Anyone with a bit of a deeper network and cryptography knowledge care to comment on this technical proposal:
https://bitcoinmagazine.com/articles/bitcoin-ng-or-how-cornell-researchers-think-a-radical-redesign-can-solve-bitcoin-s-scaling-issues-1447108649Basic idea seems to be to decouple proof of work blocks from transactions blocks (while keeping the two connected, obviously), without the usual trade off that means more tx -> bigger blocks.
Looks plausible to me, and actually a lot less "radical" than, say, turning Bitcoin into a proof-of-stake system. That said, I don't have sufficient technical knowledge to judge if it only appears plausible at a glance or if there's a catch I don't see right now.
(... he asked on the Wall Observer thread, thinking "What could possibly go wrong?")
This looks like an interesting idea which seems to both address the transaction limit concerns voiced by large blockers and the mining centralization due to slow propagation of large blocks feared by small blockers. It might open up new attack vectors though. First thought which comes to my mind is that if the miner currently responsible for verifying transactions goes offline/something happens to them, do we get a delay in transaction confirmations until the next block is mined? If so this would open the door to an attack where you would just DDOS or otherwise incapacitate the miner and the network grinds to a halt. Such centralization, very scare. Also what happens if the miner decides to double-spend transactions worth more than the coinbase reward + transaction fees combined? As far as I can tell the only punishment seems to be that their block rewards gets taken away retroactively by the network. Also what happens to such a reward afterwards? Wouldn't that mess with Bitcoins steady predictable inflation rate? So many questions...
That's the kind of input I was hoping for...
First thought which comes to my mind is that if the miner currently responsible for verifying transactions goes offline/something happens to them, do we get a delay in transaction confirmations until the next block is mined? If so this would open the door to an attack where you would just DDOS or otherwise incapacitate the miner and the network grinds to a halt. Such centralization, very scare.
The difference to the current situation is that you'd only need to incapacitate a fraction of total hash power, in contrast to the global attack you'd need to launch now to achieve the same. Correct?
Is there a time delay how long it takes to "direct" your DDOS attacks? As in: once you've learned who holds the key for the current micro block period, you have exactly 10 minutes to perform a targeted attack. Is that enough, given the constraints of practically applicable DDOS attack scenarios we know?
Also what happens if the miner decides to double-spend transactions worth more than the coinbase reward + transaction fees combined? As far as I can tell the only punishment seems to be that their block rewards gets taken away retroactively by the network. Also what happens to such a reward afterwards? Wouldn't that mess with Bitcoins steady predictable inflation rate? So many questions...
I don't consider this one so problematic, for two reasons:
(1) There's a strong economic
disincentive to do so for global utility reasons, even if locally, it might make economic sense. The only entities (pools, presumably) likely to pull off such an attack are the big holders of hash power anyway. A double spend exceeding reward+fees would be worth it locally, i.e. they'd gain more (txs value) than they'd lose (reward+fees), but they would almost certainly suffer a much greater loss globablly due to (a) lower value of any rewards+fees gained in the future because of negative market reaction to the "inside" attack, and (b) sharp disappreciation of their (sunk) hardware cost, caused by the same mechanism as in (a).
(Aside: I've used a similar argument a few times as criticism of the (imo economically naive) attack scenarios described by Emin Gün Sirer. He correctly describes a positive "local" incentive to cheat given mining centralization, but doesn't properly account for the "global" economic consequences for the cheating entity.)
That said, even if you would in principle agree with my
global vs. local utility argument, there's likely a limit to it, i.e. if you manage to cheat the network out of enough coins that you'd be able to sell fast enough before the market reacts, the attack could be worth it. Which leads to my next point:
(2) Waiting for confirmation (just 10 minutes) or several confirmations if large values are at stake is already recommended now. We're only describing successful cheating in case of the recipient accepting 0-conf txs anyway, right? In that case, there's an upper limit to the
actual damage caused anyway, since the network only allows us to see no. of confirmations (and, after the fact) possible double spends, but tx
acceptance is a decision process
outside the network, and it is almost guaranteed that the actually ("externally") accepted volume per block is strictly smaller than the total volume per block.
Poll
