Dusty
Active Member
- Mar 14, 2016
- 362
- 1,172
And where should I get this information, apart from the fact that you are trying to blame core for the loss you got using SPV mining?I'm a miner, you don't get this simple fact
Actually, while I accept minor soft forks without complaining too much, if I could choose, I would only dohard forks to ensure everybody runs the latest code. That would put out the network lazy people that don't want to update his node, or started one a long time ago and then forgot it is there.The soft fork practice is based on the same logic that Dusty holds: 99% of nodes are not capable of understanding what is going on, thus they deserve to be fooled into believing the new version does the same thing as before
By hard forking we could also fix bugs we are still keeping around just to be compatible with the first version of bitcoin (just think of the strand 0 in op_checkmultisig...)
How could you prove something that it's not even completely defined, let alone implemented and deployed?LN's payment channel model has been proved that have very little practical use, it mostly benefits centralized exchanges where they do large amount of clearing every day
[doublepost=1459967818][/doublepost]
That gets worse: if I understood right (I wouldn't bet on it), you have only a fixed amount of time to redeem your transaction (e.g.: 24 hours), and with small blocks and a large backlog, you would probably run out of time and lose your funds.Suppose you have a fairly large hub, and there is some kind of connectivity problem, be it technical, DDoS, whatever. Wouldn't this potentially trigger a run on the hub where everyone with current open channels is going to look to close them out to protect themselves? If that were to transpire, I don't think it's implausible that such an event could cause radical transaction backlog on the main chain, especially proportional to how much scaling they're getting out of Lightning on average
[doublepost=1459968069][/doublepost]
Yes, I came to the same conclusion: if the cost to open a channel is too high because the block size is artificially kept small, then new users would by bitcoins that only exists in the LN because it would be anti-economical to bring them on the blockchain. You then would have class A bitcoins (on the blockchain) and class B bitcoins on the LN.The solution to this problem is that they simply only have channels open with other hubs, and you get bitcoins from them by buying IOU entries on their side in fiat. In this scenario there doesn't need to actually be Lightning-to-the-end-user, and this is where the slippery slope to fractional reserve can happen in my opinion. It's ironic to me that in reality, a centralized LN is exactly the same use-case as Liquid. Or maybe it's not so ironic.
But I don't find this brings fractional reserve: a bitcoin on the LN is the same bitcoin on the blockchain, the total number remains the same.