Cryptocurrency Privacy: Evolving... Zerocash (ZEC, ZCL, ZEN) vs All Other Coin

juan juan.g71 at gmail.com
Fri Oct 6 23:12:11 PDT 2017


On Sat, 7 Oct 2017 00:56:29 +0300
George Violaris <violarisgeorge at gmail.com> wrote:

> On 10/6/2017 10:13 PM, juan wrote:
> > well supposedly the lightning network will add more capacity 
> 
> Supposedly, LN will allow nodes to store only the transactions that 
> concern them. Which to me sounds like a way to mess with the original 
> double-spend prevention mechanism. 

	Not in theory. LN transactions done inside a channel don't
	show up on the blockchain, but the transactions needed to open
	and close the channel (or eventual dispute resolution) are
	'on-chain' and that's what prevents double spending. 


> What if the nodes witnessing the 
> transactions behave badly? Wouldn't this be prone to attack?

	Could be. I don't know what mechanisms/incentives are there for
	nodes to behave well. 


> 
> In any case I believe it is better to have a balance-out and archive 
> mechanism rather than do transactions on a side chain. 

	But even if you have a lot more on-chain capacity you won't have
	fast transactions. 


> Transactions 
> should happen in the main, wide open chain. It would make more sense
> to keep only balances and prune transactions older than x
> confirmations. Or something along those lines, I haven't given this
> enough thought to truly make up my mind about specifics; but the
> pruned transactions can be synchronized to archive nodes for
> historicity, research and verification purposes.
> 
> Basically,
> 1. transactions older than x confirmations move to archive nodes and
> are deleted from main blockchain
> 2. main blockchain keeps transactions that are being confirmed until
> x blocks and keeps the balance amount for each public key


	I think there are plans to do...something about that.

	Spent transactions/outputs are useless, except for spying, but
	the argument goes : the only way to really 'verify' that you are
	not being tricked is to parse the whole history...



> 3. In order for this to work, we'd probably need to have a 
> pseudo-genesis block upon each archive session. It will be like a
> fork but the pseudo-genesis block will have a pointer to the previous 
> archived block. So if we're archiving 3 times a day (i.e. can be a
> const every x amount of blocks), this would mean that we're doing a
> chain fork 3 times a day. However, each time we fork we keep all the
> balances, unconfirmed (less than x times) transactions and confirmed
> transactions (equal to x confirmations) public to the new chain.
> 
> Of course the transaction signatures still need to be dealt with to 
> remove any malleability issues and the block size would need to, in
> my opinion, become entirely dynamic - something like how CryptoNote
> defines it.



More information about the cypherpunks mailing list