Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 4. (Read 378926 times)

Thanks for the link. I'll read it in its entirety.

However, from my perspective, that latter statement is nothing but a rather weak assumption. According to bitnodes, there are currently about 5650 nodes in operation. Do you really think that a significant percentage of them have less than 8 GiB RAM? Even if they do today (which I do not for a minute believe), it currently costs well under 0.1 BTC to purchase 8 GiB memory. Your assumption that requiring this much RAM will knock a significant percentage of nodes off the network is simply incredible, in the literal sense of the word.

I agree, and in that spirit, let me state clearly here, that just because Satoshi said these things it does not mean he was right, he could have been wrong as some of the Core developers are now saying. I might agree with the original vision of Satoshi but we do have to be critical and always question ourselfs. I like to believe that is what Satoshi would have wanted us to do. It is true that I often fall into the trap of viewing him as a mythological figure, which is fun but I do need to check myself on that sometimes.

Just a friendly word of advice... It isn't a good idea to create a cult of personality and make persistent appeals to authority. Satoshi was/is a genius and while it is easy to revere his opinion, he also made multiple mistakes and from his programming history wasn't the most competent developer either. Many of the current core developers are far more competent and proficient technically than Satoshi... and we shouldn't view them as infallible or use appeals to authority to them either. This is yet another reason why we need to support multiple implementations as the core developers could learn from the others or correct a mistake as well.


Happy New Year to everyone. Don't drink and drive and if you can avoid the roads by sleeping with the host/hostess of the party than take the opportunity.

I will read this paper and respond later, going to head off now and celebrate the new year. I wish everyone here a happy new year.

In the schedule outlined in BIP101 the majority of people will still be able run full nodes out of their homes. We now also have Bitcoin Unlimited which can be seen as a more conservative approach in regards to the blocksize.

The way you are phrasing this is hyperbole. You claim that this is a live or death question. Can you seriously claim that an increase to two megabytes would destroy Bitcoin? Especially as our technology increases this limit becomes more and more arbitrary. Just increasing the limit does not actually increase the blocksize as the history of Bitcoin and the altcoins proves. It would also make these types of spam attacks much more expensive and less effective.

This has everything to do with transaction capacity. The blocksize limit as an anti spam measure is meant to be set at a much higher level then the actual level of transactions, these where the conditions under which it was setup, if we decide to use the blocksize limit to block the stream of transactions then it becomes a tool of economic policy, in the case of Core it is centralized economic planning. It would be better to allow the free market to determine the size of the blocks instead.

This was never the intention or the security model that was intended for Bitcoin. Full nodes are destined to be run on servers and desktop computers, I do not see anything wrong with that. Furthermore if we had billions of people using Bitcoin, which such large blocksizes would imply, then we would also have hundreds of thousands of nodes run in data centers across the world in different jurisdictions. I would consider this to be highly decentralized and desirable, this was always the intention and design plan of Bitcoin. Security through mass adoption, not obscurity.

The original vision of Satoshi was that the majority of users would not be running a full node, he had thought about the problems of scaling and what the solutions should be. He said that we should allow it to grow as big as it needed to be, since doing otherwise would effectively block the stream of transactions, hurting adoption. Pushing transactions off chain is not a solution to scaling up the main Bitcoin blockchain itself, not to mention the terrible user experience this would be when compared to just using Bitcoin directly. Bitcoin needs to have a high volume of transactions to pay for its security while maintaining low fees which promotes adoption, which in turn increases its security.

I am really sincere and appreciate your hard work.

I am working on a project now that will back up my words of support with actual action that shows I am truly sincere with both supporting the core dev and other implementations. Let us all rise above attacking each other and bikeshedding.  

It does not help if you don't have servers at major internet backbones. And if you have, those servers will be censored in a similar way

Bitfury's paper here:

http://bitfury.com/content/4-white-papers-research/block-size-1.1.1.pdf

"The table contains an estimate of how many full nodes would no longer function without hard-ware upgrades as average block size is increased. These estimates are based on the assumption that many users run full nodes on consumer-grade hardware, whether on personal computers or in the
cloud. Characteristics of node hardware are based on a survey performed by Steam [19]; we assume PC gamers and Bitcoin enthusiasts have a similar amount of resources dedicated to their hardware.

The exception is RAM: we assume that a typical computer supporting a node has no less than 3 GB RAM as a node requires at least 2GB RAM to run with margin[15]. For example,if block size increases to 2 MB, a node would need to dedicate 8 GB RAM to the Bitcoin client, while more than a half of PCs
in the survey have less RAM."

Based on his estimation, raise the block size to 4MB will drop 75% of nodes from the network

The Bitcoin relay network is also open source.

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

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.

 
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?

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

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

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


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.

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

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.  

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

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