Bitcoin Forum
March 28, 2024, 09:59:34 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: An alternative to spamming the Blockchain  (Read 850 times)
johoe (OP)
Full Member
***
Offline Offline

Activity: 217
Merit: 238


View Profile
June 10, 2015, 01:58:50 PM
 #1

If we want to test how Bitcoin behaves if the blocks are nearly full under realistic conditions, there is an alternative to spamming the Blockchain.  We could try to convince the top miners to decrease their soft limit on the block size.  For example if most miners limit themselves to produce only 300 KB blocks we should see what happens if the blocks get full and the memory pools grow in size.

I'm not sure how easy it is to get most miners to participate in this experiment.  They should not have any disadvantages by doing this (following the logic of some people they should even gain something due to fee pressure) Anyways, the fee is about 2-3% of the block reward and the lower orphan rate should easily make up for the missed transaction fees.  If the transaction congestion has negative effects it is easy for them to revert the block size limitation.  And every miner can choose to participate or not immediately without the need for consensus (of course we only see an effect if most do).

The 300 KB limit is just a suggestion, considering that the current average block size is above 300kb; I expect that many miners are not participating.  Of course, every miner can adjust the limit arbitrarily to add or release some pressure.

I fear there is no way to do this experiment on TestNet since what we really want to test are economic choices.  E.g., it should show if users pay more transaction fees, or if they send fewer transactions.  This experiment may actually have bad effects, e.g. making Bitcoin transactions unreliable and leading to increased 0-confirmation double spends, but at least it is easy to revert the soft block limit if there are serious problems.

Donations to 1CF62UFWXiKqFUmgQMUby9DpEW5LXjypU3
1711619974
Hero Member
*
Offline Offline

Posts: 1711619974

View Profile Personal Message (Offline)

Ignore
1711619974
Reply with quote  #2

1711619974
Report to moderator
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711619974
Hero Member
*
Offline Offline

Posts: 1711619974

View Profile Personal Message (Offline)

Ignore
1711619974
Reply with quote  #2

1711619974
Report to moderator
unamis76
Legendary
*
Offline Offline

Activity: 1512
Merit: 1003


View Profile
June 10, 2015, 06:06:55 PM
 #2

Although this a pretty interesting idea, I think it would definitely cause chaos in the production network in just a few blocks after adapting the change...

Is it worth it for merchants and people sending transactions to have this experiment going when we have almost full blocks happening? It would definitely be interesting to hear devs/experts about this.
johoe (OP)
Full Member
***
Offline Offline

Activity: 217
Merit: 238


View Profile
June 10, 2015, 07:10:48 PM
 #3

Quote from: unamis76 link=topic=1086436.msg11584973#msg11584973  date=1433959615
Although this a pretty interesting idea, I think it would definitely cause chaos in the production network in just a few blocks after adapting the change...

Only if almost all miner implemented this change at the same time.  I expect that initially there are still enough miners that clean up the queued up transactions regularly. So it would have first only minor effect -- maybe some larger delays -- until enough miners adopt this change.

If you are afraid of this, the miners could also set the soft limit to 500 kb and wait until we reach this soft limit.  If something bad happen some miners can easily adapt within a few hours by setting a higher limit.  It is much better than if we wait until we reach the hard limit and then need two months to deploy an emergency hard fork if something bad happens.

Donations to 1CF62UFWXiKqFUmgQMUby9DpEW5LXjypU3
Newar
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000


https://gliph.me/hUF


View Profile
June 11, 2015, 02:24:36 AM
 #4

[...] and then need two months to deploy an emergency hard fork if something bad happens.

Where do you get two months from? The last time there was an "emergency hard fork" situation the matter was resolved in ~ two days, IIRC.

OTC rating | GPG keyid 1DC91318EE785FDE | Gliph: lightning bicycle tree music | Mycelium, a swift & secure Bitcoin client for Android | LocalBitcoins
johoe (OP)
Full Member
***
Offline Offline

Activity: 217
Merit: 238


View Profile
June 11, 2015, 06:24:38 AM
 #5

[...] and then need two months to deploy an emergency hard fork if something bad happens.

Where do you get two months from? The last time there was an "emergency hard fork" situation the matter was resolved in ~ two days, IIRC.

From BIP-50:

Quote
Immediately

Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:

Reject blocks that could cause more than 10,000 locks to be taken.
Limit the maximum block-size created to 500,000 bytes
...
Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page [that urged them to upgrade].

In other words the new version 0.8.1 was as restrictive as pre-0.8 versions for two months (i.e. an emergency soft fork against 0.8 to go back to the old rules) and the hard forking rule (allow larger blocks and more locks to be taken) was automatically deployed two months later (the first block that broke the old rules came five months later).

And in March 2013 when the accidental hard fork happened, 0.8 had already 60 % hash power on its side, so they only had to convince 40 % to upgrade.

A hard fork can only be successful if most miners and almost all merchants update.  There is no chance you can get them to update in two days. 

Donations to 1CF62UFWXiKqFUmgQMUby9DpEW5LXjypU3
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!