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