PrivateSend variations/ideas

[camosoul]

While toying with ideas about how to move dust into PrivateSend, I've had a few interesting notions. Not sure how useful they could be, but figured I'd just throw it out here.

Dust compounding by "garbage collection" superblock.

1) Essentially, PS, but with deliberate time delays. Say, every 1000 blocks, or every 500 blocks... Might need more frequency upon initial introduction, but then reduce it later...

2) Same, but add in the word I hate; encryption. <-- ew, gross, don't get it on me! It smells weird!

Such a feature would depend on onion message relaying/masternode blinding of some kind.

This would increase bandwidth, but it also holds a way to reduce bandwidth at the same time...

With IS, why shouldn't all TXes/Blocks be in deliberately time-delayed superbocks? RAM limitation of way too huge mempool?

Huge blocks every 30 or 60 minutes. Everything else is simply write-buffered IS in memory pool. Staying on the same block height would be a lot easier. Add to ChainLocks and secret mining becomes hopeless. They'll have to stay ahead for weeks... the fiscal investment would be insane, and better yet, nearly open-ended, er, infinity....

Essentially, like a huge, slow, distributed hard drive. IS is write buffer, blockchain is spinning rust... Dedicated servers, RISC-V CPUs with custom DASH/MN extensions, acres of RAM...

Instead of combining dust into one big chunk, returning it as a big piece that adds up to the amount of combined dust, semi-traceable, which is then denominated by the client by the current means... All submitted dust is denominated by the MNs directly, and only one remaining spec of dust and pre-denominated VINs are returned, which then join the existing PS mixing process like any other. The load will be high at first, but once everyone gets on the same page, it'll only happen when sped change specs add up to at least .00100001. A bit of entropy in the fee so that the returned spec is not able to be directly correlated. Sometimes return 2 or 3 specs to add noise. Adding noise like this is feasible because it's a very small amount needed. Won't make a mess.

A feature add to this would be to deliberately burn/pay a little extra in fees now and then to have no spec at all, perfect denom matched output. So, a mechanism which is entropic in nature as above paragraph, but also edge-case-selecting, so that it's not a hard rule for selection, which grabs anything "close enough, but small enough not to care." Essentially, picking a random number within a range which will be used as the decider if it matches, and sometimes, also based on entropy, simply not do it even if it does match. Like a randomly selected if-then-else which includes a do nothing option.

That's some serious steganographic privacy right there... Some of this might not make sense unless you read it a few times...

What's left of my brain had a few compute cycles available, and this is what it did without my permission... Maybe there are some useful ideas in there somewhere... Maybe not... Just thought I'd throw this out and let with less brain damage think about it...

 

[Antti Kaikkonen]

I read it twice but I still didn't understand how we could combine dust inputs into denominations without making the dust inputs linkable in the blockchain.

 

[TroyDASH]

The one idea I have for privatesend is to randomize the number of rounds (with a minimum)

Knowing that all the privatesend inputs in a transaction have been mixed the same number of rounds is an unnecessary piece of information that people analyzing the blockchain don't need to have at their disposal.

 

[camosoul]

I read it twice but I still didn't understand how we could combine dust inputs into denominations without making the dust inputs linkable in the blockchain.

While toying with ideas about how to move dust into PrivateSend, I've had a few interesting notions. Not sure how useful they could be, but figured I'd just throw it out here.

Dust compounding by "garbage collection" superblock.

1) Essentially, PS, but with deliberate time delays. Say, every 1000 blocks, or every 500 blocks... Might need more frequency upon initial introduction, but then reduce it later...

Since I've stated it elsewhere, I haven't done a good job explaining it here, and I also say it needs more to be a workable idea.

The general idea is that all dust on the network, not just yours, is in this superblock.

The fact that the dust is linkable isn't very important because we already know that dust is linkable.

As long as we remove the "to what" then it doesn't matter.

By every piece of dust (or at least a whole shItload of them) being involved, sure, somewhere in there... But, there's no way to know which is which.

And there's the notion of using encryption of the superblocks. XMR does it in every block and this makes the blockchain unwieldy. If XMR ever mattered in large scale, it would collapse immediately. But, if DASH did something similar, but only did it every 1000 blocks, the scale of the problem is reduced by several orders of magnitude. With the scale of other data being stored in the blockchain, bloat becomes irrelevant. Just like other one-trick-pony coins, you could steal XMR's verblown one-trick, and scale it appropriately to be useful, and add it to DASH. Resistance is futile...

However, I still think this could be done 100% steganographically instead or resorting to cryptography. Cryptography is a 4 letter word.

It might be that this dust has to be managed on the front end during the denomination process... Essentially, every spec of dust left from from a denom is queued with a MasterNode as part of the denomination operation... Held in a separate dust memory pool waiting for a few thousand others to do the same. When you've added enough dust to the list, a pre-denominated-by-the-masternode denom is sent to you, and the dust from that re-enters the same loop, waiting for more dust to add up...

It's a different mechanism, but using the same principles. Instead of using a bare minimum of 3 in a given moment, you get a few thousand deliberately delayed for a much longer time span. With few thousand sources involved, any supposed link is not provable. This could be a stacking deterministic list, almost like a sidechain governed exclusively by the MNs, just waiting to be batched out into the main chain. This would be a mechanism to handle IoT and mirotransactions, too... MN managed mini sidechian awaiting inclusion in main chain via superblock (encrypted or otherwise).

Who runs their bank account down to zero? A few nickles and dimes tied up for a few hours at a time won't really have an impact on users.

 

[Antti Kaikkonen]

The fact that the dust is linkable isn't very important because we already know that dust is linkable.

If the dust is already linkable then why not just combine the dust into the lowest denomination when we have enough of it?

Using the unlinkable dust without linking it is hard part. For example the amount left over from sending a PrivateSend transaction that is currently 'wasted' in transaction fees.

Using encryption might work. For example in mimblewimble each block is essentially a big mixing transaction where the input and output values are encrypted.