On Sat, 7 Oct 2017 00:56:29 +0300 George Violaris <violarisgeorge@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.