Re: New paper: Accelerating Bitcoin's Trasaction Processing
Hello avivz..
If a heaviest subtree determines current network head, then two things will be possible with a 50% attacker that aren't currently possible now:
1) You can actually strip off head and the chain length can move backwards. (This includes rewinding back past a difficulty retarget, which is currently impossible.[1])
2) You can create a scenario where two mining factions create divergent forks which simply add to their own subtree weight, and the main chain length goes ~nowhere.
With the way bitcoin is currently built, neither of these two possibilities is.. er.. possible. All 50% attacks must, even though they rewrite history, move head forwards.
Whether this has any meaning in terms of risk to bitcoin users I suppose is another matter than the point of my post. Did you address these possibilities in your paper? I ask because I read a good chunk of it, but not all of it, for which I apologise. I am extremely happy to see academic work being done on bitcoin.
At the very least, I'd like to encourage you (as I am a random internet nobody
to create an experimental fork with this idea built in as a testnet alternative.
Hrm.. I suppose in terms of user software, all current infrastructure which makes assumptions about the current rules would be exposed to risk by a switch to ghost-enabled bitcoind..
[1] maaku pointed out people may be confused with my terminology: a replacement of work can "rewind" a chain in the sense that the history is substituted with another history of greater work in a non-GHOST mainline: "Rewinding" in the sense I mean it here is to strip off the numerical topmost block so that mainline head is actually prior to the retarget point: using GHOST orphans it is possible to erase the retarget and make it historically as though it never happened.
If a heaviest subtree determines current network head, then two things will be possible with a 50% attacker that aren't currently possible now:
1) You can actually strip off head and the chain length can move backwards. (This includes rewinding back past a difficulty retarget, which is currently impossible.[1])
2) You can create a scenario where two mining factions create divergent forks which simply add to their own subtree weight, and the main chain length goes ~nowhere.
With the way bitcoin is currently built, neither of these two possibilities is.. er.. possible. All 50% attacks must, even though they rewrite history, move head forwards.
Whether this has any meaning in terms of risk to bitcoin users I suppose is another matter than the point of my post. Did you address these possibilities in your paper? I ask because I read a good chunk of it, but not all of it, for which I apologise. I am extremely happy to see academic work being done on bitcoin.
At the very least, I'd like to encourage you (as I am a random internet nobody
to create an experimental fork with this idea built in as a testnet alternative.Hrm.. I suppose in terms of user software, all current infrastructure which makes assumptions about the current rules would be exposed to risk by a switch to ghost-enabled bitcoind..
[1] maaku pointed out people may be confused with my terminology: a replacement of work can "rewind" a chain in the sense that the history is substituted with another history of greater work in a non-GHOST mainline: "Rewinding" in the sense I mean it here is to strip off the numerical topmost block so that mainline head is actually prior to the retarget point: using GHOST orphans it is possible to erase the retarget and make it historically as though it never happened.