[Bitcoin-development] Gavin's post-0.9 TODO list...

[Bitcoin-development] Gavin's post-0.9 TODO list...

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Mike asked what non-0.9 code I'm working on; the three things on the top of
my list are:

1) Smarter fee handling on the client side, instead of hard-coded fees. I
was busy today generating scatter-plots and histograms of transaction fees
versus priorities to get some insight into what miner policies look like
right now.

2) "First double-spend" relaying and alerting, to better support low-value
in-person transactions.  Related:
*Have *a *Snack*, Pay with
*Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>


3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
block size limit, how we can do it safely, and go through all of the
arguments that have been made against it and explain why they're wrong.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1382 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On 16 August 2013 03:00, Gavin Andresen <gavinandresen@gmail.com> wrote:

> Mike asked what non-0.9 code I'm working on; the three things on the top
> of my list are:
>
> 1) Smarter fee handling on the client side, instead of hard-coded fees. I
> was busy today generating scatter-plots and histograms of transaction fees
> versus priorities to get some insight into what miner policies look like
> right now.
>

+1


>
> 2) "First double-spend" relaying and alerting, to better support low-value
> in-person transactions.  Related:
> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>
>

+1


>
> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
> block size limit, how we can do it safely, and go through all of the
> arguments that have been made against it and explain why they're wrong.
>

What block size do you think is ideal?


>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3314 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

Cool. Maybe it's time for another development update on the foundation blog?


On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> Mike asked what non-0.9 code I'm working on; the three things on the top
> of my list are:
>
> 1) Smarter fee handling on the client side, instead of hard-coded fees. I
> was busy today generating scatter-plots and histograms of transaction fees
> versus priorities to get some insight into what miner policies look like
> right now.
>
> 2) "First double-spend" relaying and alerting, to better support low-value
> in-person transactions.  Related:
> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>
>
> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
> block size limit, how we can do it safely, and go through all of the
> arguments that have been made against it and explain why they're wrong.
>
> --
> --
> Gavin Andresen
>
>

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

The only other thing I'd like to see there is the start of a new anti-DoS
framework. I think once the outline is in place other people will be able
to fill it in appropriately. But the current framework has to be left
behind.

If I had to choose one thing to evict to make time for that, it'd be the
whitepapers. At the moment we still have plenty of headroom in block sizes,
even post April. It can probably be safely delayed for a while.


On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:

> Cool. Maybe it's time for another development update on the foundation
> blog?
>
>
> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>
>> Mike asked what non-0.9 code I'm working on; the three things on the top
>> of my list are:
>>
>> 1) Smarter fee handling on the client side, instead of hard-coded fees. I
>> was busy today generating scatter-plots and histograms of transaction fees
>> versus priorities to get some insight into what miner policies look like
>> right now.
>>
>> 2) "First double-spend" relaying and alerting, to better support
>> low-value in-person transactions.  Related:
>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>>
>>
>> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
>> block size limit, how we can do it safely, and go through all of the
>> arguments that have been made against it and explain why they're wrong.
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2818 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]

https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
*Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
If you disallow the same IP and/or subnet from establishing too many TCP
connections with your node, it becomes more expensive for attackers to use
a single host exhaust a target node's resources.  This iptables firewall
based example has almost zero drawbacks, but it is too complicated for most
people to deploy.  Yes, there is a small chance that you will block
legitimate connections, but there are plenty of other nodes for random
connections to choose from.  Configurable per source IP and source subnet
limits with sane defaults enforced by bitcoind itself would be a big
improvement over the current situation where one host address can consume
limited resources of many target nodes.

This doesn't remove the risk of a network-wide connection exhaustion attack
by a determined attacker, but it at least makes multiple types of attacks a
lot more expensive.  This also doesn't do much against the io
vulnerability, which would require major redesigns to prevent in Bitcoin.

https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
*Want to safely delay the block size limit increase for another year or two?
*  This patch alone enables that.



On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike@plan99.net> wrote:

> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.
>
> If I had to choose one thing to evict to make time for that, it'd be the
> whitepapers. At the moment we still have plenty of headroom in block sizes,
> even post April. It can probably be safely delayed for a while.
>
>
> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> Cool. Maybe it's time for another development update on the foundation
>> blog?
>>
>>
>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>>
>>> Mike asked what non-0.9 code I'm working on; the three things on the top
>>> of my list are:
>>>
>>> 1) Smarter fee handling on the client side, instead of hard-coded fees.
>>> I was busy today generating scatter-plots and histograms of transaction
>>> fees versus priorities to get some insight into what miner policies look
>>> like right now.
>>>
>>> 2) "First double-spend" relaying and alerting, to better support
>>> low-value in-person transactions.  Related:
>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>>>
>>>
>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
>>> block size limit, how we can do it safely, and go through all of the
>>> arguments that have been made against it and explain why they're wrong.
>>>
>>> --
>>> --
>>> Gavin Andresen
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5854 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4789 bytes --]

A ban-subnet RPC would be a reasonable addition, but obviously DoS
attackers that are IP or bandwidth constrained are really just script
kiddies. Also anything that involves every node operator doing manual
intervention rather works against decentralisation and having a big
network. That's why I keep pushing for automated heuristic driven
prioritisation.


On Fri, Aug 16, 2013 at 3:41 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:

>
> https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
> *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
> If you disallow the same IP and/or subnet from establishing too many TCP
> connections with your node, it becomes more expensive for attackers to use
> a single host exhaust a target node's resources.  This iptables firewall
> based example has almost zero drawbacks, but it is too complicated for most
> people to deploy.  Yes, there is a small chance that you will block
> legitimate connections, but there are plenty of other nodes for random
> connections to choose from.  Configurable per source IP and source subnet
> limits with sane defaults enforced by bitcoind itself would be a big
> improvement over the current situation where one host address can consume
> limited resources of many target nodes.
>
> This doesn't remove the risk of a network-wide connection exhaustion
> attack by a determined attacker, but it at least makes multiple types of
> attacks a lot more expensive.  This also doesn't do much against the io
> vulnerability, which would require major redesigns to prevent in Bitcoin.
>
>
> https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
> *Want to safely delay the block size limit increase for another year or
> two?*  This patch alone enables that.
>
>
>
> On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> The only other thing I'd like to see there is the start of a new anti-DoS
>> framework. I think once the outline is in place other people will be able
>> to fill it in appropriately. But the current framework has to be left
>> behind.
>>
>> If I had to choose one thing to evict to make time for that, it'd be the
>> whitepapers. At the moment we still have plenty of headroom in block sizes,
>> even post April. It can probably be safely delayed for a while.
>>
>>
>> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> Cool. Maybe it's time for another development update on the foundation
>>> blog?
>>>
>>>
>>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@gmail.com
>>> > wrote:
>>>
>>>> Mike asked what non-0.9 code I'm working on; the three things on the
>>>> top of my list are:
>>>>
>>>> 1) Smarter fee handling on the client side, instead of hard-coded fees.
>>>> I was busy today generating scatter-plots and histograms of transaction
>>>> fees versus priorities to get some insight into what miner policies look
>>>> like right now.
>>>>
>>>> 2) "First double-spend" relaying and alerting, to better support
>>>> low-value in-person transactions.  Related:
>>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>>>>
>>>>
>>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
>>>> block size limit, how we can do it safely, and go through all of the
>>>> arguments that have been made against it and explain why they're wrong.
>>>>
>>>> --
>>>> --
>>>> Gavin Andresen
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7664 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 5401 bytes --]

Automatic heuristic driven prioritization, with sane defaults and some
configurable knobs, is exactly what I suggest.

In the short-term though, any connection limits added to the client by
default would be the simplest and easiest protection measure to audit.  It
would improve things a lot over the current situation where there are no
limits, and it requires no manual intervention from node operators.

Warren







On Fri, Aug 16, 2013 at 3:46 AM, Mike Hearn <mike@plan99.net> wrote:

> A ban-subnet RPC would be a reasonable addition, but obviously DoS
> attackers that are IP or bandwidth constrained are really just script
> kiddies. Also anything that involves every node operator doing manual
> intervention rather works against decentralisation and having a big
> network. That's why I keep pushing for automated heuristic driven
> prioritisation.
>
>
> On Fri, Aug 16, 2013 at 3:41 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:
>
>>
>> https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
>> *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
>> If you disallow the same IP and/or subnet from establishing too many TCP
>> connections with your node, it becomes more expensive for attackers to use
>> a single host exhaust a target node's resources.  This iptables firewall
>> based example has almost zero drawbacks, but it is too complicated for most
>> people to deploy.  Yes, there is a small chance that you will block
>> legitimate connections, but there are plenty of other nodes for random
>> connections to choose from.  Configurable per source IP and source subnet
>> limits with sane defaults enforced by bitcoind itself would be a big
>> improvement over the current situation where one host address can consume
>> limited resources of many target nodes.
>>
>> This doesn't remove the risk of a network-wide connection exhaustion
>> attack by a determined attacker, but it at least makes multiple types of
>> attacks a lot more expensive.  This also doesn't do much against the io
>> vulnerability, which would require major redesigns to prevent in Bitcoin.
>>
>>
>> https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
>> *Want to safely delay the block size limit increase for another year or
>> two?*  This patch alone enables that.
>>
>>
>>
>> On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> The only other thing I'd like to see there is the start of a new
>>> anti-DoS framework. I think once the outline is in place other people will
>>> be able to fill it in appropriately. But the current framework has to be
>>> left behind.
>>>
>>> If I had to choose one thing to evict to make time for that, it'd be the
>>> whitepapers. At the moment we still have plenty of headroom in block sizes,
>>> even post April. It can probably be safely delayed for a while.
>>>
>>>
>>> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:
>>>
>>>> Cool. Maybe it's time for another development update on the foundation
>>>> blog?
>>>>
>>>>
>>>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <
>>>> gavinandresen@gmail.com> wrote:
>>>>
>>>>> Mike asked what non-0.9 code I'm working on; the three things on the
>>>>> top of my list are:
>>>>>
>>>>> 1) Smarter fee handling on the client side, instead of hard-coded
>>>>> fees. I was busy today generating scatter-plots and histograms of
>>>>> transaction fees versus priorities to get some insight into what miner
>>>>> policies look like right now.
>>>>>
>>>>> 2) "First double-spend" relaying and alerting, to better support
>>>>> low-value in-person transactions.  Related:
>>>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>>>>>
>>>>>
>>>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the
>>>>> 1MB block size limit, how we can do it safely, and go through all of the
>>>>> arguments that have been made against it and explain why they're wrong.
>>>>>
>>>>> --
>>>>> --
>>>>> Gavin Andresen
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 8642 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Fri, Aug 16, 2013 at 03:41:54AM -1000, Warren Togami Jr. wrote:
> https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
> *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
> If you disallow the same IP and/or subnet from establishing too many TCP
> connections with your node, it becomes more expensive for attackers to use
> a single host exhaust a target node's resources.  This iptables firewall
> based example has almost zero drawbacks, but it is too complicated for most
> people to deploy.  Yes, there is a small chance that you will block
> legitimate connections, but there are plenty of other nodes for random
> connections to choose from.  Configurable per source IP and source subnet
> limits with sane defaults enforced by bitcoind itself would be a big
> improvement over the current situation where one host address can consume
> limited resources of many target nodes.

Have you looked into what it would take to just apply the IP diversity
tests for outgoing connections to incoming connections? The code's
already there...

-- 
'peter'[:-1]@petertodd.org
0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Gregory Maxwell]

On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. <wtogami@gmail.com> wrote:
> If you disallow the same IP and/or subnet from establishing too many TCP
> connections with your node,
[...]
> has almost zero drawbacks,

There are whole countries who access the internet from single IP
addresses. There are major institution with hundreds or even thousands
of hosts that could be running Bitcoin who are visible to the public
internet as a single IP address (/single subnet).  Most tor traffic
exits to the internet from a dozen of the largest exits, common
local-network configurations have people addnode-ing local hosts from
many systems on a subnet, etc.

Prioritizing the availability of inbound slots based on source IP is
reasonable and prudent, but it does not have almost zero drawbacks.
Outright limiting is even worse.

As a protective measure its also neigh useless for IPv6 connected
hosts and hidden service hosts.  It's also ineffective at attacks
which exhaust your memory, cpu, IO, or bandwidth without trying to
exhaust your sockets.

So I am not opposed to prioritizing based on it (e.g. when full pick
an inbound connection to drop based on criteria which includes network
mask commonality), but I would not want to block completely based on
this.

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]

On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote:
> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.

Part of anti-DoS should include making it easier for people to
contribute back to the network. Lowest hanging fruit:

1) SPV nodes with spare bandwidth should relay whole blocks to reduce
the load on full-nodes. The SPV security model is based on hashing power
anyway, so there is no major harm in doing so - if you have the
resources to fake blocks, you probably have the resources to sybil the
network anyway.

2) It's probably reasonable for SPV peers with bandwidth to be willing
to do bloom filtering on the behalf of peers that don't have spare
bandwidth. Hence they would set NODE_BLOOM, but not NODE_NETWORK. (or
more likely some more nuanced flags) Again this has to apply to full
blocks only unless we come up with some PoW scheme or similar to
discourage DoS attacks via invalid transactions. (maintaining partial
UTXO sets is another possibility, although a complex one)

Both examples work best with payment protocols where the recipient is
responsible for getting the transaction broadcast. Similarly you can by
default not connect to full-node peers, and then connect to them on
demand when you have a transaction to send.

Doing this also makes it more difficult to sybil the network - for
instance right now you can create "SPV honeypots" that allow incoming
connections only from SPV nodes, thus attracting a disproportionate % of
the total SPV population given a relatively small number of nodes. You
can then use that to harm SPV nodes by, for instance, making a % of
transactions be dropped deterministicly, either by the bloom matching
code, or when sent. Users unlucky enough to be surrounded by sybil nodes
will have their transactions mysteriously fail to arrive in their
wallets, or have their transactions mysteriously never confirm. Given
how few full nodes there are, it probably won't take very many honeypots
to pull off this attack, especially if you combine it with a
simultaneous max connections or bloom io attack to degrade the capacity
of honest nodes.

Deanonymization is another attack that can be done at the same time of
course.

In any case, the more peers on the network that can relay data the
better.

3) Make it easier to run a full node. IMO partial mode is the way to go
here. Note that from a legal perspective we really want to make sure
that running full nodes (and mining p2pool or solo) continue to be
something ordinary users do. We do not want to give the impression to
regulators that running a full node is in any way unusual or rare, and
thus something that might be practical or desirable to regulate. Users
should be given clear options about how much disk space and bandwidth to
donate to the health of the network, and within those limits nodes
should always try to make progress towards being full nodes, and in the
meantime being increasingly productive partial nodes.

Even with pure SPV nodes if they are relaying block data and ideally
transactions they make it much more difficult for regulations to be made
that, say, require full node operators to apply blacklists to
transactions in the mempool or in blocks.


4) This is really a side effect, and not directly DoS-related, but
unfortunately we're going to have to create some kind of
proof-of-UTXO-possession that miners include in the blocks they mine.
With partial mode it's just too easy and tempting for people to mine
blocks with fee paying transactions in them without actually having the
full UTXO set; such nodes can't tell if a block is invalid due to a fake
txin, and thus will happily extend a invalid chain. This possession
proof can probably be make part of a UTXO commitment.

> If I had to choose one thing to evict to make time for that, it'd be the
> whitepapers. At the moment we still have plenty of headroom in block sizes,
> even post April. It can probably be safely delayed for a while.

Lots of off-chain tx solutions are popping up which will help push back
the issue's relevance as well. Also your micropayment channels possibly.

-- 
'peter'[:-1]@petertodd.org
000000000000000b9656276a0fdab028ca759c3fd7f951fb20196c264b5cd1ce

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
> Doing this also makes it more difficult to sybil the network - for
> instance right now you can create "SPV honeypots" that allow incoming
> connections only from SPV nodes, thus attracting a disproportionate % of
> the total SPV population given a relatively small number of nodes. You
> can then use that to harm SPV nodes by, for instance, making a % of
> transactions be dropped deterministicly, either by the bloom matching
> code, or when sent. Users unlucky enough to be surrounded by sybil nodes
> will have their transactions mysteriously fail to arrive in their
> wallets, or have their transactions mysteriously never confirm. Given
> how few full nodes there are, it probably won't take very many honeypots
> to pull off this attack, especially if you combine it with a
> simultaneous max connections or bloom io attack to degrade the capacity
> of honest nodes.

Oh, here's an even better way to do the "tx drop" attack: when you drop
a transaction, make a fake one that pays the same scriptPubKeys with the
same amount, and send it to the SPV peer instead. They'll see the
transaction go through and show up in their wallet, but it'll look like
it got stuck and never confirmed. They'll soon wind up with a wallet
full of useless transactions, effectively locking them out of their
money.

Here's another question for you Mike: So does bitcoinj have any
protections against peers flooding you with useless garbage? It'd be
easy to rack up a user's data bill for instance by just creating junk
unconfirmed transactions matching the bloom filter.

-- 
'peter'[:-1]@petertodd.org
0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

bitcoinj-0.10 release notes:

   - We now require Bloom-capable (0.8+) peers by default and will
   disconnect from older nodes. This avoids accidental bandwidth saturation on
   mobile devices.

Given the user-security concern that Peter brings up, reconsideration of
this new default behavior in SPV clients may be warranted.



On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
> > Doing this also makes it more difficult to sybil the network - for
> > instance right now you can create "SPV honeypots" that allow incoming
> > connections only from SPV nodes, thus attracting a disproportionate % of
> > the total SPV population given a relatively small number of nodes. You
> > can then use that to harm SPV nodes by, for instance, making a % of
> > transactions be dropped deterministicly, either by the bloom matching
> > code, or when sent. Users unlucky enough to be surrounded by sybil nodes
> > will have their transactions mysteriously fail to arrive in their
> > wallets, or have their transactions mysteriously never confirm. Given
> > how few full nodes there are, it probably won't take very many honeypots
> > to pull off this attack, especially if you combine it with a
> > simultaneous max connections or bloom io attack to degrade the capacity
> > of honest nodes.
>
> Oh, here's an even better way to do the "tx drop" attack: when you drop
> a transaction, make a fake one that pays the same scriptPubKeys with the
> same amount, and send it to the SPV peer instead. They'll see the
> transaction go through and show up in their wallet, but it'll look like
> it got stuck and never confirmed. They'll soon wind up with a wallet
> full of useless transactions, effectively locking them out of their
> money.
>
> Here's another question for you Mike: So does bitcoinj have any
> protections against peers flooding you with useless garbage? It'd be
> easy to rack up a user's data bill for instance by just creating junk
> unconfirmed transactions matching the bloom filter.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3950 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]

That change was made in response to user complaints. Heck we get complaints
about battery life and bandwidth impact even with Bloom filtering. We can't
just randomly start using peoples bandwidth for relaying blocks, especially
as I guess most SPV nodes are behind NAT.

If Gavin is right and the future is dominated by mobiles and tablets, then
it will require a change of thinking in how P2P networks work. I think
there are plenty of people with private servers who would be willing to run
nodes though. I'm not too worried about this.


On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:

> bitcoinj-0.10 release notes:
>
>    - We now require Bloom-capable (0.8+) peers by default and will
>    disconnect from older nodes. This avoids accidental bandwidth saturation on
>    mobile devices.
>
> Given the user-security concern that Peter brings up, reconsideration of
> this new default behavior in SPV clients may be warranted.
>
>
>
> On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete@petertodd.org> wrote:
>
>> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> > Doing this also makes it more difficult to sybil the network - for
>> > instance right now you can create "SPV honeypots" that allow incoming
>> > connections only from SPV nodes, thus attracting a disproportionate % of
>> > the total SPV population given a relatively small number of nodes. You
>> > can then use that to harm SPV nodes by, for instance, making a % of
>> > transactions be dropped deterministicly, either by the bloom matching
>> > code, or when sent. Users unlucky enough to be surrounded by sybil nodes
>> > will have their transactions mysteriously fail to arrive in their
>> > wallets, or have their transactions mysteriously never confirm. Given
>> > how few full nodes there are, it probably won't take very many honeypots
>> > to pull off this attack, especially if you combine it with a
>> > simultaneous max connections or bloom io attack to degrade the capacity
>> > of honest nodes.
>>
>> Oh, here's an even better way to do the "tx drop" attack: when you drop
>> a transaction, make a fake one that pays the same scriptPubKeys with the
>> same amount, and send it to the SPV peer instead. They'll see the
>> transaction go through and show up in their wallet, but it'll look like
>> it got stuck and never confirmed. They'll soon wind up with a wallet
>> full of useless transactions, effectively locking them out of their
>> money.
>>
>> Here's another question for you Mike: So does bitcoinj have any
>> protections against peers flooding you with useless garbage? It'd be
>> easy to rack up a user's data bill for instance by just creating junk
>> unconfirmed transactions matching the bloom filter.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5907 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Fri, Aug 16, 2013 at 04:36:20PM +0200, Mike Hearn wrote:
> That change was made in response to user complaints. Heck we get complaints
> about battery life and bandwidth impact even with Bloom filtering. We can't
> just randomly start using peoples bandwidth for relaying blocks, especially
> as I guess most SPV nodes are behind NAT.

UPNP seems to work well for the reference client. What's the situation
there on Android?

I leave my phone plugged in and connected via wifi for most of the day;
lots of people do that.

The user interface for this stuff is very simple: "How much bandwidth
will you contribute back? If you contribute more bandwidth back, other
peers will prioritize you and your wallet will be more reliable."

-- 
'peter'[:-1]@petertodd.org
000000000000003cfc051263917373a1cab2655994b97c54a625021f52c84658

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

I might agree this would be helpful for the many phones plugged into power
and on wifi for large portions of the day.  However that doesn't really
help much when phone IP addresses change often as you move onto different
networks, and currently IP address is the only thing that peers can keep
track of for the goodness of a peer as there is no roaming pseudo-identity
cookie due to separate goal of anonymity?  I haven't studied the issue if
would be even possible to have both privacy protection and unique node
identifiers for anti-DoS authentication at the same time.

On Fri, Aug 16, 2013 at 4:59 AM, Peter Todd <pete@petertodd.org> wrote:

> The user interface for this stuff is very simple: "How much bandwidth
> will you contribute back? If you contribute more bandwidth back, other
> peers will prioritize you and your wallet will be more reliable."
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000003cfc051263917373a1cab2655994b97c54a625021f52c84658
>

[-- Attachment #2: Type: text/html, Size: 1484 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@petertodd.org> wrote:

> UPNP seems to work well for the reference client. What's the situation
> there on Android?
>

Not sure - it could be investigated. I think UPNP is an entirely
userspace-implementable protocol, so in theory it could be done by a
userspace library (even libminiupnp - java is not a requirement on android)


> I leave my phone plugged in and connected via wifi for most of the day;
> lots of people do that.
>

I suspect you mean "I think lots of people do that". I'm not so sure. We
could potentially run an experiment in the Android app to measure how many
users are in a position to contribute back, but just because you have wifi
doesn't mean you can reconfigure it using UPnP. That helps a lot in home
networks, but at the office it doesn't help.

I'm wary of a ton of work being put in to achieve not very much here.
Satoshi's original vision was always that millions of users were supported
by 100,000 or so nodes. I don't think that's unreasonable over the long
term.

Besides, prioritisation isn't very hard. Nodes can just hand clients a
signed timestamp which they remember. When re-connecting, the signed
timestamp is handed back to the node and it gives priority to those with
old timestamps. No state is required on the node side. Signing and checking
can be passed onto the general ECDSA thread pool that works its way through
pending signature operations, they'd be prioritised lower than checking
blocks/broadcasts.

[-- Attachment #2: Type: text/html, Size: 2159 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

Oops, hit send too early.

Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side. Signing and checking
> can be passed onto the general ECDSA thread pool that works its way through
> pending signature operations, they'd be prioritised lower than checking
> blocks/broadcasts.
>

The other nice thing about this approach, besides being stateless on the
server side, is that it's up to the client whether or not they present the
cookie. So the node can say "if you don't present your cookie I'm going to
disconnect you" but when the node has sufficient resources, it'd just not
request this and the client remains anonymous. If the client thinks the
server is calling its bluff, it can just wait and see if it really does get
disconnected and if so, present the cookie up front next time.

[-- Attachment #2: Type: text/html, Size: 1386 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
> On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@petertodd.org> wrote:
> 
> > UPNP seems to work well for the reference client. What's the situation
> > there on Android?
> >
> 
> Not sure - it could be investigated. I think UPNP is an entirely
> userspace-implementable protocol, so in theory it could be done by a
> userspace library (even libminiupnp - java is not a requirement on android)

Do find out.

> > I leave my phone plugged in and connected via wifi for most of the day;
> > lots of people do that.
> >
> 
> I suspect you mean "I think lots of people do that". I'm not so sure. We
> could potentially run an experiment in the Android app to measure how many
> users are in a position to contribute back, but just because you have wifi
> doesn't mean you can reconfigure it using UPnP. That helps a lot in home
> networks, but at the office it doesn't help.

Also worth finding out.

> I'm wary of a ton of work being put in to achieve not very much here.
> Satoshi's original vision was always that millions of users were supported
> by 100,000 or so nodes. I don't think that's unreasonable over the long
> term.

Appeal to authority.

Stop bringing up Satoshi's "vision" - our understanding of
crypto-currencies has improved in the 4.5 years since Bitcoin was
released. Satoshi didn't even forsee pool mining, which says a lot about
his economic judgement.

> Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side. Signing and checking
> can be passed onto the general ECDSA thread pool that works its way through
> pending signature operations, they'd be prioritised lower than checking
> blocks/broadcasts.

Right, so you're giving priority to peers that have been around for
awhile. You've succeeded in forcing attackers to wait a bit.

A) What's the definition of a peer? What stops me from pretending to be
100 peers?

B) Given an attacker willing to wait, what's your plan?

-- 
'peter'[:-1]@petertodd.org
000000000000004a52a297d9ae8ecde2ba62b681cc5a4cfbf7636032fc78e7d0

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]

A sane default that better protects users could be...

If (plugged into power) && (wifi) then non-bloom peers are OK.  It would
protect those users more than reliance upon on the smaller subset of bloom
nodes.  Scale back to the less secure behavior when battery and bandwidth
matters.

Warren


On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn <mike@plan99.net> wrote:

> That change was made in response to user complaints. Heck we get
> complaints about battery life and bandwidth impact even with Bloom
> filtering. We can't just randomly start using peoples bandwidth for
> relaying blocks, especially as I guess most SPV nodes are behind NAT.
>
> If Gavin is right and the future is dominated by mobiles and tablets, then
> it will require a change of thinking in how P2P networks work. I think
> there are plenty of people with private servers who would be willing to run
> nodes though. I'm not too worried about this.
>
>
> On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:
>
>> bitcoinj-0.10 release notes:
>>
>>    - We now require Bloom-capable (0.8+) peers by default and will
>>    disconnect from older nodes. This avoids accidental bandwidth saturation on
>>    mobile devices.
>>
>> Given the user-security concern that Peter brings up, reconsideration of
>> this new default behavior in SPV clients may be warranted.
>>
>>
>>
>> On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>>> > Doing this also makes it more difficult to sybil the network - for
>>> > instance right now you can create "SPV honeypots" that allow incoming
>>> > connections only from SPV nodes, thus attracting a disproportionate %
>>> of
>>> > the total SPV population given a relatively small number of nodes. You
>>> > can then use that to harm SPV nodes by, for instance, making a % of
>>> > transactions be dropped deterministicly, either by the bloom matching
>>> > code, or when sent. Users unlucky enough to be surrounded by sybil
>>> nodes
>>> > will have their transactions mysteriously fail to arrive in their
>>> > wallets, or have their transactions mysteriously never confirm. Given
>>> > how few full nodes there are, it probably won't take very many
>>> honeypots
>>> > to pull off this attack, especially if you combine it with a
>>> > simultaneous max connections or bloom io attack to degrade the capacity
>>> > of honest nodes.
>>>
>>> Oh, here's an even better way to do the "tx drop" attack: when you drop
>>> a transaction, make a fake one that pays the same scriptPubKeys with the
>>> same amount, and send it to the SPV peer instead. They'll see the
>>> transaction go through and show up in their wallet, but it'll look like
>>> it got stuck and never confirmed. They'll soon wind up with a wallet
>>> full of useless transactions, effectively locking them out of their
>>> money.
>>>
>>> Here's another question for you Mike: So does bitcoinj have any
>>> protections against peers flooding you with useless garbage? It'd be
>>> easy to rack up a user's data bill for instance by just creating junk
>>> unconfirmed transactions matching the bloom filter.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6688 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5620 bytes --]

There shouldn't be a "smaller subset of Bloom filtering nodes" because the
idea of making it optional is a stupid one.

If you're worried about DoS, come up with real fixes instead of trying to
break features that work.


On Sat, Aug 17, 2013 at 2:08 AM, Warren Togami Jr. <wtogami@gmail.com>wrote:

> A sane default that better protects users could be...
>
> If (plugged into power) && (wifi) then non-bloom peers are OK.  It would
> protect those users more than reliance upon on the smaller subset of bloom
> nodes.  Scale back to the less secure behavior when battery and bandwidth
> matters.
>
> Warren
>
>
> On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> That change was made in response to user complaints. Heck we get
>> complaints about battery life and bandwidth impact even with Bloom
>> filtering. We can't just randomly start using peoples bandwidth for
>> relaying blocks, especially as I guess most SPV nodes are behind NAT.
>>
>> If Gavin is right and the future is dominated by mobiles and tablets,
>> then it will require a change of thinking in how P2P networks work. I think
>> there are plenty of people with private servers who would be willing to run
>> nodes though. I'm not too worried about this.
>>
>>
>> On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:
>>
>>> bitcoinj-0.10 release notes:
>>>
>>>    - We now require Bloom-capable (0.8+) peers by default and will
>>>    disconnect from older nodes. This avoids accidental bandwidth saturation on
>>>    mobile devices.
>>>
>>> Given the user-security concern that Peter brings up, reconsideration of
>>> this new default behavior in SPV clients may be warranted.
>>>
>>>
>>>
>>> On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete@petertodd.org> wrote:
>>>
>>>> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>>>> > Doing this also makes it more difficult to sybil the network - for
>>>> > instance right now you can create "SPV honeypots" that allow incoming
>>>> > connections only from SPV nodes, thus attracting a disproportionate %
>>>> of
>>>> > the total SPV population given a relatively small number of nodes. You
>>>> > can then use that to harm SPV nodes by, for instance, making a % of
>>>> > transactions be dropped deterministicly, either by the bloom matching
>>>> > code, or when sent. Users unlucky enough to be surrounded by sybil
>>>> nodes
>>>> > will have their transactions mysteriously fail to arrive in their
>>>> > wallets, or have their transactions mysteriously never confirm. Given
>>>> > how few full nodes there are, it probably won't take very many
>>>> honeypots
>>>> > to pull off this attack, especially if you combine it with a
>>>> > simultaneous max connections or bloom io attack to degrade the
>>>> capacity
>>>> > of honest nodes.
>>>>
>>>> Oh, here's an even better way to do the "tx drop" attack: when you drop
>>>> a transaction, make a fake one that pays the same scriptPubKeys with the
>>>> same amount, and send it to the SPV peer instead. They'll see the
>>>> transaction go through and show up in their wallet, but it'll look like
>>>> it got stuck and never confirmed. They'll soon wind up with a wallet
>>>> full of useless transactions, effectively locking them out of their
>>>> money.
>>>>
>>>> Here's another question for you Mike: So does bitcoinj have any
>>>> protections against peers flooding you with useless garbage? It'd be
>>>> easy to rack up a user's data bill for instance by just creating junk
>>>> unconfirmed transactions matching the bloom filter.
>>>>
>>>> --
>>>> 'peter'[:-1]@petertodd.org
>>>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>> It's a free troubleshooting tool designed for production.
>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>> Download for free and get started troubleshooting in minutes.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 8415 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Jeff Garzik]

On Sat, Aug 17, 2013 at 8:35 AM, Mike Hearn <mike@plan99.net> wrote:
> There shouldn't be a "smaller subset of Bloom filtering nodes" because the
> idea of making it optional is a stupid one.
>
> If you're worried about DoS, come up with real fixes instead of trying to
> break features that work.

It is not just abstract worry.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[John Dillon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd <pete@petertodd.org> wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> Doing this also makes it more difficult to sybil the network - for
>> instance right now you can create "SPV honeypots" that allow incoming
>> connections only from SPV nodes, thus attracting a disproportionate % of
>> the total SPV population given a relatively small number of nodes. You
>> can then use that to harm SPV nodes by, for instance, making a % of
>> transactions be dropped deterministicly, either by the bloom matching
>> code, or when sent. Users unlucky enough to be surrounded by sybil nodes
>> will have their transactions mysteriously fail to arrive in their
>> wallets, or have their transactions mysteriously never confirm. Given
>> how few full nodes there are, it probably won't take very many honeypots
>> to pull off this attack, especially if you combine it with a
>> simultaneous max connections or bloom io attack to degrade the capacity
>> of honest nodes.
>
> Oh, here's an even better way to do the "tx drop" attack: when you drop
> a transaction, make a fake one that pays the same scriptPubKeys with the
> same amount, and send it to the SPV peer instead. They'll see the
> transaction go through and show up in their wallet, but it'll look like
> it got stuck and never confirmed. They'll soon wind up with a wallet
> full of useless transactions, effectively locking them out of their
> money.

Excellent, and makes a mockery of zero-confirmation transactions to boot.

Can be prevented by passing along txin proofs, but they require the full
transaction, so the effective UTXO set size would go up greatly post-pruning. I
am sure Mike would love to demand that full nodes do this for their peers
though, at least until UTXO commitments are greated, at great cost to full
nodes.

On the other hand, a tx with some txin proofs can be safely relayed by SPV
nodes, an interesting concept. Do the UTXO commitment people have keeping proof
size small in mind?

> Here's another question for you Mike: So does bitcoinj have any
> protections against peers flooding you with useless garbage? It'd be
> easy to rack up a user's data bill for instance by just creating junk
> unconfirmed transactions matching the bloom filter.

That is good too.

I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
Should be easy to do as a patch to satoshi bitcoin I think. The implementation
must include a RFC3514 compliant service bit to let peers know of the operators
intentions. Along those lines I'll donate 3BTC to adding service bit selection
to DNS seeds.

We should clearly show people the limitations of SPV before they depend too
much on it. Nothing wakes users up like a 21 million BTC transaction in their
wallet.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJSEYvxAAoJEEWCsU4mNhiPxI8IAJaWJ9s0YG3Ex5h8Dr6oPJ9M
uXTXa/Rt0DqS6mmyD9O80sXfgPbPbQa2rDL6imlqONaWfpXFZl2W9vxRGaZJ9wrr
3KBHzK8lasDOKqlEX92h8ZmQBjw4w5bK/heRLo1PnSZ8ojKn8+My1JvZWOPzF0Ct
tDXXuCE94csKuGRdmdDdVoXqy4XZaMQhHrGbrWVotQs1HzX3iK146GoGaZC0YyBx
cdWg/xDPtAxgb5zf2RSeNHfXeY0wZawe8vBxaS56gCRl54PG7fJvqL+YPcarNb1p
zEmahJjoyQHskjFeDpgEiXnWu3K3JGTSA5GvekWvBbJCcV4o1E6EI6LG0f1SfIs=
=12DC
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Mon, Aug 19, 2013 at 03:09:07AM +0000, John Dillon wrote:
> That is good too.
> 
> I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
> Should be easy to do as a patch to satoshi bitcoin I think. The implementation
> must include a RFC3514 compliant service bit to let peers know of the operators
> intentions. Along those lines I'll donate 3BTC to adding service bit selection
> to DNS seeds.

Would you please delay these bounties for a few weeks while things
settle down. The service bit selection is fine, but for the other two a
month would be appreciated.

Thanks

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[John Dillon]

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0HGGQ2WWylPMiczJmKmV4jrDd
6asoesEk5kH0IWM2xiY2re+/WkRVeNUlVT7R4+uIzQm/iMzKpIWNiF5a87x3+E9+
+KgJg1a4elKZ6UO4Bvov+Gw65u7q3eunVUYHUKfaLIUBDAO4Pc5vOCVNqAEIAJyT
qFTqTbV9XE+REN/1KVmRLgidcRcxnSFFnkUVUozdMev8oGqoW3iAs8rVr5DuSO/a
FW0UOdI9vBLC51+pdbBNoR9c1saheRbnTks67kLziQmuBFkly6cbLYUyh859pA3K
yjRaRLa1Q6IX76NZTdEc3F7XnfmMBwEFS2t9vSAqhFptAXlhnmKov+g7iJ8oaAWQ
361OcXvxPk6wmWKFroZIo1is0a3izoAcLFB9NWv7BU9I06XB3Gw5gVnzXQexTlV+
KHd8zeJYfc1IaPLdxefhp8tfrJIjAOXq9FmKjgB5Qki8cgCWM1pJIJK0t4XTVxI6
8LU1aldq5Qlond0aIBfS6QFErTFtVYmFLjl8YETcphBZAOSb6Rgudrz9mAL1brOu
fjg9aVTSTjWjFHflRFSpNKVjj+5zS93NMEEaNQmWjeexScw175DVKJoU6lnVFgfk
I7d+Lf5axVwlawZ+euN9YURE1azWUR4OECfDvd6Na8MGs+OwedbWP5/OfDGg2rzN
OG/SK5AxlrshrOmrY7emlMOhYIhd8A+KQ0ghLocTv8JVDvaIEnWkWEq4idhzOv4m
9xFmde45SOxy/PuReDEgGAS3S1IOMMzdkEH8yuzYf2cFzQ0d4PmHNn6NGDo9bEIV
Bjw9pqg5rg+8un14T3+c9ZbfkEvLB+sEQ9uVidg9jE1ZSH/l9XG0stbSnnDmAkYy
DbbA7WDsJ0fxQD1zvnDUlq84I2Fr5RwecOWuCUUUHGXdfe0AnxGL1k96Jd0t3BXj
JbY5fBUbN1QTuwqUSUBhE8uE7gGVZyWHel+DtKxwpIkpQ/CPLxFWJQL8oswN4Re+
CgS1Fs/P2MJdb0ht8cTTdFUEIKYW41eG84Vgpyn7gwd/IE1gPdpsDtoAV8uwIXsJ
WBHtYgO/cH3ofyITOcsm7gfkI3V4T87I3Sjrnk0ipa6fWh8dwhZnG1s5b7lKVgAp
QOqgWdjoP+4/FWCCpo9EVWqRfRU7js/TfuKOBiLDpKEkdmmuCOiMlxe5vt5FUHbq
wT0V5Iian5GcqZvJ/CZWzAxMY+qXu/OziI9Emvz5AA/yWymcHJl2M8RY+L+fVB67
/JSsHl0xQLHehKIFZKuTacy87pRHCoq7vA72lm+XCqC7+RojzPwODia7ShCfrZe2
YctdU/VWVMMgkpLcGxRMRFc2Rxbbge3kEQCt+b7lL7HVq0vsBoF4g3X4kzLxxyeD
JiR8PHknlWOjy5KgseKzTCt3sygvyJZrEPQ5SiBtoAkLgmEzkOxiy1DHrj59soM9
QY7L3XTLLOya4daL5+iZjZXm28JNXAYycAu3fyXx7rnbL6m/gcGjJZiuwwajMvmF
WvjbJBm9f5qOxK87ShnPj2ZwQ1w1nnz7i5oOdtELwUb96uMFegNDRSfMNpN4pmTh
2Qpffp9QZMEOxE+a7SnNjq5xG4S3qTnhdhTzQL5sIC+yJZ7L2gdbbrjdud2gcKRc
yQIkst51OIV6/xJ65AD6qzIcifpLm+u5/t6eVGLvw0G8u3gFHgelM1kPfX8iYDOR
CTDnJxx30/GXEvqD4/nCm5JytgolzH/PilBME1w2dPf845HebA0XCAhSoqdoLCvF
7jrllVCh/PDlK40XbO/cDYgXF7deDbgXVF2OBGc6qqAho3VE83ebR1wQWlUOyPIo
ScQyePNu500Yy/GUnwBK7029N4r6R1RBDn/rTsD/2w==
=6OvE
-----END PGP MESSAGE-----

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[John Dillon]

My apologies, that was for Peter

On Mon, Aug 19, 2013 at 5:00 AM, John Dillon
<john.dillon892@googlemail.com> wrote:
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
> G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
> GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
> eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0HGGQ2WWylPMiczJmKmV4jrDd
> 6asoesEk5kH0IWM2xiY2re+/WkRVeNUlVT7R4+uIzQm/iMzKpIWNiF5a87x3+E9+
> +KgJg1a4elKZ6UO4Bvov+Gw65u7q3eunVUYHUKfaLIUBDAO4Pc5vOCVNqAEIAJyT
> qFTqTbV9XE+REN/1KVmRLgidcRcxnSFFnkUVUozdMev8oGqoW3iAs8rVr5DuSO/a
> FW0UOdI9vBLC51+pdbBNoR9c1saheRbnTks67kLziQmuBFkly6cbLYUyh859pA3K
> yjRaRLa1Q6IX76NZTdEc3F7XnfmMBwEFS2t9vSAqhFptAXlhnmKov+g7iJ8oaAWQ
> 361OcXvxPk6wmWKFroZIo1is0a3izoAcLFB9NWv7BU9I06XB3Gw5gVnzXQexTlV+
> KHd8zeJYfc1IaPLdxefhp8tfrJIjAOXq9FmKjgB5Qki8cgCWM1pJIJK0t4XTVxI6
> 8LU1aldq5Qlond0aIBfS6QFErTFtVYmFLjl8YETcphBZAOSb6Rgudrz9mAL1brOu
> fjg9aVTSTjWjFHflRFSpNKVjj+5zS93NMEEaNQmWjeexScw175DVKJoU6lnVFgfk
> I7d+Lf5axVwlawZ+euN9YURE1azWUR4OECfDvd6Na8MGs+OwedbWP5/OfDGg2rzN
> OG/SK5AxlrshrOmrY7emlMOhYIhd8A+KQ0ghLocTv8JVDvaIEnWkWEq4idhzOv4m
> 9xFmde45SOxy/PuReDEgGAS3S1IOMMzdkEH8yuzYf2cFzQ0d4PmHNn6NGDo9bEIV
> Bjw9pqg5rg+8un14T3+c9ZbfkEvLB+sEQ9uVidg9jE1ZSH/l9XG0stbSnnDmAkYy
> DbbA7WDsJ0fxQD1zvnDUlq84I2Fr5RwecOWuCUUUHGXdfe0AnxGL1k96Jd0t3BXj
> JbY5fBUbN1QTuwqUSUBhE8uE7gGVZyWHel+DtKxwpIkpQ/CPLxFWJQL8oswN4Re+
> CgS1Fs/P2MJdb0ht8cTTdFUEIKYW41eG84Vgpyn7gwd/IE1gPdpsDtoAV8uwIXsJ
> WBHtYgO/cH3ofyITOcsm7gfkI3V4T87I3Sjrnk0ipa6fWh8dwhZnG1s5b7lKVgAp
> QOqgWdjoP+4/FWCCpo9EVWqRfRU7js/TfuKOBiLDpKEkdmmuCOiMlxe5vt5FUHbq
> wT0V5Iian5GcqZvJ/CZWzAxMY+qXu/OziI9Emvz5AA/yWymcHJl2M8RY+L+fVB67
> /JSsHl0xQLHehKIFZKuTacy87pRHCoq7vA72lm+XCqC7+RojzPwODia7ShCfrZe2
> YctdU/VWVMMgkpLcGxRMRFc2Rxbbge3kEQCt+b7lL7HVq0vsBoF4g3X4kzLxxyeD
> JiR8PHknlWOjy5KgseKzTCt3sygvyJZrEPQ5SiBtoAkLgmEzkOxiy1DHrj59soM9
> QY7L3XTLLOya4daL5+iZjZXm28JNXAYycAu3fyXx7rnbL6m/gcGjJZiuwwajMvmF
> WvjbJBm9f5qOxK87ShnPj2ZwQ1w1nnz7i5oOdtELwUb96uMFegNDRSfMNpN4pmTh
> 2Qpffp9QZMEOxE+a7SnNjq5xG4S3qTnhdhTzQL5sIC+yJZ7L2gdbbrjdud2gcKRc
> yQIkst51OIV6/xJ65AD6qzIcifpLm+u5/t6eVGLvw0G8u3gFHgelM1kPfX8iYDOR
> CTDnJxx30/GXEvqD4/nCm5JytgolzH/PilBME1w2dPf845HebA0XCAhSoqdoLCvF
> 7jrllVCh/PDlK40XbO/cDYgXF7deDbgXVF2OBGc6qqAho3VE83ebR1wQWlUOyPIo
> ScQyePNu500Yy/GUnwBK7029N4r6R1RBDn/rTsD/2w==
> =6OvE
> -----END PGP MESSAGE-----

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 8/18/13 8:09 PM, John Dillon wrote:
> On the other hand, a tx with some txin proofs can be safely relayed by SPV
> nodes, an interesting concept. Do the UTXO commitment people have
keeping proof
> size small in mind?
More than a kilobyte, probably less than a few tens of kilobytes. It
depends on parameters (branching factor, script vs hash(script)) that
are tweakable with time/space and long-term/short-term tradeoffs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSEakMAAoJEAdzVfsmodw4B9wQAIu82nxMAyMiTpFcWW6v0fQ9
26bzOznyIhzAlFUeCXvgwtqoxjRcheLOnsFsAr0TLdLYrx00o4+MS0GepV40gEpd
Ds/itvAnW8aWdCls0qy1hljWrsp8R3IfXWchXy13kjOhTIx8JaALeHEzOCsJVxCf
nWrV7UNLRO1eXhLUnFLnZ3/HdljMZnLqLexSGXorn4I2zwg5HGNMJxIenU3vDj8s
68k4rSk/eUptG97ZmJxCysn7nt5F1cxRutsVOPxsC/4+FptMYf9YJRJDNpvttYyl
ztI2xV+ARfEvSZs0lqGAcpvKwVV4IvZDGXhUCiS6LQ99tvMid4kjIGYPwlyK6SJW
LoYVbvjbauEIPn4URW8XilMB5EEJisr5/7ZV/aDLEFcBA/is5ePuQioo/81yOWUw
k5PghJ/TBMBQhxOGCz86onCI1YwrWfhu2sz6xNIHm9lbyZQcw3N/ai77FQqxxkxp
iBbIAvhk4sQ7lPt4QHmiL4isPzaiScKVTjvzfc5hAHSmu6xQysf8VA/SwUSgAJZB
iUPYRz5URaw8a/WDlo7YA6BRV/l7RloEcWGs6br3jVYxtJSaxqDwwrUV3SdDtzBR
uiE1OVPp8ihY3OJbnZkbvy3lXXlLjwrLVwMUgprhUo793QtktZH+O0V+StcGKLGD
4rdK6Z3C8Wx9FY2fvkBy
=HZdx
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

On Mon, Aug 19, 2013 at 5:09 AM, John Dillon
<john.dillon892@googlemail.com>wrote:

> > Here's another question for you Mike: So does bitcoinj have any
> > protections against peers flooding you with useless garbage? It'd be
> > easy to rack up a user's data bill for instance by just creating junk
> > unconfirmed transactions matching the bloom filter.
>

Unconfirmed transactions that are received show up as unspendable and in
most wallets they have a little graphic that changes as more peers announce
the tx. So if a peer sent non-existent transactions then they'd allow show
up as seen by only one peer, which would look different to how normal
broadcast transactions show up.

Whether users really notice this graphic or understand what it means is
debatable, of course, but all Bitcoin wallets have that problem. I've yet
to see any that would successfully communicate the notion of confidence to
new, untrained users. That's why the default is to not let you spend
unconfirmed transactions, unless they were created by yourself (you're
allowed to spend change).

bitcoinj does not attempt to handle DoS attacks by malicious remote peers
today, because such an attack has never been observed, has no obvious
profit motive and as you don't get to choose which nodes the wallets
connect to it'd be difficult to pull off. Unless you control the users
internet connection of course, but that's a well known caveat which is
documented on the website.

[-- Attachment #2: Type: text/html, Size: 1946 bytes --]