Topic: WARNING! Bitcoin will soon block small transaction outputs - page 3. (Read 58538 times)

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

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.

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.

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.

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.

He didn't "block any output with a value of less than 54uBTC"... he set the default value that nodes block to 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.

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

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.

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://bitcointalksearch.org/topic/bitcoin-addon-distributed-block-chain-storage-197810

The short answer is Gavin gave us the tools to choose. He gave us free will with regard to bitcoin.  Picture a football field filled with 10,000 people, each one keeping track of transactions, Your the guy on the 10 yard line next to the guy in a wheres waldo outfit.

With this change you as an individual can choose what message you will or wont pass on to the people around you. Before the change you didnt have this choice, you didnt have free will. you had to blindly pass on what was given to you.

If enough people choose to not pass on certain transactions the message wont go anywhere even if you send it. But its not as simple as blocking stuff to be mean. its a matter of each individual deciding what is and isnt good to send. If you cant make this choice due to lack of information, they are kind enough to have a default set. (Keep in mind, in versions before 0.8.2, you had no choice in this. Your client had a built in number, you either used it or you didnt use bitcoin.)

This number was set to a default value that fits bitcoin at its current value. That means if you try to send something below that value, the network would ignore it. if its over that value, they pass it on. But everyone can choose what to set, What they will ignore and what they will pass on.

being against the change is being against your ability to choose.

Again, I dont understand - how can Gavin change anything, other than what a new release
of a client does -
If I continue to use an older client , why / how would my small transactions be blocked ??

do you have a problem reading, sir?

go educate yourself: https://en.bitcoin.it/wiki/Protocol_specification

Hi, im just curious where exactly your pool stands on this issue.. so let me ask...

If i have 500 dust transactions sitting in my wallet and i wanted to tidy them all up. Can i make a transaction sending them all to one address and include no fee.. (or just the default fee of .0001 and have your pool mine it?

Or, you could just set your -minrelaytxfee option to something lower than the default.  Much easier than "modifying the reference client".

Well at this time the client doesn't "know" if a miner will include a particular transaction or if it will even be relayed to a miner.  The end state is like a higher level "fee/node/miner discovery" protocol which would allow the client to make intelligent predictions on if a transaction will be relayed/mined, how long it will take and how much improvement in expected confirmation time an increased fee produces.

Unfortunately if you relay a transaction that is unlikely to get mined you make the whole Bitcoin network vulnerable to DoS attacks by flooding it with transactions; essentially you are using network bandwidth without paying for it. Gavin wants to make the dust limit adaptive to what miners actually mine, but doing so won't be easy and P2P layer changes are always risky.

As always, if you feel strongly that you want your pool to mine such transactions and want to let people create them, you can always advertise a node to submit such tx's to directly. In fact I think it's enough to just connect your pool's nodes to 173.242.112.53, which relays any transaction indiscriminately regardless of fee or even if it passes the IsStandard() test.

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.

How is this a problem for you? EMC is a mining pool and can mine whatever transactions they want.

Agreed.  I understand Inaba's frustration in being burned by this once, but it should be pretty easy to update your code to just filter out tiny payments.  Alternatively, remove the dust threshold and mine the payouts yourself, but please consider DeathAndTaxes' stats (I haven't verified them myself) about how tiny outputs hardly ever get spent -- your own mining nodes will bear the permanent UTXO bloat cost of uneconomical payouts to your users.