Bitcoin Forum
March 28, 2024, 08:47:57 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: coin selection vs low value spam: non-deterministic failure  (Read 990 times)
Strider Hiryu (OP)
Newbie
*
Offline Offline

Activity: 29
Merit: 0



View Profile
August 25, 2012, 08:20:48 PM
 #1

If I run this program (v 0.6.99 on a testnet3-box with about 200 BTC balance), it succeeds about 1500 times and then fails with 'Error: Transaction creation failed, code: -4'.

Code:
b = jsonrpc.ServiceProxy(...)
for i in xrange(100000):
    print i
    a = b.getnewaddress('')
    b.sendtoaddress(a, 0.00000001)

debug.log shows: 'SelectCoins() best subset: ...' trying to pick up a massive set of small inputs.

Increasing the send amount usually gets it working again, but decreasing it back either fails immediately or eventually.

Isn't the implication here that you could destabilize a site by spamming them with low value transactions?  And increase their transaction fees when SelectCoins randomly picks up the low value inputs.

I think the solution for the coin selection is to sort the inputs from least 'encumbered' to most 'encumbered' (the value-age heuristic used to calculate tx fees), and just pick the inputs off the top, spam would then never get touched.  Possibly see how many inputs from the most 'encumbered' end can be included without increasing the transaction fee (to slowly eat the spam).  Or some clever global optimization.

Either way I think coin selection probably has to minimize the current transaction fee.
"There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711615677
Hero Member
*
Offline Offline

Posts: 1711615677

View Profile Personal Message (Offline)

Ignore
1711615677
Reply with quote  #2

1711615677
Report to moderator
1711615677
Hero Member
*
Offline Offline

Posts: 1711615677

View Profile Personal Message (Offline)

Ignore
1711615677
Reply with quote  #2

1711615677
Report to moderator
1711615677
Hero Member
*
Offline Offline

Posts: 1711615677

View Profile Personal Message (Offline)

Ignore
1711615677
Reply with quote  #2

1711615677
Report to moderator
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
August 25, 2012, 08:55:17 PM
Last edit: August 25, 2012, 10:01:20 PM by Stephen Gornick
 #2

Isn't the implication here that you could destabilize a site by spamming them with low value transactions?  And increase their transaction fees when SelectCoins randomly picks up the low value inputs.

That's one risk you face when using a static Bitcoin address.   If your service gives a unique address per payment there is less chance of this being a problem.  But someone could repeatedly send spam-like amounts to inflict pain on the recipient.  A coin selection method that ignores amounts under a certain threshold when otherwise including them would increase the fee would neutralize that threat.

The only ones complaining about it so far are those who are getting the dust spam from their losing bets from SatoshiDICE, so that is self-inflicted pain.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
August 25, 2012, 09:15:10 PM
 #3

Isn't the implication here that you could destabilize a site by spamming them with low value transactions?  And increase their transaction fees when SelectCoins randomly picks up the low value inputs.
The attacker will pay transaction fees to send those spammy inputs, and that has been a large enough disincentive that it hasn't happened.

That said, SelectCoins aught to be improved; ideally, it should never include an input if the fee for adding that input is greater than that input's value.

Or maybe it should just ignore inputs below the 'spam transaction' threshold for now, as being more trouble than they're worth.


How often do you get the chance to work on a potentially world-changing project?
Strider Hiryu (OP)
Newbie
*
Offline Offline

Activity: 29
Merit: 0



View Profile
August 26, 2012, 01:00:35 PM
 #4

Isn't the implication here that you could destabilize a site by spamming them with low value transactions?  And increase their transaction fees when SelectCoins randomly picks up the low value inputs.
The attacker will pay transaction fees to send those spammy inputs, and that has been a large enough disincentive that it hasn't happened.

That said, SelectCoins aught to be improved; ideally, it should never include an input if the fee for adding that input is greater than that input's value.

Or maybe it should just ignore inputs below the 'spam transaction' threshold for now, as being more trouble than they're worth.

https://bitcointalk.org/index.php?topic=63877.msg1038709#msg1038709

Anyways this was triggered by someone spamming the wallet with a very larger number of small transactions, of course I've always known this could be an issue but dealing with it is mostly a matter of money I didn't do anything about it.

I knew I saw that somewhere. That's an Intersango owner/dev I believe.

An end user's rational self-interest is total transaction fee minimization. I think this means that some approximation of total transaction fee minimization has to become the dominant coin selection method.

And the current coin selection solves some other problem. I think the way to look at it is this: you have some age-weighed inputs, some fee associated with a send from them, a discount rate that you are willing to trade a current transaction fee reduction for a future reduction, I suspect you might need estimates for average transaction size and time between transactions: the function to minimize would be the sum of discounted transaction fees, and in the absence of a clever solution, a stochastic/brute force/heuristic solution will do the job.

btw, I don't think a 'recent coin' premium can survive market forces. The miners who set the transaction fee, I assume will be constrained by block size, meaning that transaction size is the 'scarcity' that will determine fees. Which means that miners have an inventive to charge a linear fee per transaction size alone since coin age doesn't concern them (too much - I guess there is some risk premium for reversed spends).
phantomcircuit
Sr. Member
****
Offline Offline

Activity: 463
Merit: 252


View Profile
August 26, 2012, 05:51:40 PM
 #5

Isn't the implication here that you could destabilize a site by spamming them with low value transactions?  And increase their transaction fees when SelectCoins randomly picks up the low value inputs.
The attacker will pay transaction fees to send those spammy inputs, and that has been a large enough disincentive that it hasn't happened.

That said, SelectCoins aught to be improved; ideally, it should never include an input if the fee for adding that input is greater than that input's value.

Or maybe it should just ignore inputs below the 'spam transaction' threshold for now, as being more trouble than they're worth.

https://bitcointalk.org/index.php?topic=63877.msg1038709#msg1038709

Anyways this was triggered by someone spamming the wallet with a very larger number of small transactions, of course I've always known this could be an issue but dealing with it is mostly a matter of money I didn't do anything about it.

I knew I saw that somewhere. That's an Intersango owner/dev I believe.

An end user's rational self-interest is total transaction fee minimization. I think this means that some approximation of total transaction fee minimization has to become the dominant coin selection method.

And the current coin selection solves some other problem. I think the way to look at it is this: you have some age-weighed inputs, some fee associated with a send from them, a discount rate that you are willing to trade a current transaction fee reduction for a future reduction, I suspect you might need estimates for average transaction size and time between transactions: the function to minimize would be the sum of discounted transaction fees, and in the absence of a clever solution, a stochastic/brute force/heuristic solution will do the job.

btw, I don't think a 'recent coin' premium can survive market forces. The miners who set the transaction fee, I assume will be constrained by block size, meaning that transaction size is the 'scarcity' that will determine fees. Which means that miners have an inventive to charge a linear fee per transaction size alone since coin age doesn't concern them (too much - I guess there is some risk premium for reversed spends).



For the vast majority of people this isn't really a problem.

Tons of tiny bitcoin transfers are a good thing for most people as they get to keep them.

We're fairly unique in that we dont keep any part of the transfer (not even a small fixed fee).

For most people though the incentives are to not spam people with small transactions.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!