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

Well put!

Satoshi is kind of analogous to the Wright Brothers, but these BIP101 clowns foolishly think they're bringing bitcoin into the jet age---but without the highly rigorous testing and design standards such a feat requires. BIP101 seems more like the infamous Spruce Goose to me.

opinion stated as fact


opinion stated as fact

opinion stated as fact
opinion stated as fact
opinion stated as fact
opinion stated as fact
opinion stated as fact

I have opinions I do not state them as facts.

opinion stated as fact


probably opinion stated as fact, but its hard to tell

I think this is a common theme, and its not just you or your 'side'. There are plenty of big blockers that keep posting stuff that makes me cringe its just that they aren't rebutting my posts so there's no real reason to call them out.

Now I am not saying I am perfect, but I certainly try to make sure that I recognise what is my opinion and what are facts. I think if more people did this then the conversation could be much more productive.

My statement about XT being the only solution wasn't a conclusion, it was just one amongst several points. When you say things like "Supporting bigger blocks just for bigger blocks..." it implies that you have either not understood, or ignored what I wrote. I am in favour of big blocks for all of the reasons that I stated, and not just for their own sakes. I am troubled because the only option I have to 'support' big blocks is to run XT. They are related but independent points.

If you want a 'conclusion' then you would be better focusing on this comment: "We should do a bit of X,Y and Z. I think in doing these things iteratively, further opportunities will present themselves. Thats the reality of software development (at least in my experience). Sometimes you have to do a bit of suck it and see. It might not be optimal at that given point in time, but it can help drive development in a more optimal direction."

This comment is supposed to illustrate how software itself iterates, rather than to speak of the "open source" process. When a feature is developed algorithms are created. Those algorithms can sometimes trigger development - either the optimisation of existing algorithms, the refactoring of related code to take advantage of those new algorithms, or inspire different features based on the new algorithms. This is not an exhaustive list, but it illustrates the point I think. That sometimes it is not possible to see what will several steps ahead until some of the previous steps are implemented. To further clarify I am not saying that is the entirety of the development process, but it is one facet.

The conclusions would be that I think bigger blocks allow for more time to to continue developing scaling solutions without compromising the viability of bitcoin in terms of transaction throughput. That I think that this will not lead to dangerous levels of centralisation overnight (I agree it may not be sustainable - but conversely nobody can actually say that it is not) by making it prohibitively expensive to run a node. I think that there is not any need to attempt to artificially create a fee market when we are still in the position of coinbase being a huge revenue stream. I think that it is preferable to let a fee market develop organically.

However much you try and state that all of these opinions are wrong, you cannot categorically state that your counter opinions are any more factual. However strongly you might believe in them.

Hal Finney had an opinion, and you posted it. He could be right. Satoshi had an opinion too - its in my sig, maybe he is right. gmaxwell posted about how he though 'coffee on chain' was far less of a problem than 'nothing on chain' - I'd agree. Using the blockchain for non bitcoin transfer seems much further away from "what is bitcoin" than actually recording bitcoin transfer.

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

The problem isn't the block data, which at the present 1 MB limit uses less than 3 percent of a 350 MB/month ISP cap.  The problem is that Bitcoin Core does not provide the instrumentation and tools to allow node operators to manage their bandwidth utilization.  The developers could fix this situation if they were so inclined.   I interpret this situation to a question of priorities and/or lack of network performance expertise on the part of Bitcoin Core developers.

Heh, seems gavin cant help but making a joke out of himself.

For the records:

Gmax: 24 commits last month  https://github.com/gmaxwell
Gavin: 0 commits last month  https://github.com/gavinandresen

Keep the faith Gmax.

https://www.reddit.com/r/Bitcoin/comments/3uz0im/eli5_if_large_blocks_hurt_miners_with_slow/cxj3k01?context=3

Have faith in development or whatever, just let the developers work on proper scaling solutions.



Big picture: "I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010

And it is exclusive from being highjacked with broken democracy social brigading.



No, full blocks are meant to be in bitcoin.



The reality of "open" software development is that anybody is free to contribute, but it does not imply it will be implemented by the network's participants.

Still, bitcoin unity relies on a consensus, not some various branding for all the braindeads spectrum a la cocacola zero, light and cherry.



Supporting bigger blocks just for bigger blocks is childish and stands no ground in the technical debate.

I am supporting scaling solutions that do not hamper the decentralization and hence the security of bitcoin's network.
I am supporting bitcoin as an immuable force from which a healthy monetary system will emerge.




Unbelievable, talking stuff like "belief" "could" "believe" "things" all the way down to such pseudo conclusion.



There is no point bending bitcoin's rules just to fit couple USG payment processors and broken fiat intermediaries.

To hell with the corporate leeches.

No, I don't think that you have got the analogy correct.

The BIP101 / XT crew are proposing to change the 'Technical Specification' of the aircraft. This is a document that describes under what conditions the aircraft is safe to operate, including load-limits.

Changing the 'Technical Specification' doesn't magically change what the aircraft is physically capable doing, it only changes how people will be inclined to use the aircraft.

BIP101 doesn't change Bitcoin's wingspan or any other physical quality that *may* make it safe to operate at twice the load. It only changes the document that describes how to use the aircraft safely.

This in itself isn't a bad thing; If the aircraft is overly conservatively specified, then updating the specification to reflect the actual capabilities of the aircraft is a prudent thing to do. - You want to of course maximize the utility of your aircraft.

However with BIP101, they are proposing to adjust the aircraft specification without even much looking at testing a model aircraft under such loads in a air tunnel, much less making a full-sized copy for rigorous test flights.

They are acting in complete disregard with established engineering concepts such as engineering safety factors, or conservative design specifications. - From a engineering point of view, those who propose BIP101 (or any other scaling proposal), without first showing scientific evidence and reasoning that such a proposal will be within the physical capabilities of the network, imho, are looking much like chumps.

Of course when an aircraft crashes, it costs hundreds of lives. - Bitcoin, only billions of dollars.

Also for the record... three nodes... ~80 connections on each

I understand your points entirely. However, even if we make Bitcoin a system that is going to be used for very small everyday purchases like coffee, those don't necessarily have to be on the main chain. You don't need the strongest network in the world to secure your $1 purchase. This is one of the things that supporters of XT, BIP101, no limit/etc. have sometimes tried to use as a argument (not being able to buy coffee with small blocksize). I'm also aware of the concern of storing huge amounts of data on the blockchain which was not designed for that purpose and is very inefficient when it comes to that. How about something a few gigabytes in size? Wouldn't really work out in a efficient way.

---

---

To keep it short, someone of your expertise shouldn't waste too much time in this thread. People have been coming and going with very strong arguments, but the "opposing" side doesn't budge. Their way is the right way, or none is (not always, but often).

Are you suggesting that the exchanges will force miners onto the BIP101 chain by refusing to exchange their bitcoins? So the BIP101 supporters have finally given up pretending this isn't a coup attempt?

Allow me to introduce you to the first fully p2p exchange,  bitsquare.io  (fully functional beta is fairly imminent apparently).

Decentralisation will win, it's the much more powerful organisation method. The world you knew is gone.

For me this is the strongest argument for small blocks that I have read to date, and I agree with it. It is expensive to run a node. (I'd argue not prohibitively, but thats a matter of opinion).

Despite this I still think we need bigger blocks, and in taking this road I think that the pain Gregory described above would increase. I think this is growing pain though and although its undesirable I don't think its symptomatic of terminal illness.

I absolutely have faith that "development" has some big answers to this, and that protocol/software improvement will be the thing that addresses the challenges we currently face with infrastructure requirements.

Essentially I think we can have it all, and that those that frame the debate as being mutually exclusive are too married to their position to see the big picture.

Bandwidth requirements are a big concern. Full blocks are a big concern. Speculation as to the consequences of these things (an in particular using those hypothetical concerns) to justify why we must do X is not helpful.

We should do a bit of X,Y and Z. I think in doing these things iteratively, further opportunities will present themselves. Thats the reality of software development (at least in my experience). Sometimes you have to do a bit of suck it and see. It might not be optimal at that given point in time, but it can help drive development in a more optimal direction.

My biggest concern is that the only option I have to support bigger blocks is XT. I'd hate for everyone to jump to that because it was the only viable alternative.

To be clear, its the fact there is only one option that is the problem. In and of itself I don't think XT is necessarily a bad option, and I certainly don't subscribe to the belief that it would automatically result in all the bad things happening. Over time it could potentially facilitate those things, but I also believe that if that were the case then this can be addressed.

Yes, I have "faith". Without it what is the point in anything.

This thread just keeps on giving..  I'm still undecided if it's in a good way or a baaaad way...

How about a different approach.

..

The size of the UTXO set is a 'tiny' 1GB.  http://statoshi.info/dashboard/db/unspent-transaction-output-set , and more importantly it grows very slowly.

At 144MB per day (with each block full at current 1mb limit), that's 30x144 = 4.3GB / month of TXNs being fired around the network. (I download more than that in an evening watching netflix..)

These are the only bits that matter.

I have mucked about with the 'pruning mode' in the latest BTCore, and if I may, it just doesn't go far enough.. No disrespect, it's lovely work, but we're just scratching the surface.

I need to be able to run a full, validating, independent node, without any SPV-ness, with around 2GB of space, and my current mid-tier internet connection.    

That's it.

(Discard the un-needed, only put the hash of txn in blocks, put the UTXO merkle root hash in the block, store the UTXO as a new weird dataset type, scrape the spam-dust off and give it to the miners, use a proof-chain (just block headers with valid POW) instead of storing the whole block..  etc etc blah blah.. I dunno.. something!?)

..

There's obviously some very clever people here, so how about it ?

Then big blocks wouldn't be an issue. And we can ALL get along, again..  
..

ps. #GMAX - don't be depressed.. We need you to be strong. And smart. Hang in there..

Rage more please.


Wait until miners will not afford to pay their bills! Things will change.

Core: The airplane is getting overloaded.  Time to start auctioning off capacity to the highest bidders.  The rest can go by car, train, ship, or bus.  Or stay home.

Gavinista: I demand you immediately double the load-limit by doubling the airplane's wingspan.  No, you can't do a feasibility test in a wind tunnel first, Because Censorship!  Do it now or we hijack this bitch.

Plot twist: The airplane is in mid-flight over central Greenland.

So this is the December FUD offensive they were talking about.

Cant' you read? It means that this alone will make it possible to grow like that. More will be possible together with protocol improvements and other measures.
We don't need artificial scarcity:

BeYourOwnBank ; 33 Punkte vor 13 Stunden*

Blockstream/Core are weak and desperate, centralized and fragile.

Their only hope of succeeding is by creating artificial scarcity all around: artificially restricting us from speaking out freely on our forums, artificially restricting us from transacting directly and cheaply on our blockchain and in our mempool.

Their only chance of success is to change everything from being permissionless back into being permissioned: they want us to ask their permission to speak on "their" forums (via their censors), they want us to ask permission to transact on "their" blockchain (via LN), and they want us to compete to pay higher fees to propagate in "their" mempool (via RBF).

They know they are vulnerable and they are running scared.

All Bitcoin has to do to succeed is remain decentralized and anti-fragile and open to everyone.

-----------------

My feeling (not that a feeling is worth much) is that 8GB blocks will be enough. If we really do see that level of adoption (~1 billion transactions per day) there will be a lot of off-chain transactions as well.

In other words, the idea that 1 MB blocks (or 2 or 4 or can be "enough" with layer-2 or offchain solutions is... unrealistic, but that layer-2 or offchain solutions can help Bitcoin get from 1 billion to 10 (or 100) billion transactions per day seems plausible to me.

 chriswilmer, Today at 12:36 AM 

-----------------

    I agree, and even 32MB blocks will allow for 100 TPS on-chain, which is a lot of real-world business, and would support a very healthy BTC price. It is fully reasonable to expect off-chain solutions to take a lot of volume *eventually*. The strategic error is trying to force that outcome before off-chain solutions develop organically and take volume on their own merits.
     
solex, Today at 1:10 AM

Of course it is. It's neither a Front National movement nor another right or left wing socialist project.
The Tide is Turning

https://www.youtube.com/watch?v=SbeLFG6Lglo

I have 50 mbps down 10 mbps up with no cap residential ADSL. Running all three blockchains as a full node with ports open is about 400 GB per month.

Edit: I added the no cap option for an extra 15 CAD a month, The plan comes with 400 GB of data per month. Cost including a home POTS phone line is 132.50 CAD a month including all taxes.

If you think of Bitcoin as an airplane, and the block size limit as the load-limit of the aircraft. -  The block-size debase makes much more sense.

We are talking about changing the _technical_specification_ of the aircraft, not actually scaling the aircraft for greater loads.

BIP101 and the other block size proposals do nothing to actually scale the Bitcoin infrastructure, the only talk about changing the specification for Bitcoin infrastructure.

Of-course if you double the load-limit of a aircraft, it *may* still work, but if you double it again, it will probably fail in a spectacular manner.

The real scaling dose happen, but it isn't lauded, it is the hard CS engineering that upgrade the engines, upgrade the fuselage, etc.

Maybe having the engineers who maintain and build the aircraft setting the technical specification for what the aircraft is capable of safely handling is a prudent approach?

Boeing doesn't have a public vote asking the public what the take-off-load-limt for their aircraft should be; neither should the Bitcoin community have such a vote for Bitcoin protocol. Indeed, for such systems the limits should be set very conservatively.

How much bandwidth is Core using per month? What are your maximum download/upload speeds from your ISP (and how much does it cost)? How many peers are you connected to on a regular basis? Do you have any special settings in your config file (fee rules or connection limits)?

I have dedicated hardware for my node (building computers is a hobby of mine, so I probably go overboard there), yet sharing Bitcoin data with my peers is where I am having issues. I've had to limit the number of peers that my node will allow or my internet service slows to a crawl for other purposes. I pay quite a bit for top tier (enthusiast) internet speeds from a major ISP.

Or, are you simply saying that your old computer can sync the chain at which point you shut it down?