Gold collapsing. Bitcoin UP.

[Peter R]

The more I think about it, the more I'm convinced that it's going to be REALLY difficult to attack Bitcoin Unlimited (or a BU-like approach) in a convincing manner. Seriously, how does that conversation go?

BU Critic: "Big blocks are dangerous because they promote mining centralization as a result of the self-propagation advantage of..."

BU Supporter: "Whoa, whoah, whoah. BU isn't a 'big block' proposal. Nor is it a 'small block' proposal. It's not a block size proposal at all. It's simply a tool for letting the market flexibly decide the appropriate size of blocks in a decentralized fashion. In fact, there's no reason BU couldn't be used to enforce a smaller block size limit than the one suggested by Core."

BU Critic: "Ok, but we can't just allow miners and nodes to decide for themselves what size blocks they'll mine / accept! That's madness."

BU Supporter: "What do you mean 'allow'? There's no way to stop them. Bitcoin has always been defined by the code that people choose to run and the version of the ledger that people choose to value. All BU does is remind us who was really in control of Bitcoin all along (i.e., the market) by removing an unsustainable 'inconvenience barrier' that artificially strengthened the Schelling point defined by Core's recommendations."

BU Critic: "But hard forks are dangerous! BU might break consensus!"

BU Supporter: "There are overwhelming game-theoretic incentives favoring uniformity. The network WILL converge on a single version of the ledger as an emergent block size limit is discovered and enforced."

BU Critic: "But the Core devs are like, super smart. We all just need to trust that they know what's best when it comes to the block size limit."

BU Supporter: "So, in a system designed to be trustless and decentralized, we're supposed to blindly trust the decisions of a centralized entity?"

BU Critic: "Um... yes?"

Great post!

On this topic, another talking point Core uses against BU is that BU simply "doesn't work." For example, here is Adam Back on Bitcoin Unlimited:


Adam is knowledgeable enough (I think) to understand that BU will follow consensus as defined by the longest proof-of-work chain composed of valid transactions. So his claim that it will "insta fork" is just silly. If you push the small-blockers further, they will admit that "indeed BU will follow the longest proof-of-work chain," but they'll add the disclaimer "that chain won't be Bitcoin--it will be an altcoin instead."

Basically, this allows them to make a disingenuous FUD statement (BU will fork from Bitcoin) which is only true if you simultaneously believe that Bitcoin = Core. What matters to most people is tracking consensus. By any normal definition of "Bitcoin," it is only Core that would be at risk of "insta forking" if it dogmatically adhered to 1MB against overwhelming support for larger block sizes.

 

[_mr_e]

And thats precisely why I gave him the response that I did. He's clearly playing dumb.

 

[Aquent]

News at Ten. Adam Back scared to come down, condones bitcointalk censorship. Prefers tweeter soundbite propaganda...

 

[Aquent]

Final shots? https://www.reddit.com/r/btc/comments/3z6a1k/adam_back_condones_censorship/

 

[Bagatell]

News at Ten. Adam Back scared to come down, condones bitcointalk censorship. Prefers tweeter soundbite propaganda...

https://bitcointalk.org/index.php?topic=1312371.msg13428944#msg13428944

 

[Peter R]

There are things going on behind the scenes too. I suspect Blockstream wants to keep "negotiations" going so that Core retains the appearance of legitimacy for longer.

But Core has made its decision. There will be no increase to the max block size limit by Core in 2016.

Personally, I welcome Adam to come to this forum and offer some constructive criticism regarding Bitcoin Unlimited. The more people helping, the quicker we can move away from the single governance entity that presently controls and handicaps Bitcoin: Core.

 

[Matthew Light]

I invited Adam to this thread, which someone else created for the purpose of debating technical issues and merits of BU:

https://bitco.in/forum/threads/invitation-for-bitcoin-unlimited-proposal-review.715/

He responded that he is willing to discuss in a thread he created on a forum censored by Michael Marquardt, but not willing to participate here.


Hopefully people can encourage him to change his mind.

 

[Justus Ranvier]

Hopefully people can encourage him to change his mind.

Is it really worth making the attempt?

Everybody should be given ample opportunity to demonstrate good faith, but if they continually fail to exploit those opportunities at some point you have to break out of the sunk cost fallacy and move on.

 

[cypherdoc]

@Matthew Light

Adam did NOT get there first, as in start the BCT thread, before I had sent him this tweet earlier this morning. 8:39am vs 9:58am:

 

[Zangelbert Bingledack]

Here's my attempt:

https://bitcointalk.org/index.php?topic=1312371.msg13429654#msg13429654

I didn't cover acceptance depth as the post was already too long, and since he doesn't seem to understand emergent order it would open yet another big cans of worms and the convo would never end (focusing on a few key points is, well, key). If he doesn't understand emergent order, that is great news because if he can be made to understand it a lot of progress may be made.

I get that it may be a lost cause, but it's worth a few hours of my time as while Adam may have some huge blind spots and of course the CoI, he's above all an academic and isn't averse to updating from time to time.

 

[Aquent]

Obviously everyone is a free spirit, but I don't think he should be engaged in a censored forum. We were made to go away from that place and he now is somewhat overtly condoning that censorship, and not just in bitcointalk but in reddit too, so there is no reason to go back there and be at the mercy of the ban hammer, especially not to discuss with a person who clearly seems to want to shun light and walk in the dark.

 

[Roger_Murdock]

It seems to me that there are three ways you can criticize Bitcoin Unlimited.

1. You can criticize the idea behind BU, i.e. the recognition that Bitcoin is always defined by the code that people are willing to run and the notion that the (in any case, unsustainable) "inconvenience barrier" to code changes should be lowered to promote decentralization of development and implementations.
2. You can criticize BU's actual implementation of that idea, e.g. "the code doesn't handle this edge case appropriately" or "it doesn't include this feature that most people would find to be very useful" etc.
3. You can criticize BU by assuming that the people who use it will set their parameters once in a completely retarded manner without any concern for what others are doing, and then walk away without any kind of ongoing monitoring of what's actually happening on the network. (After all, if your blocks keep getting orphaned, it's only what, ten grand a pop at current exchange rates?)

Type 1 criticisms I don't find terribly convincing for reasons I've outlined previously. (It's especially hard to make Type 1 criticisms when you're a micro-blocker who has proclaimed that your support of itty-bitty blocks is based on your deep and abiding love for "decentralization.")

Type 2 criticisms are of course welcome and can only serve to make Bitcoin Unlimited (or an alternative implementation of the ideas behind it) a better offering.

Type 3 criticisms are well, retarded for fairly obvious reasons.

Am I missing any categories?

 

[Zangelbert Bingledack]

@Roger_Murdock

I think that's correct. Type 1 should be the bulk of it over the longer term at least, because BU is more than just software, it's also a question: "What are you so afraid of? If the market agrees with you, why not open up Core settings that are controversial?" That makes Type 2 criticisms a bit of a dead end. BU is an idea, and the genie is out of the bottle.

Type 3 criticisms can be dealt with by BUIP002, which would let users track whatever behavior Core/etc. has in its latest offering. In fact, arguably a non-dynamic client like Core is worse off here, as the user would have to wait for Core to supply an update if things got dicey. With the advance of specialization within the industry, it would be the nodes/miners that would end up being the experts on what to do in such situations, rather than the cryptographers and code optimizers working at Core dev.

 

[theZerg]

We have provided github checkins, multiple papers on theory, and BUIP001. Adam obviously hasn't read them as he is making incorrect assumptions BU behavior. If he isn't willing to read these I'm not willing to waste my time educating him via Twitter sound bytes or painful Q&A on a censored forum, sorry.

 

[Matthew Light]

Agree, we should not be posting in a censored forum except to invite people to come discuss things on uncensored fora.

 

[JVWVU]

Why are we screwing with Adam Back when we know he is in it for a paycheck right now.

The shit I am seeing in my twitter feed makes it look like a teen bitch fight.

The technology discussion goes above my comprehension but there are people I trust for that.

We need to focus on getting key individuals in our corner to then move forward, IMO these individuals are

Gavin, Garzik, Ver, Oliver Jansens, Bruce Fenton, New Liberty (who would be my choice to review code), Fred Eshram, Andreas, Pierre rochard, work on trying to get 1 a day to lead to BU development and in the future others will follow

 

[Melbustus]

We have provided github checkins, multiple papers on theory, and BUIP001. Adam obviously hasn't read them as he is making incorrect assumptions BU behavior. If he isn't willing to read these I'm not willing to waste my time educating him via Twitter sound bytes or painful Q&A on a censored forum, sorry.

Also, when someone pointed out (on twitter) this forum to him as a discussion venue, he responded that he doesn't like "invite only" fora. So he's obviously under at least one misconception, but probably many...I assume by virtue of spending time surrounded by hardcore small-blockers. I think Adam is at heart a reasonable guy, with good motivations. If he were sitting in an office every day with some of the more well-spoken big-block proponents, I think the misconceptions would be gone, and there's a chance he'd start to have a better appreciation for free-market incentives/solutions in bitcoin.

 

[YarkoL]

First off, I want to thank Zangelbert Bingledack for responding
to the bitcointalk thread that Adam Back started. It has sparked
off some lively discussion and so far the participants have managed
to keep the gloves on.

The criticisms offered by Core supporters set me thinking.
I haven't read all the threads on this forum, so apologies if what I'm about
to propose is already chewed over.

From what I have understood so far, It seems that the way to determine the
"good" block size in order to avoid being ending up on an isolated fork is to
constantly monitor what other users are doing.
Presumably this means taking part in discussions and following media, and
these activities incur a cost. Not all users will have the time. It ought to be
possible to optionally put the block size limit on "autopilot", so that it
dynamically changes without the user intervention. AFAICS this can be
accomplished by making the client advertise its preferred block size limit
to the network and then give some recommendation to the user based on data
it has encountered. There might be several recommendations based on different
statistical methods. (edit: of course this approach could be thwarted by sybil
attack, and using the excessivedepth already gives information about other
users. Oh well I keep learning)

 

[Zangelbert Bingledack]

So he's obviously under at least one misconception, but probably many...I assume by virtue of spending time surrounded by hardcore small-blockers.

That's the thing with sycophants. Surround yourself with them at your own peril. Not saying all small-blockers are sycophants, but some certainly are and I assume they've been feeding him false information like that this forum is censored or "invite-only." Spending time in that Bubble Boy world rots the mind. Let's just make sure this forum doesn't becomes its own bubble. Where did @Yoghurt114 go?
[doublepost=1451773456][/doublepost]@YarkoL

I imagine that blocksize cap settings would usually only change occasionally, with a lot of advance notice - just as now. Mining consortiums, business organizations, etc. could put out recommendations, devs would have proposals, there would be debates (less heated ones), polling would happen, maybe the client would support some kind of communication on blocksize plans, "flag days" might be set, etc. I mentioned one scenario in that thread a few minutes ago. And of course any popular implementation's scaling method could be mimicked, as in BUIP002.

 

[Justus Ranvier]

Here's a chart that should exist, but I have not yet seen:

The odds of a bitcoin transaction being reversed start off high with 0 confirmations and drop stepwise with the first confirmation and each additional one.

The odds of a LN transaction being reversed are related to the odds of a dishonest participant being able to cheat and prevent the victim from broadcasting a refund transaction during the critical interval.

That risk is probably either constant with time, or else maybe increases with time since channel opening.

The odds of a LN reversal are probably lower than that of a 0-conf bitcoin confirmation, but the risks should cross over at some point.

It would be great to 1) know how many confirmations that takes, and 2) see it represented graphically.