Economically Unspendable Outputs: A Problem On The Radar

[mobodick]

We can work on that and make it a perfect democracy. Actually, a lot of people is working on it if you haven't noticed.

A perfect democracy is hell for minority views.
Grey is the new grey.
Way to go.
 

[1713932507]

1713932507

[1713932507]

1713932507

[1713932507]

1713932507

[mobodick]

We can work on that and make it a perfect democracy. Actually, a lot of people is working on it if you haven't noticed.

A perfect democracy is hell for minority views.
Grey is the new grey.
Way to go.
 

What if there's no majority?
A hung parliament doesn't sound so uncommon, or bad. While the politicians are bickering over who to form coalitions with, a period of stability and prosperity ensues

Well, that also has a downside.
No decisions would be taken even if they were nessesary.
I can't stress enough that any good system has both rigid and flexible parts.
Too rigid or too flexible and it can not work.
In between is a field of stable change and adaptation.

[ThiagoCMC]

To be fair, it is paid for by fees which are bigger than all other sources combined, and will get bigger because of the 0.5% change. Which means it is not spam, but a type of high-volume flow which, arguably, Bitcoin is not ready for.

The current fees are there to deter flooding, not to justify it. Even with fees, transactions are still being mostly subsidized by miners.

Last I heard the miners are being subsidized by the market assigning $1150 to the block reward, even if no transactions are included!

Since "flooding" is being evidenced by "dead puppies" then one solution lies in this approach:

For sources which exhibit dead puppy behavior the fee required for inclusion in a block needs to increase exponentially for each additional transaction

Up front I will say this is a technical challenge, but not impossible, and there are some very capable people here who could take a shot at it.

SatoshiDice needs to keep going so that when a change like above is made it will organically force a change in behavior (which will be SD internalizing or netting transaction flow). Then we can have some confidence that a recognized attack vector is blocked.

Can we make, at least, some kind of "dead puppies" alarm?

[solex]

Can we make, at least, some kind of "dead puppies" alarm?

This is the situation. The alarm is sounding already!

...A transaction is considered DP involved if it pays to an identified DP address or if any of its inputs paid to an identified DP address.

Height  Size    Amount of DP-involved.
224737 163012 82.0755%
224736 498888 94.9111% (!)
224734 249140 93.4021%
224732 498991 85.5789%
224728 249091 80.2395%

...the supply of these transactions seems to be basically unbounded it seems likely that adjustments to block target sizes are unlikely to produce faster confirmations at this time.

(my bold emphasis)

The block 224736 is 1/2Mb, which is the biggest they get at the moment, and it is almost 95% full of SatoshiDice bets.  This type of transaction source is indeed basically unbounded as the number of users it has is a tiny fraction of the potential audience. Further, an uptake of bot usage will alleviate the "bottleneck" of humans pushing a button, ensuring that bets can hit the blockchain at an ever increasing rate.

We just had a monumental debate about the 1Mb max block size limit on this forum, and the significant reason for that debate is that it is a hard fork. Yet the growth of this type of transaction flow makes the hard fork almost inevitable in 2013 whereas it might not need doing until 2015 at the growth rate of all the non-SD business. Needless to say, a hard fork is best executed when everyone has the maximum time to upgrade at their own pace beforehand.

I do not blame SD one iota as they are using functionality as it is presented. There is a weakness which Bitcoin has at present for "flooding" by legitimate fee-paying transactions. The answer is to slowly push back when the loading becomes excessive so that transaction sources have an incentive to optimize.

Unfortunately, a number of people consider this to be the appropriate response:

[Brushan]

Can't the bitcoin clients make it impossible to make transactions of less than, for example, 1/10 of a cent worth of BTC.
IMO it wouldn't make much difference for the daily user and the limit can be lowered gradually in steps as BTC rises in value.
Or am i missing something?

[Luke-Jr]

Can't the bitcoin clients make it impossible to make transactions of less than, for example, 1/10 of a cent worth of BTC.
IMO it wouldn't make much difference for the daily user and the limit can be lowered gradually in steps as BTC rises in value.
Or am i missing something?

That's something miners have to do, basically.
And most of the big ones are already neglecting to care, so good luck with that :/

[conspirosphere.tk]

I thought that the fees would somehow automatically rise in cases of high traffic.
Would not that be the most market-friendly and efficient solution?

[Prattler]

I thought that the fees would somehow automatically rise in cases of high traffic.
Would not that be the most market-friendly and efficient solution?

At the moment a transaction only needs a fee of 0.0005 BTC, but costs the network ~$.10 in storage alone (for the full duration it's not spent). The fee doesn't go to the network however, it goes to the miner. Miners have the incentive to include as much transactions as possible.

See
https://bitcointalk.org/index.php?topic=151329.msg1608087#msg1608087
https://bitcointalk.org/index.php?topic=151329.msg1608413#msg1608413

[bitlybit]

haha bitcoin not flawed look now today is value 48 dollar by end this year 1000 dollar no flaw in this syste just hold value up rich

[tacotime]

Just get BTCGuild, 50BTC, DeepBit, and Slush to remove all transactions that don't have at least a 0.01 BTC fee attached to them or which don't have at least 0.01 BTC per each output.  The solution is really, really easy and makes miners more money.  Miners have room to be greedy.

Clients will learn real quick to incorporate fees, and SD will learn real quick to stop making these spam transactions.  There's no reason that SatoshiDice just couldn't present the user with a page for each transaction showing if they won or lost, and use up their own server space instead of that of the block chain.

It's not even remotely a problem, the pools just need to act now to preserve the integrity of the block chain.  And I'm guessing we'll see this within the next month or two, and SD will be forced to change its ways.

[Prattler]

Just get BTCGuild, 50BTC, DeepBit, and Slush to remove all transactions that don't have at least a 0.01 BTC fee attached to them or which don't have at least 0.01 BTC per each output.  The solution is really, really easy and makes miners more money.  Miners have room to be greedy.

Clients will learn real quick to incorporate fees, and SD will learn real quick to stop making these spam transactions.  There's no reason that SatoshiDice just couldn't present the user with a page for each transaction showing if they won or lost, and use up their own server space instead of that of the block chain.

It's not even remotely a problem, the pools just need to act now to preserve the integrity of the block chain.

Miners should care about the policy of the mining pool they are mining for. They should ask for something similar to https://bitcointalk.org/index.php?topic=151335.msg1605900#msg1605900 to be implemented on their pool.

In practice, miners and mining pools don't tend to care for bitcoin long term.

[solex]

Memo. When the chain fork is resolved and post-mortem out the way, ask gmaxwell how many dead puppies are in block 225430 on the 0.8 chain.

And now a more elaborate explanation:

0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept "too large" blocks (we don't yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.

However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.

The solution is to (for now) go back to the old chain, which has block 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430.

[misterbigg]

I have to give credit where credit is due. evoorhees appeared in #bitcoin-dev and temporarily shut down SatoshiDICE to make things easier for the mining pools and developers to fix the problem with 0.7 and the forked block chain. I believe this thread has been successful at raising awareness of the issues. It is unfortunate that it had to be done this way but Bitcointalk is a rough-and-tumble place.

Now that all the players are aware of the issues, the noisy replies have overcome the signal, and that SatoshiDICE showed some good faith I think it's time to lock this. Thanks to everyone who participated!