Instead of changing block size, why don't they change block time? 10/8 min instead of 10min, no latency issue, faster transactions, space for everyone, seems like a win-win?
Just need to adapt block reward and halving, it doesn't seem to be a big deal since every others altcoins plays with these parameters.
For "faster transactions", even a 10/8 min is too long and people would still have to rely on mempool transactions. It doesn't raise the security because the proof of work is still the same.
Latency is one of the problems with regards to creating an economy of scale and centralization. It may actually work better to increase the block size by having 3MB blocks with 20 minute intervals or 1 hour blocks with 20MB caps, though that also has some centralizing pressures in increasing the full node expenses and may even result in latency-blocktime ratio increasing. There also is of course the problem of confirmations being inconvenient with 1 hour blocks.
Love this response in the comment section by Jacob Eliosoff:
> My point isn't who's right and who's wrong. It's that well-informed publications like Bitcoin Magazine have an important role to play here in spelling out the specific technical questions and their pros and cons, and that requires interviewing more than one side
Here's one way the article is wrong:
> The main (though not only) reason bigger blocks favor bigger miners has to do with latency.
Gregory Maxwell (a small block advocate) himself has said this is not true:
>The technical/security implications of larger blocks are related to
other things than propagation time, if you assume people are using the
available efficient relay protocol (or better).
Also calling Small Block advocates "Decentralists" is really silly in my opinion. Both sides want increased decentralization.
Yes, and they even acknowledge in the article that several mining pools are already sharing the block header with each other before propagating the entire block. They completely ignore that when talking about the latency issues with increasing block size, which makes me extremely skeptical whether or not this article is biased.
Myself, attempting to write an application on top of the blockchain that would store extra information in the blockchain, have met a huge resistance from that community, that came along with a lot of name-calling and not understanding the implications of "filling the blockchain with garbage". I came to the conclusion that this is a really, really fragile issue within the Bitcoin community that many people feel extremely strongly about, and that the core issue is that every member with commit access can veto a decision out, effectively making the project come to a halt.
Many organizations now have a huge financial stake in the success of Bitcoin, which for some is reason enough to be against it. I think the XT fork is an extremely interesting strategy, because it caters directly to those institutions that have the most financial stake in Bitcoin. I wouldn't be surprised if this problem will escalate even further in the future, and it will be very interesting to watch.
Reducing the scalability problem to "large vs. small" of a single variable is almost as damaging to intellectual debate as two-party politics are. That, or they're directly isomorphic.
My favorite perspective on this Tragedy analogizes the Commons in question to a cavern whose acoustics preserve any sound shouted within. We could allow more people to shout at once, but that would increase the number of echos, increasing the total amount of "signal" and effectively decreasing the SNR when all you're interested in is a single signal out of the whole cacophony. As the permitted transmission bandwidth rises, the complexity of making sense out of the received data increases at some sharper rate that I won't just pull from my ass.
The fundamental right that must be preserved - the action that must be kept accessible at minimum price to anybody wishing to perform it - is not that of adding data, but rather verifying and interpreting that which is already present. Shouting should be expensive, because you hurt every other eardrum.
>And while it has been suggested that miners can connect to a VPS if they prefer to remain anonymous rather than connect through Tor, this is not quite satisfying for decentralists either. Speaking to Bitcoin Magazine, hashcash inventor and Blockstream CEO Dr. Adam Back explained why.
>“It is technically possible to mine using a VPS (Virtual Private Server), but miners who do so are not choosing their own transactions,” Back emphasized. “Instead, they connect to a server that does this for them. It’s another form of centralization, at the extreme. And we already see this happening due to bad connectivity in some countries, where miners use VPS services set up in another country to win some time and increase profits…”
Is it just me or was this article generated by a markov bot?
So the main argument is that large blocks take longer to propagate, giving an advantage to the miners that find them.
This completely ignores IBLT, which propagates a small fixed-size data structure instead. It takes advantage of the fact that miners have most of the transactions already, so sending complete copies of them is redundant.
But the 'O(1) block propagation time proposal' essentially merges the consensus and networking layer.
Notable problems:
1. Engineering would like to keep the networking layer and consensus layer separate because of architectural decisions for eg; difficult to push networking upgrades
2. Syncing unordered data in a trustless distributed system is a hard problem. Some propose ordering them, but that promotes censorship and centralization.
Because it does not work on it's own. The IBLT compression is just a way to check whether a data (transaction) is part of a dataset (transactions in mempool) when collision is low.
For this to work, the mempools must be almost same. Like I said, syncing unordered trustless distributed system is a difficult problem. Suppose, engineering implements a method to do so among nodes, it will by definition be a part of the way they network but concept-wise are a part of the consensus layer.
14 comments
[ 3.0 ms ] story [ 47.9 ms ] threadJust need to adapt block reward and halving, it doesn't seem to be a big deal since every others altcoins plays with these parameters.
Or am I missing something?
For "faster transactions", even a 10/8 min is too long and people would still have to rely on mempool transactions. It doesn't raise the security because the proof of work is still the same.
> My point isn't who's right and who's wrong. It's that well-informed publications like Bitcoin Magazine have an important role to play here in spelling out the specific technical questions and their pros and cons, and that requires interviewing more than one side
Here's one way the article is wrong:
> The main (though not only) reason bigger blocks favor bigger miners has to do with latency.
Gregory Maxwell (a small block advocate) himself has said this is not true:
>The technical/security implications of larger blocks are related to other things than propagation time, if you assume people are using the available efficient relay protocol (or better).
Also calling Small Block advocates "Decentralists" is really silly in my opinion. Both sides want increased decentralization.
Myself, attempting to write an application on top of the blockchain that would store extra information in the blockchain, have met a huge resistance from that community, that came along with a lot of name-calling and not understanding the implications of "filling the blockchain with garbage". I came to the conclusion that this is a really, really fragile issue within the Bitcoin community that many people feel extremely strongly about, and that the core issue is that every member with commit access can veto a decision out, effectively making the project come to a halt.
Many organizations now have a huge financial stake in the success of Bitcoin, which for some is reason enough to be against it. I think the XT fork is an extremely interesting strategy, because it caters directly to those institutions that have the most financial stake in Bitcoin. I wouldn't be surprised if this problem will escalate even further in the future, and it will be very interesting to watch.
The fundamental right that must be preserved - the action that must be kept accessible at minimum price to anybody wishing to perform it - is not that of adding data, but rather verifying and interpreting that which is already present. Shouting should be expensive, because you hurt every other eardrum.
>“It is technically possible to mine using a VPS (Virtual Private Server), but miners who do so are not choosing their own transactions,” Back emphasized. “Instead, they connect to a server that does this for them. It’s another form of centralization, at the extreme. And we already see this happening due to bad connectivity in some countries, where miners use VPS services set up in another country to win some time and increase profits…”
Is it just me or was this article generated by a markov bot?
This completely ignores IBLT, which propagates a small fixed-size data structure instead. It takes advantage of the fact that miners have most of the transactions already, so sending complete copies of them is redundant.
https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
http://www.i-programmer.info/programming/theory/4641-the-inv...
Notable problems:
1. Engineering would like to keep the networking layer and consensus layer separate because of architectural decisions for eg; difficult to push networking upgrades
2. Syncing unordered data in a trustless distributed system is a hard problem. Some propose ordering them, but that promotes censorship and centralization.
I also don't see how deterministic ordering, perhaps based on hashing the transaction, would promote censorship or centralization.
For this to work, the mempools must be almost same. Like I said, syncing unordered trustless distributed system is a difficult problem. Suppose, engineering implements a method to do so among nodes, it will by definition be a part of the way they network but concept-wise are a part of the consensus layer.