WARNING! Bitcoin will soon block small transaction outputs

[lucif]

I propose more efficient solution of spam problem.

Don't use hardcode.

Just lets develop ultimate storage which will not give a fuck about spam.

https://bitcointalk.org/index.php?topic=197810.0

[Eri]

I propose more efficient solution of spam problem.

Don't use hardcode.

Just lets develop ultimate storage which will not give a fuck about spam.

https://bitcointalk.org/index.php?topic=197810.0

1. It may sound harsh but your solution seems pointless for now.
2. Your 'ultimate storage' grows with more users, but so does the amount of spam produced. It would solve nothing. I like many others would still prefer to store the entire chain.
3. Current fix = limited/no spam.
4. Pruning, would remove all spent transactions that are 2(?) transactions back since they wouldnt be needed, dramatically reducing the size of the blockchain. At which point your solution is entirely moot since anyone could store whats left of it without issue.
5. Storage devices are getting cheaper and larger every day and so is memory. im sure if it were needed at some point in the future someone could build a custom board with a crazy amount of memory on it to store the UTXO set. With the speed memory runs at im sure someone could make a slower, cheaper, larger ramdisks for this purpose.

[qrs]

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

It's true, last payment less than 54 uBTC was on 12th June What if someone send me less than 54 uBTC? 

[Eri]

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

It's true, last payment less than 54 uBTC was on 12th June What if someone send me less than 54 uBTC?  

The update isnt widely adopted enough to be effective yet.

The change only tries to prevent you from *Creating* outputs that small. It does nothing to prevent you from spending money you have, even if its just 1 satoshi.(edit: it just needs to be higher then 54ubtc if the public adopts the .0001 btc as the current normal fee)


(light reading)

The Fees to send many small bits of bitcoin will be higher then normal because of how fees work. Its why were trying to prevent people from sending you tiny transactons, It costs you more money then they are worth.

[boonies4u]

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

It's true, last payment less than 54 uBTC was on 12th June What if someone send me less than 54 uBTC? 

He didn't "block any output with a value of less than 54uBTC"... he set the default value that nodes block to 54 uBTC.

[DeathAndTaxes]

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

It's true, last payment less than 54 uBTC was on 12th June What if someone send me less than 54 uBTC? 

1) Update the config of his node to allow smaller outputs (it is a single line of text in the bitcoin.config file).
2) Update the config of your node to allow smaller outputs
3) Find a miner willing to include transactions with smaller outputs in a block.
4 optional) Convince enough nodes to relay these smaller transactions so you don't need to send them direct to willing miner(s).

Transactions with outputs smaller than the dust threshold (54.3% of min mandatory fee on low priority transactions) are still valid.

[scintill]

Mining of transactions aren't a problem, and EMC continues to mine dust outputs.  However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client.  That's my issue/beef with this.  The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.

The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.

I agree it would be better to be more dynamic.  Now I'm confused as to how this affects EMC (it just sounds like compatibility testing); why you need to send such small amounts; and whether you consider changing some configuration settings, which others have mentioned, to be "modifying" the client.

[DeathAndTaxes]

Mining of transactions aren't a problem, and EMC continues to mine dust outputs.  However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client.  That's my issue/beef with this.  The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.

The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.

I agree it would be better to be more dynamic.  Now I'm confused as to how this affects EMC (it just sounds like compatibility testing); why you need to send such small amounts; and whether you consider changing some configuration settings, which others have mentioned, to be "modifying" the client.

I would be interested in that to.  Unless there is something wrong with my account (haven't mined in a long time), it looks like minimum payout is 0.02 BTC (360x higher than the default dust threshold) and that min existed before the client change.

[Inaba]

PPS in it's purest form requires the sending of small amounts.  Now, you can argue for various modifications to pure PPS to overcome this particular problem, but fundamentally it kills pure PPS pools.  It makes it impossible to get paid for 1 share (quite a bit more than 1 actually, but it's the same issue), so the pool is no longer PPS, but PPsS.

[DeathAndTaxes]

PPS in it's purest form requires the sending of small amounts.  Now, you can argue for various modifications to pure PPS to overcome this particular problem, but fundamentally it kills pure PPS pools.  It makes it impossible to get paid for 1 share (quite a bit more than 1 actually, but it's the same issue), so the pool is no longer PPS, but PPsS.

It is impossible to get paid for a difficulty 1 share but shares doesn't have to be difficulty 1.  Why couldn't one use a higher difficulty share?

Revenue per difficulty 1 share: 25 BTC / 21,335,329.114 * 1E8 = 117 S ea (at current difficulty)
Dust Threshold: 5430 S
Maximum # of independently payable shares per BTC of block reward: 1E8 / 5430 = 18,416

Min pure PPS share difficulty: (block difficulty) / (18,416 * current block subsidy)

Min pure PPS share difficulty (at current difficulty & 25 BTC block): ( 21,335,329.114) / (18,416 * 25 ) = 46 diff.
Value of difficulty 46 share = 25 * 46 / 21,335,329.114 * 1E8 = 5390 S ea
At difficulty 47 a 1 GH/s miner will find ~ 17 shares per hour (average time between share 201 seconds)

For simplicity I would round to nearest 10 difficulty and change every difficulty adjustment.  Too easy.  The last 8 difficulty periods would be

Code:

Period             Share diff    Value per share
------------------------------------------------
04/05/2013	      20 diff    6516 S
04/17/2013	      20 diff    5571 S
04/29/2013	      30 diff    4962 S
05/12/2013	      30 diff    4469 S
05/25/2013	      30 diff    4114 S
06/05/2013	      40 diff    3203 S
06/16/2013	      50 diff    2585 S
06/29/2013	      50 diff    2343 S

[Syke]

PPS in it's purest form requires the sending of small amounts.  Now, you can argue for various modifications to pure PPS to overcome this particular problem, but fundamentally it kills pure PPS pools.  It makes it impossible to get paid for 1 share (quite a bit more than 1 actually, but it's the same issue), so the pool is no longer PPS, but PPsS.

1 share is worth about 1/100th of a penny. I'm ok with bitcoin not being able to flood the blockchain with .01c payments.

[Eri]

PPS in it's purest form requires the sending of small amounts.  Now, you can argue for various modifications to pure PPS to overcome this particular problem, but fundamentally it kills pure PPS pools.  It makes it impossible to get paid for 1 share (quite a bit more than 1 actually, but it's the same issue), so the pool is no longer PPS, but PPsS.

Does your pool use 'pure PPS'?

[Inaba]

PPS in it's purest form requires the sending of small amounts.  Now, you can argue for various modifications to pure PPS to overcome this particular problem, but fundamentally it kills pure PPS pools.  It makes it impossible to get paid for 1 share (quite a bit more than 1 actually, but it's the same issue), so the pool is no longer PPS, but PPsS.

It is impossible to get paid for a difficulty 1 share but shares doesn't have to be difficulty 1.  Why couldn't one use a higher difficulty share?

Revenue per difficulty 1 share: 25 BTC / 21,335,329.114 * 1E8 = 117 S ea (at current difficulty)
Dust Threshold: 5430 S
Maximum # of independently payable shares per BTC of block reward: 1E8 / 5430 = 18,416

Min pure PPS share difficulty: (block difficulty) / (18,416 * current block subsidy)

Min pure PPS share difficulty (at current difficulty & 25 BTC block): ( 21,335,329.114) / (18,416 * 25 ) = 46 diff.
Value of difficulty 46 share = 25 * 46 / 21,335,329.114 * 1E8 = 5390 S ea
At difficulty 47 a 1 GH/s miner will find ~ 17 shares per hour (average time between share 201 seconds)

For simplicity I would round to nearest 10 difficulty and change every difficulty adjustment.  Too easy.  The last 8 difficulty periods would be

Code:

Period             Share diff    Value per share
------------------------------------------------
04/05/2013	      20 diff    6516 S
04/17/2013	      20 diff    5571 S
04/29/2013	      30 diff    4962 S
05/12/2013	      30 diff    4469 S
05/25/2013	      30 diff    4114 S
06/05/2013	      40 diff    3203 S
06/16/2013	      50 diff    2585 S
06/29/2013	      50 diff    2343 S

You could, but as I said, that is a different matter all together.  A fundamental building block of PPS is the difficulty 1 share, since it's the basis of everything else.  Whether or not it matters if you can pay a difficulty 1 share is another discussion, not really germane to this particular issue.

47 difficulty is way too high for some miners.  Take a Block Erupter for example, at 300 MH/s - it will never get paid in your scenario.  Whether mining is worth it at less than 47 difficulty is a different exercise, though.  As difficulty climbs, the situation worsens for the low hashrate miners.

PPS in it's purest form requires the sending of small amounts.  Now, you can argue for various modifications to pure PPS to overcome this particular problem, but fundamentally it kills pure PPS pools.  It makes it impossible to get paid for 1 share (quite a bit more than 1 actually, but it's the same issue), so the pool is no longer PPS, but PPsS.

Does your pool use 'pure PPS'?

It did, until now.

[Syke]

47 difficulty is way too high for some miners.  Take a Block Erupter for example, at 300 MH/s - it will never get paid in your scenario.

Never? 300 MH/s will generate roughly 5 47-difficulty shares per hour.

[DeathAndTaxes]

You could, but as I said, that is a different matter all together.  A fundamental building block of PPS is the difficulty 1 share, since it's the basis of everything else.

Difficulty 1 = requires on average 2^32 hashes.  This is an utterly artificial distinction.  Satoshi could have made difficulty 1 require an average of 2^64 hashes and block difficulty would be 0.005355 today.  It would work just as well.  Hell if you wanted to you could accept sub 1 difficulty shares.  Not much point especially as miners get fast but you could. 

There is nothing "fundamental" about difficulty 1 hashes other than you have always done it.  Eventually given a high enough hash rate the value of a difficulty 1 share will be less than 1 satoshi.  What then?  Failure of the PPS pool model?

47 difficulty is way too high for some miners.  Take a Block Erupter for example, at 300 MH/s - it will never get paid in your scenario.

Um shares are probabilistic.  It will take a miner an average of 197,568,495,616 attempted hashes to find one which meets difficulty 46 target.  While the time between shares is random, in the long run a 300 MH/s miner will find one difficulty 46 shares for every 658 seconds spent mining.  A 300 MH/s miner, mining for a full 24 hours would be expected to find 131 diff-46 shares.  The miner will find 1/46 as many diff-46 shares as diff-1 shares in a given period of time however the diff-46 shares will be worth 46x as much.

Not sure if you are posting without enough sleep but you should know better than most that the only difference between shares (of any difficulty) and block solutions is reduced difficulty.  That is it.  Current block difficulty is ~21 million.  A diff 1 share is ~21 million times easier to find than a block.  A diff 46 share is ~456,000 times easier to find than a block.   The difference between diff-1 and diff-46 is negligible compared to the difference between either and full block difficulty. 

[scintill]

It did [run "pure PPS"], until now.

What exactly stopped you from continuing that?  Why wouldn't a "pure PPS" pool just mine their own dusty payouts?  In some nonsensical scenario where the pool won't mine their own dusty payouts but enough of the network will relay/mine them, why not just change the threshold in the configuration file?  Earlier you said it was about the "reference client"; a pool running an unconfigured reference client doesn't need to be coddled so this argument doesn't make sense IMO.  Change the threshold and/or mine your own payouts, I don't understand why that's a problem.  You are the pool operator and I'm not, so by all means set me straight if I'm missing something.

[legitnick]

The more people who run a full node, the greater the decentralization[1][2].

Using the chain as data storage, rather than currency, costs everybody, because it increases the rate at which people are discouraged from running full nodes.  It increases the costs of that dataset that cannot be pruned, and must be carried for eternity: the unspent transaction output set (UTXO), the list of coins available for spending.

Right now, it remains within the realm of a hobbyist to run a full node, especially with the recent memory usage improvements in bitcoind.  But one day, that will not be the case.

By pushing back on data spam, we reduce the rate-of-increase on blockchain resource costs, and reduce the disincentive to run a full node.  We push back the day at which there are just a handful of archive nodes with a copy of the full block chain.

[chmod755]

So I'm not the only one who doesn't want to store thousands of tiny fractions, that are basically unspendable (or at least very expensive to spend) for other people.

It's easy to change online services to make them compatible with this and it can be changed back to a lower limit, if it's reasonable.

Do you guys always pay with $/€/... 0.01 coins?

Scalability & making it less expensive (in terms of storage) to run a full node is more important right now. Well done, Mr. Andresen.

[daemondazz]

Do you guys always pay with $/€/... 0.01 coins?  

For some reason my mortgage broker refused to allow me to pay for my house with 30 million 1c coins...

[chmod755]

For some reason my mortgage broker refused to allow me to pay for my house with 30 million 1c coins...

Of course, because you tried to bloat his wallet with ~70 tons of coins.