Author

Topic: coin selection vs low value spam: non-deterministic failure (Read 1021 times)

sr. member
Activity: 463
Merit: 252
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://bitcointalksearch.org/topic/m.1038709

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.
newbie
Activity: 29
Merit: 0
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://bitcointalksearch.org/topic/m.1038709

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).
legendary
Activity: 1652
Merit: 2301
Chief Scientist
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.

legendary
Activity: 2506
Merit: 1010
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.
newbie
Activity: 29
Merit: 0
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.
Jump to: