Gold collapsing. Bitcoin UP.

[chriswilmer]

That's exciting that BU is getting more noticed. I think the observation that block size is not part of the consensus layer is going to seem obvious in retrospect (those are the best kind of observations).

 

[AdrianX]

That personal text line "Bitcoin replaces central, not commercial, banks" is so hack I don't even know where to start!

Can't remember where I read that but it hit me that whoever said that doesn't even know the difference between a commercial bank and a retail bank. But has some notion that a central bank is the ultimate settlement layer.

The irony here is central banks exist only as a lender of last resort of fiat they are an elastic band for money supply. Their primary role is not to keep commercial and retail banks honest but to keep them solvent.

Bitcoin does nothing for them.

 

[Roger_Murdock]

Interestingly, what this means is that if another miner produced a > 1 MB block, the BU miners would begin to mine on top of it.

But, as things stand right now, wouldn't that be irrational? With the majority of the hash power still enforcing the 1 MB limit, any block you found on that chain is guaranteed to just end up orphaned, no? So presumably it would make more sense to run BU with the same block size limits as Core and attempt to coordinate a switch to higher limits when enough of the network was on board? The XT approach to the coordination problem seemed like a pretty good one (although the 75% threshold seemed unnecessarily high to me)?

 

[Justus Ranvier]

The response to my most recent post to bitcoin-dev mailing list was predictable.

 

[Roger_Murdock]

There is no benefit from Bitcoin the settlement layer, we might as well just use some permissioned federated system of rapid bank settlement exchanging fiat/asset-denominated IOU's for underlying held in custody.

I don't think I agree with that. It's not that there's no benefit from Bitcoin as a settlement layer; it's that Bitcoin is capable of providing additional benefit by also serving as a payment layer. Borrowing from a previous comment of mine:

Obviously, Bitcoin can scale somewhat. In fact, I'd say it can pretty obviously scale a great deal from where it is today. But exactly how much and how fast it scales will determine how affordable trustless, on-blockchain transactions will be as usage increases. In any case, concerns about exactly how scalable Bitcoin will prove to be shouldn't make us lose sight of the following: with fiat, trustless transactions aren't even possible. In other words, it doesn't make sense to compare Bitcoin's on-blockchain transactional capacity with the transactional capacity of, for example, the VISA network. You can obviously build a credit / banking / IOU layer on top of Bitcoin -- just as there exists such a layer with fiat. The difference is that with fiat, it's IOUs all the way down; there's no trustless, reliably-scarce monetary base at the bottom.

The real problem with the "settlement network or payment network" debate is that it's something of a false dichotomy. There's no question that Bitcoin is suitable for use as a settlement network and can provide tremendous value in that capacity. But I hope and suspect that it will also continue to be suitable for use as a payment network, at least for payments of a certain size. Now in practice, that might mean mortgage payments and not cups of coffee. But where exactly that line falls is something that I want to see determined by the market and not central planning.

 

[sickpig]

"But I hope and suspect that [bitcoin] will also continue to be suitable for use as a payment network, at least for payments of a certain size. Now in practice, that might mean mortgage payments and not cups of coffee. But where exactly that line falls is something that I want to see determined by the market and not central planning." -- @Roger_Murdock

bolded part hit the nail on the head.

history told us repeatedly that in such context central planning failed miserably.

do we really need another iteration of elitist-politburo-like-top-down politics failure?

 

[Inca]

do we really need another iteration of elitist-politburo-like-top-down politics failure?

No we dont. But like it or not that is exactly what we have. The Core dev's at the heart of the project working on Core need their power taken away from them. And they won't like giving up central control to the market but it will be crucial for the longer term survival of bitcoin.

To engender change either within Core or away from it, nodes and industry need to crystallise around a single competing alternative.

I would suggest this should be BU and we should start to coalesce the XT and big block community around this. If >50% of nodes are BU with industry in agreement it will be politically very difficult for Core to try and continue down this unwanted path citing any legitimacy for the network.

A script to spin up BU nodes for bitcoin is something we should look into also.

 

[Erdogan]

In the 1600's, merchants often used paper in their international trade, to avoid robberies. Bankers could afterwards clear the trades by meeting physically in the middle, clearing a set of trades with gold, then with a lower sum corresponding to the difference between the set of trades.

With bitcoin, the situation is different, as a remote transfer is just as easy as a local transfer.

There is no need to create bitcoin backed paper money for the purpose of trading, because that could just as easily be accomplished with notes in the form of paper wallets. If merchants find it convenient, it will exist in the market.

It is not useful to compare gold and bitcoin for this purpose. There is no natural path bitcoin -> bitcoin backed fiat -> unbacked fiat.

 

[cypherdoc]

But, as things stand right now, wouldn't that be irrational? With the majority of the hash power still enforcing the 1 MB limit, any block you found on that chain is guaranteed to just end up orphaned, no? So presumably it would make more sense to run BU with the same block size limits as Core and attempt to coordinate a switch to higher limits when enough of the network was on board? The XT approach to the coordination problem seemed like a pretty good one (although the 75% threshold seemed unnecessarily high to me)?

No. The way I understand it is that nodes, including those of pools, will have their default block limit size set at 16 MB. Thus, pools will accept and relay any new block sizes up to that default limit. A different setting is used by the pools to produce blocks and this default is set at 1MB. they are free to inch that production size higher and those blocks will be accepted and relayed across the network not only by non mining nodes but also by mining pool nodes, assuming they haven't changed the default 16mb acceptance limit. Then pools start freely building on top of that block either retaining their preset 1MB production setting or by being encouraged to up their production setting above 1MB, ideally.
[doublepost=1451220412,1451219486][/doublepost]Unfortunately, BU has chosen a confusing term ''excessive block limit' which is more simply just the user defined limit whose default is 16mb.

I think somewhere else a thread days BU is not 'competitive' with 101 or something like that. Confusing.

 

[sickpig]

 

[Zangelbert Bingledack]

No, there are two separate settings: the0 max size of the block you'll accept and the max size of the block you'll produce. BU defaults to producing blocks no larger than 1 MB.

Interestingly, what this means is that if another miner produced a > 1 MB block, the BU miners would begin to mine on top of it.

Yeah and that's why I say you'd be foolish to keep these settings as a miner right now, because there is no way the rest of the network is going to accept a block you mine on top of a >1MB block as of today. You'd lose 25BTC.

The whole point is that the miner must keep careful tabs on this setting, as that is the very essence of how Bitcoin consensus will have to emerge. Although on that view the default doesn't matter because any miner not savvy enough to know to change it is screwed anyway, I think if we want miners on board the least we can do is make the current default not be a currently irrational one for miners (or put in a warning).

After all, as @theZerg said elsewhere, BU isn't a "big blocks" client,* it's a client that gives users unlimited choice.

Another possibility is, if the idea is to avoid privileging the Core settings, simply force the user to input some numbers before the program will run. Don't even have defaults. But weighing the factors, I think defaulting to Core settings is the best move for now. Or better yet, have a two-choice menu during installation that says, "Default to Core settings? Set your own now? In either case you can adjust them later." Then people can enable currently-rational settings with a single click but there is no nannying them by forcing them into that - nor even defaulting them into that.

*which would just be more paternalism!
[doublepost=1451223286,1451222529][/doublepost]@Inca

BU isn't really just one single implementation. Modularization (giving the user options) blurs the lines of where one implementation begins and another ends, as it should be. The whole idea of implementations in the first place was born out of centralized thinking about what Bitcoin is and how it reaches consensus.

Rather than a crystalization on a single "alternative," it's a whole new paradigm: there isn't Core or alternatives with different consensus settings, rather there is an inevitable move toward the user being able to choose those consensus settings him or herself. This unbundles trusted code from the nannified consensus. Now you hire the Core/etc. devs just for their trusted security code, not for their spoonfeeding you Bitcoin consensus.

 

[sickpig]

wow it was fast.

coinbase is under DDoS attack at the moment.

 

[Zangelbert Bingledack]

@all

Check out /u/anarchystar's thread in /r/Bitcoin today. He is bringing the ideas underlying BU to the gates of Mordor!

Hopefully it hasn't been deleted.

 

[Inca]

Yeah and that's why I say you'd be foolish to keep these settings as a miner right now, because there is no way the rest of the network is going to accept a block you mine on top of a >1MB block as of today. You'd lose 25BTC.

The whole point is that the miner must keep careful tabs on this setting, as that is the very essence of how Bitcoin consensus will have to emerge. Although on that view the default doesn't matter because any miner not savvy enough to know to change it is screwed anyway, I think if we want miners on board the least we can do is make the current default not be a currently irrational one for miners (or put in a warning).

After all, as @theZerg said elsewhere, BU isn't a "big blocks" client,* it's a client that gives users unlimited choice.

Another possibility is, if the idea is to avoid privileging the Core settings, simply force the user to input some numbers before the program will run. Don't even have defaults. But weighing the factors, I think defaulting to Core settings is the best move for now. Or better yet, have a two-choice menu during installation that says, "Default to Core settings? Set your own now? In either case you can adjust them later." Then people can enable currently-rational settings with a single click but there is no nannying them by forcing them into that - nor even defaulting them into that.

*which would just be more paternalism!
[doublepost=1451223286,1451222529][/doublepost]@Inca

BU isn't really just one single implementation. Modularization (giving the user options) blurs the lines of where one implementation begins and another ends, as it should be. The whole idea of implementations in the first place was born out of centralized thinking about what Bitcoin is and how it reaches consensus.

Rather than a crystalization on a single "alternative," it's a whole new paradigm: there isn't Core or alternatives with different consensus settings, rather there is an inevitable move toward the user being able to choose those consensus settings him or herself. This unbundles trusted code from the nannified consensus. Now you hire the Core/etc. devs just for their trusted security code, not for their spoonfeeding you Bitcoin consensus.

The point is Peter, that once the network runs a client on the majority of nodes/miners that lift decisions such as max_blocksize out of being hardcoded into the software, and instead dynamically set by the market, that an irreversible change in the setting of protocol rules occurs. It doesn't matter whether it is one or many implementations it is the change that is important.

It will be nigh on impossible for Core to try and insert programmatic limits and changes to the protocol after something like BU is in the wild.

 

[Aquent]

Hope you all had a great christmas guys.

I'm in the process of updating the website and wondered if someone could write a high level summary of what bitcoun unlimited is. Specifically, how everyone can set their own limit, the fact that there is a buffer of some 5mb I think, how emergent consensus is meant to arise, how you wouldn't be forked off etc. I have been busy with other things so haven't had much time to read about it in full detail, so I can not do it myself unfortunately, but a nice summary would be really helpful to educate everyone.

Highish level though, sort of 4-5 paragraphs to be incorporated here: http://aquentus.github.io/BitcoinUnlimitedWeb/bitcoinUnlimited/index.html

I'm still in the process of taking feedback for the site, so, it is still draftish, but I would like some comments on what you guys think of the credits section. Necessarily we can not mention everyone due to lack of space (although I have linked to everyone/members page).

My thinking was @theZerg as the maintainer, @Peter__R for his huge contributions, @awemany for assisting Peter__R (not sure if your name is public @awemany?) @sickpig because he signed the binay, but I am not very sure about this one if @sickpig wishes to provide his name then that'd be fine, but we hope the site is read widely, including in family settings, and although the nick is fine, it may seem a bit unprofessional? I don't mind though, but comments welcomed. I've named myself for the website and @Graphics for the graphics but if he is anonymous and wishes to remain so then I think the mention would be a bit redundant.

All comments are highly welcomed either here or on its dedicated thread https://bitco.in/forum/threads/bitcoin-unlimited-visual-identity.206/page-4

 

[cypherdoc]

Yeah and that's why I say you'd be foolish to keep these settings as a miner right now, because there is no way the rest of the network is going to accept a block you mine on top of a >1MB block as of today. You'd lose 25BTC.

it would if 51% of the miners were mining with BU.

 

[cypherdoc]

what is this craziness?:

"A better long term solution may be provable computing, plus multisig, with miners verifying that transactions have been signed by Blockstream or another entity in that the node/wallet they are running is compliant with Bitcoin consensus rules."

https://github.com/bitcoin-dot-org/bitcoin.org/pull/1178#issuecomment-167382418

 

[Inca]

The more I read about this stuff, the more I think bitcoin needs to decisively break out of this centralised governance disaster. Should bitcoin emerge it will spark a mega relief rally.

 

[Justus Ranvier]

what is this craziness?

A few people have claimed that's TradeFortress's account.

 

[theZerg]

@Zangelbert Bingledack You are correct, today I'd set my max mining size to 1MB, and my excessive size to 1MB. So you would not mine on a big block fork until other people have done so.

I think we may need to tweak the "accept depth" semantics a bit. Let's say that the miner sets it to 4 blocks, and fork is created where EVERY block is excessive. Today IIRC the miner will always be 4 blocks behind a hash-rate majority, the user will always be 4 blocks behind the chain tip.

But the more I think about it the more I think that the algorithm should be to look for the FIRST INSTANCE of an excessive block on that chain. After all the point of accept depth is to prove that there is significant hash power on a chain, compared to someone who just got lucky. And if the first instance is > the accept depth, the chain is accepted.

So the difference between this proposal and today is that after 4 "excessive blocks" the miner pops to the chain tip rather than always trailing it.