Idea on the "Blocks are [not] full problem" - page 2.

niniyo

member

Activity: 118

Merit: 10

Quote from: grue on December 02, 2013, 04:01:36 PM

Quote from: niniyo on December 02, 2013, 03:43:23 PM

Exactly. Are the core devs treating this issue seriously? In my opinion it's the biggest threat to Bitcoin's future. The blockchain transactions-per-second needs to get MUCH higher in order to support the future that we all want.

If bitcoin becomes a low-TPS system with high fees that is only viable for moving millions of dollars, and all other transactions move off blockchain, then I think Bitcoin will collapse since it loses its main feature that is appealing (ie. peer-to-peer payments).

that said, it's important to note that bitcoin is not for micropayments.

What counts as a micropayment? Fair enough if you can't pay a few cents through the blockchain, but I think anyone should be able to pay for a meal or a coffee via the blockchain, so transaction fees would have to stay below ~5-10 cents to make this viable.

grue

legendary

Activity: 2058

Merit: 1452

Quote from: niniyo on December 02, 2013, 03:43:23 PM

Exactly. Are the core devs treating this issue seriously? In my opinion it's the biggest threat to Bitcoin's future. The blockchain transactions-per-second needs to get MUCH higher in order to support the future that we all want.

If bitcoin becomes a low-TPS system with high fees that is only viable for moving millions of dollars, and all other transactions move off blockchain, then I think Bitcoin will collapse since it loses its main feature that is appealing (ie. peer-to-peer payments).

that said, it's important to note that bitcoin is not for micropayments.

Quote from: justusranvier on December 02, 2013, 02:52:33 PM

Quote from: gmaxwell on December 02, 2013, 02:43:03 PM

250 is the default in the reference software. A simpler hypothesis than miners performing some complex orphaning cost benefit analysis is that they don't care to change the defaults.

An easy way to test that hypothesis would be to change the default to 1 MB and see how many miners suddenly start creating larger blocks.

for a pool admin, it's trivial to change the "soft" block size in bitcoin-qt

niniyo

member

Activity: 118

Merit: 10

Quote from: justusranvier on December 02, 2013, 02:52:33 PM

Quote from: gmaxwell on December 02, 2013, 02:43:03 PM

250 is the default in the reference software. A simpler hypothesis than miners performing some complex orphaning cost benefit analysis is that they don't care to change the defaults.

An easy way to test that hypothesis would be to change the default to 1 MB and see how many miners suddenly start creating larger blocks.

Exactly. Are the core devs treating this issue seriously? In my opinion it's the biggest threat to Bitcoin's future. The blockchain transactions-per-second needs to get MUCH higher in order to support the future that we all want.

If bitcoin becomes a low-TPS system with high fees that is only viable for moving millions of dollars, and all other transactions move off blockchain, then I think Bitcoin will collapse since it loses its main feature that is appealing (ie. peer-to-peer payments).

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: gmaxwell on December 02, 2013, 02:43:03 PM

250 is the default in the reference software. A simpler hypothesis than miners performing some complex orphaning cost benefit analysis is that they don't care to change the defaults.

An easy way to test that hypothesis would be to change the default to 1 MB and see how many miners suddenly start creating larger blocks.

grue

legendary

Activity: 2058

Merit: 1452

this solves the block propagation problem, but it still doesn't solve the problem of TXs eating up a full node's hard drive space.

gmaxwell

staff

Activity: 4284

Merit: 8808

Bandwidth isn't the only consideration— checksig can have a pretty substantial impact too.

But conserving bandwidth— and keeping the cost of operating a node down— is part of the reason to not have 1MB blocks constantly. Taking a 4x bandwidth hike for everyone is a pretty substantial cost. I suppose it's better than the blocks actually being that size, but still…

Quote

Miners include few transactions in blocks because more transactions equals more probability of orphaned block so lets equal all blocks

Citation needed. 250 is the default in the reference software. A simpler hypothesis than miners performing some complex orphaning cost benefit analysis is that they don't care to change the defaults.

rme

hero member

Activity: 756

Merit: 504

Problem discussed in this thread:
https://bitcointalksearch.org/topic/blocks-are-not-full-whats-the-plan-339505

Quote

Miners create 250KB or less blocks because they broadcast faster and they have less chances of been orphaned, they include few transactions in them

Here it comes my idea about this issue:

Miners include few transactions in blocks because more transactions equals more probability of orphaned block so lets equal all blocks:

Miners should craft a block normally, so lets imagine they generate a 250KB block. Before they send it to other node they have to concatenate junk bytes (random (?)) to the block data, so all blocks are 1MB.

When a node sees this block, they broadcast it and when they finish they delete this junk bytes and they only the block.

The junk data never gets into the blockchain

Pros:
- All blocks "are" 1MB in terms of relaying them.
- We avoid other more tecnical mecanisms
Cons:
- Bitcoin QT needs some bandwith more because now all blocks are 1MB.

If one day we need to rise the 1MB block limit this process will be the same but all blocks will require to be 10MB (for example). We only need to concatenate junk to them.

How to perform this hard fork?
Bitcoin core developers can release an update that includes this fix but only enforcing it when the blockchain reaches the block 277000 (30 days later) so we give some time for people and miners to update their software.

Topic: Idea on the "Blocks are [not] full problem" - page 2. (Read 2097 times)