Peter Todd [ARCHIVE] on Nostr: š Original date posted:2013-08-18 š Original message:Did some tests with a ...
š
Original date posted:2013-08-18
š Original message:Did some tests with a varient of attack... In short it's fairly easy to
saturate a node's disk IO bandwidth and when that happens the node
quickly falls behind in consensus, not to mention becomes useless to
it's peers. Note that the particular varient I tried is different, and
less efficient in bandwidth, than others discussed privately.
Bandwidth required to, for example, take out a Amazon EC2 m1.small is
about 1KiB/second, and results in it getting multiple blocks behind in
consensus, or a delay on the order of minutes to tens of minutes. I had
similar results attacking a p2pool node I own that has a harddrive and
4GiB of ram - of course my orphan rate went to 100%
It'd be interesting to repeat the attack by distributing it from
multiple peers rather than from a single source. At that point the
attack could be made indistinguishable from a bunch of SPV wallets
rescanning the chain for old transactions.
In any case given that SPV peers don't contribute back to the network
they should obviously be heavily deprioritized and served only with
whatever resources a node has spare. The more interesting question is
how do you make it possible for SPV nodes to gain priority over an
attacker? It has to be some kind of limited resource - schemes that rely
on things like prioritizing long-lived identities fail against patient
attackers - time doesn't make an identity expensive if the identity is
free in the first place. Similarly summing up the fees paid by
transactions relayed from that peer also fail, because an attacker can
easily broadcast the same transaction to multiple peers at once - it's
not a limited resource. Bandwidth is limited, but orders of magnitude
cheaper for the attacker than a Android wallet on a dataplan.
--
'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130818/82c987fe/attachment.sig>;
š Original message:Did some tests with a varient of attack... In short it's fairly easy to
saturate a node's disk IO bandwidth and when that happens the node
quickly falls behind in consensus, not to mention becomes useless to
it's peers. Note that the particular varient I tried is different, and
less efficient in bandwidth, than others discussed privately.
Bandwidth required to, for example, take out a Amazon EC2 m1.small is
about 1KiB/second, and results in it getting multiple blocks behind in
consensus, or a delay on the order of minutes to tens of minutes. I had
similar results attacking a p2pool node I own that has a harddrive and
4GiB of ram - of course my orphan rate went to 100%
It'd be interesting to repeat the attack by distributing it from
multiple peers rather than from a single source. At that point the
attack could be made indistinguishable from a bunch of SPV wallets
rescanning the chain for old transactions.
In any case given that SPV peers don't contribute back to the network
they should obviously be heavily deprioritized and served only with
whatever resources a node has spare. The more interesting question is
how do you make it possible for SPV nodes to gain priority over an
attacker? It has to be some kind of limited resource - schemes that rely
on things like prioritizing long-lived identities fail against patient
attackers - time doesn't make an identity expensive if the identity is
free in the first place. Similarly summing up the fees paid by
transactions relayed from that peer also fail, because an attacker can
easily broadcast the same transaction to multiple peers at once - it's
not a limited resource. Bandwidth is limited, but orders of magnitude
cheaper for the attacker than a Android wallet on a dataplan.
--
'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130818/82c987fe/attachment.sig>;