Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)

[brg444]

What is bitcoin? Why should it's properties be determined by humans via populist means?

Veritas?

I might ask you another question, who or what else should determine the properties of Bitcoin if not human beings? In the absence of sentient AI, it is left to human beings to decide on the rules of the protocol. Fortunately Bitcoin has incentive and governance mechanism build into the protocol to allow this process to happen in a much more fair and free fashion when compared to the state democracies that we are used to. This is a part of the genius behind the invention of Bitcoin, it has solve some of these age old problems like tyranny of the majority and volunteerism.

Bitcoin is also less likely to fall victim to populists politics considering that it is in effect ruled by the economic majority who are incentivized to do what is best for Bitcoin. Unlike our present political systems where often the incentives become perverted. If I had to describe what Bitcoin is in one word I would say that Bitcoin is freedom.

So cute...

[1714764233]

1714764233

[1714764233]

1714764233

[1714764233]

1714764233

[1714764233]

1714764233

[1714764233]

1714764233

[1714764233]

1714764233

[johnyj]

Can someone explain to me how not raising the block size limit is a good thing? All transactions should be able to go thru in a semi-timely manner and if the limit is reached in a block then that transaction is just cancelled? That doesnt' make sense to me, I don't see a good reason NOT to switch to bitcoin XT. Secondly, why wasn't this thought of originally in the making of bitcoin? Seems odd.

From the beginning the block size limit works as a spam filter (even this year it successfully resisted the spam attack by coinwallet.eu during July and September). And now people realized it also can work as a means to prevent centralization (As long as blocks are small, average people with a little bit IT knowledge can run a full node in his home thus increase the level of decentralization)

This has nothing to do with transaction capacity, but a live or death question. If the blocks are huge and average people can not run a node, thus they all run on large data centers, then a couple of phone call to ISP could disable the bitcoin network. By making blocks small and portable, you can run it on almost any device thus it becomes unlikely you can disable bitcoin network unless you shutdown the whole internet

Mining nodes on the other hand can not be run by average home users, Satoshi also anticipated certain degree of mining centralization. This is also a potential risk but not a live and death problem

So, as long as average home users can run a full node, the block size is not the problem. But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer, so currently the only safe choice is 2MB, not 8MB promoted by XT

[jbreher]

I don't see a good reason NOT to switch to bitcoin XT.

Well, in addition to the maxblocksize increase, XT contains several other unrelated controversial changes.

[jbreher]

Gavin he worked on the design and code back in 2007

Well, _that_ is a rather interesting assertion. Do you have a citation to back it up?

[jbreher]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

[johnyj]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

I don't remember exactly, but just google it, and also another statistic by Mark in Montreal conference showing that even a 1MB block can take over 30s to verify on a mining node

[BitUsher]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

This is the data you are looking for -
https://rusty.ozlabs.org/?p=522

here is the simulation test code-
https://gist.github.com/rustyrussell/9c3c4bf3127419bd3f1d



This is an example of a tx that can push validation times to their limit and potentially crash nodes--

https://www.blocktrail.com/BTC/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08


There are solutions to this problem and principally why core devs want to roll these out first ... before increasing the blocksize limit on the main tree.

[QuestionAuthority]

Gavin he worked on the design and code back in 2007

Well, _that_ is a rather interesting assertion. Do you have a citation to back it up?

He might be talking about Andresen's work for the University of Massachusetts Amherst or Gravity Switch if they use the same languages in their project development as Bitcoin. I don't think he means actually working on Bitcoin unless he has some inside info from the cypherpunks mailing list or HashCash work that we don't know about. Andresen doesn't show up on the Bitcoin scene until 2010.

[VeritasSapere]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

I don't remember exactly, but just google it, and also another statistic by Mark in Montreal conference showing that even a 1MB block can take over 30s to verify on a mining node

Today we have the mining relay network, the block is relayed in milliseconds. What you are saying is factually incorrect.

[sAt0sHiFanClub]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

This is the data you are looking for -
https://rusty.ozlabs.org/?p=522

here is the simulation test code-
https://gist.github.com/rustyrussell/9c3c4bf3127419bd3f1d



This is an example of a tx that can push validation times to their limit and potentially crash nodes--

https://www.blocktrail.com/BTC/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08


There are solutions to this problem and principally why core devs want to roll these out first ... before increasing the blocksize limit on the main tree.

Wasn't that F2P's own transaction to hoover up the coinwallet brainwallet dust?  Its a pretty extreme boundary case, but surely the number of inputs ( and associated resources tied up) are the issue - not the size of the transaction per se. Thats why it got processed with no fees - normally these wouldn't be touched.

edit:  was brainwallet, not coinwallet

[VeritasSapere]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

The primary limiting technological factor for blocksize today is bandwidth and latency.

[BitUsher]

This problem is far worse if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB of outputs takes over 11 minutes to hash. If you can mine one of those, you can keep competitors off your heels forever, and own the bitcoin network… Well, probably not.  But there’d be a lot of emergency patching, forking and screaming…

And this assuming the initial optimizations completed to speed up Verification!
This means that If we hardforked a 2MB MaxBlockSize increase on the main tree and we softforked/hardforked in SepSig, we would essentially have up to a 8MB limit (3.5MB to 8MB) in which an attack vector could be opened up with heavy input and multisig tx which would crash nodes.

These are edge cases... but edge cases are what attackers use to disrupt the network.

Remember we have to design code to expect the worst and hostile intent, especially for bitcoin which has many extremely powerful adversaries. This is why I have a nuanced view of simultaneously supporting multiple implementations, the conservative approach from the core devs, and eventually increasing the block limit.  

[VeritasSapere]

This problem is far worse if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB of outputs takes over 11 minutes to hash. If you can mine one of those, you can keep competitors off your heels forever, and own the bitcoin network… Well, probably not.  But there’d be a lot of emergency patching, forking and screaming…

And this is with the initial optimizations completed to speed up Verification.
This means that If we hardforked a 2MB MaxBlockSize increase on the main tree and we softforked/hardforked in SepSig, we would essentially have up to a 8MB limit (3.5MB to 8MB) in which an attack vector could be opened up with heavy output and multisig tx which would crash nodes.

What you are saying here is completely factually inaccurate, the number of transactions does not increase hashing time. Furthermore you are assuming that miners are irrational and malicious which is flawed. If the miners collectively wanted to destroy the Bitcoin network they already could do that now. It is the underlying game theory and economics of Bitcoin that prevents this from happening in the first place.

If a miner decided to attack the network by creating excessively big blocks then other miners can simply choose to orphan those blocks and not build of them. Bitcoin Unlimited already has this build into the client as a preventative measure for such a scenario, which is a highly unlikely attack vector which furthermore is easily countered. I have written more extensively about this issue here:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-203#post-7395
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-208#post-7550

[BitUsher]

What you are saying here is completely factually inaccurate, the number of transactions does not increase hashing time. Furthermore you are assuming that miners are irrational and malicious which is flawed. If the miners collectively wanted to destroy the Bitcoin network they already could do that now. It is the underlying game theory and economics of Bitcoin that prevents this from happening in the first place.

Its the number of inputs that can lead to long verification times. I cited an example.

Furthermore you are assuming that miners are irrational and malicious which is flawed. If the miners collectively wanted to destroy the Bitcoin network they already could do that now. It is the underlying game theory and economics of Bitcoin that prevents this from happening in the first place.

I am not assuming miners are irrational or malicious either. First, we should prepare and secure ourselves for this possibility, but lets assume that a majority of the hashing power has and will continue to have the best of intentions for a moment. We can assume shortcuts for profit, mistakes, and ignorance from miners despite their intentions. Case in point -- SPV mining.


P.S... I really appreciate your efforts with Bitcoin Unlimited and hope that more developers test and review the code. Having multiple implementations is extremely valuable to our ecosystem.

[johnyj]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

I don't remember exactly, but just google it, and also another statistic by Mark in Montreal conference showing that even a 1MB block can take over 30s to verify on a mining node

Today we have the mining relay network, the block is relayed in milliseconds. What you are saying is factually incorrect.

As I understand, Matt Corallo's bitcoin relay network is a private company, similar "a phone call to shut it down" risk

[VeritasSapere]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

I don't remember exactly, but just google it, and also another statistic by Mark in Montreal conference showing that even a 1MB block can take over 30s to verify on a mining node

Today we have the mining relay network, the block is relayed in milliseconds. What you are saying is factually incorrect.

As I understand, Matt Corallo's bitcoin relay network is a private company, similar "a phone call to shut it down" risk

The free market coming up with solutions on its own, if it did get shut down another one could simply be setup.

[sAt0sHiFanClub]

 

code to expect the worst and hostile intent, especially for bitcoin which has many extremely powerful adversaries

you are correct on that one. Look at the ddos attacks on XT. I suppose its down to who you think your adversaries are, eh?

[VeritasSapere]

What you are saying here is completely factually inaccurate, the number of transactions does not increase hashing time. Furthermore you are assuming that miners are irrational and malicious which is flawed. If the miners collectively wanted to destroy the Bitcoin network they already could do that now. It is the underlying game theory and economics of Bitcoin that prevents this from happening in the first place.

Its the number of inputs that can lead to long verification times. I cited an example.

Furthermore you are assuming that miners are irrational and malicious which is flawed. If the miners collectively wanted to destroy the Bitcoin network they already could do that now. It is the underlying game theory and economics of Bitcoin that prevents this from happening in the first place.

I am not assuming miners are irrational or malicious either. First, we should prepare and secure ourselves for this possibility, but lets assume that a majority of the hashing power has and will continue to have the best of intentions for a moment. We can assume shortcuts for profit, mistakes, and ignorance from miners despite their intentions. Case in point -- SPV mining.

P.S... I really appreciate your efforts with Bitcoin Unlimited and hope that more developers test and review the code. Having multiple implementations is extremely valuable to our ecosystem.

Thank you, I appreciate your criticism. I am sorry if I came across a bit strong, I am to used to dealing with some of the trolls on this thread. Your observations are accurate, and we can assume shortcuts for profits and mistakes will be made despite the miners best intentions. I even suspect that some of these problems we will need to learn the hard way, the nice thing about Bitcoin Unlimited is that we could all decide on a two megabyte limit for instance and increase it again when required, allowing us more time to understand and further analyze its effects.

[johnyj]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

I don't remember exactly, but just google it, and also another statistic by Mark in Montreal conference showing that even a 1MB block can take over 30s to verify on a mining node

Today we have the mining relay network, the block is relayed in milliseconds. What you are saying is factually incorrect.

As I understand, Matt Corallo's bitcoin relay network is a private company, similar "a phone call to shut it down" risk

The free market coming up with solutions on its own, if it did get shut down another one could simply be setup.

Not when you are already heavily dependent on that one, you can not come up with a solution overnight

[VeritasSapere]

But simulation by bitfury already indicated that we will have a severe performance problem with 4MB blocks on average home computer

I'd like to see that report. Got a link?

With only several thousand running full nodes now, it seems to me that 'average home computer' is not the limiting issue.

I don't remember exactly, but just google it, and also another statistic by Mark in Montreal conference showing that even a 1MB block can take over 30s to verify on a mining node

Today we have the mining relay network, the block is relayed in milliseconds. What you are saying is factually incorrect.

As I understand, Matt Corallo's bitcoin relay network is a private company, similar "a phone call to shut it down" risk

The free market coming up with solutions on its own, if it did get shut down another one could simply be setup.

Not when you are already heavily dependent on that one, you can not come up with a solution overnight

The Bitcoin relay network is also open source.