Gold collapsing. Bitcoin UP.

[Justus Ranvier]

You must have some very big windows in your house.... you saw that one coming.

If you search my posts, I said it last year too.

Peter Todd, et. all. have talked about this possibility since that John Dillion leak in 2013, and he in particular has repeatedly demonstrated a willingness to engage in black hat attacks in order to get his way.

It's not a difficult prediction to make.

At every stage of this debate, when Blockstream/Core doesn't get their way they drop one more pretense of good faith behavior.

Before the fork happens they will drop all pretenses.
[doublepost=1489522197][/doublepost]
http://archive.is/FK5GD

https://archive.is/lusfj

 

[awemany]

Ouch!

But we'll get through this.

On another note: This non-standard use of assert(..) should be abolished IMO. Call it fail_if(..) to make it explicit.

 

[Dusty]

That won't happen because of how channel formation will work.

You're imagining a situation where existing Bitcoin users move their own on-chain funds into a channel with a bank.

That situation represents a negligible fraction of a real-world LN users.

Most users in a LN scenario obtain bitcoins through their bank, which means it's the bank's bitcoins being encumbered by the channel.

When the banks figure out those opening transactions never need to confirm, they can over-commit their utxos to customer channels.

From the perspective of every LN client, an unconfirmed channel is perfectly valid - they have no way of knowing whether 1, 10, 100, or 1000 channel transactions all spend the same inputs.

That's perfectly understandable, but there is no difference from actual schemes where people leave their bitcoins to third parties like coinbase or all the exchanges.

So, in this respect, the LN is not adding a new way to create fractional reserve bitcoins.

 

[molecular]

now what's the path of action for node operators with crashed nodes?

pull release branch from https://github.com/BitcoinUnlimited/BitcoinUnlimited.git, recompile and get the node backup up, I'm guessing?

 

[go1111111]

Ouch!

But we'll get through this.

This is exactly why a very simple patch on top of Core allowing users to set an EB setting (with implied infinite AD, to keep it simple) is so important.

I've brought this up multiple times and get the response "Who are all these people who want bigger blocks but don't want the rest of the BU code changes? I've never seen them!"

I believe there are a lot of people out there who want bigger blocks, but who aren't really sure about BU's code quality and like the engineering competence of Core. These aren't the people who are most vocal on reddit and twitter. They're just regular users.

A simple patch on top of Core does two very important things, (1) provides a good option for people who want bigger blocks but also want to be conservative about the code that they're possibly trusting a lot of their net worth with (2) Therefore, reduces the time between now and when those wanting bigger blocks have a hash power majority.

 

[Justus Ranvier]

By the way, crash bugs in network daemons are merely annoying if the daemon is configured to auto-restart using an appropriate daemon manager.

Both runit and systemd support this.
[doublepost=1489526011][/doublepost]

So, in this respect, the LN is not adding a new way to create fractional reserve bitcoins.

Not as such, but LN proponents who are trying to make real Bitcoin transactions unavailable are working to create a situation where a run on the bank is can't be performed, and so fractional reserves are impossible to avoid.

LN is not a threat to Bitcoin's supply integrity in the absence of a block size limit.

OTOH, without a block size limit it's unclear if anyone would ever use LN at all.

 

[Dusty]

New By the way, crash bugs in network daemons are merely annoying if the daemon is configured to auto-restart using an appropriate daemon manager.

Both runit and systemd support this.

Yes, but a malicious user can remember your ip and as soon your node comes back online send you the packet to crash you again, thus rendering your node completely useless.
Also, each time the node is restarted he has to scan the blockchain headers, recover from a database crash, etc.
A lot of time is needed to startup and only a second to crash: not good :-(

--- Double Post Merged, 43 minutes ago ---
Dusty said: ↑
So, in this respect, the LN is not adding a new way to create fractional reserve bitcoins.
Not as such, but LN proponents who are trying to make real Bitcoin transactions unavailable are working to create a situation where a run on the bank is can't be performed, and so fractional reserves are impossible to avoid.

I do agree, but the cause of that is a (very) limited block size, not the LN per se.

OTOH, without a block size limit it's unclear if anyone would ever use LN at all.

I can envisage a host of new use case scenarios if there is the possibility of doing an unlimited number of instant 1-satoshi transactions. That could rebuild the whole web by paying an incredibly small amount for a single page view, or for a video, etc. This could also be useful to limit mail spam.

Automated microtransactions can enable new business model never thought before, and I'm sure someone will think interesting applications: I don't think we have to fear new payment technology, if this is not done to artificially limit our capacity for normal bitcoin transactions.

Also, LN badly needs a blockchain to work and function properly, so I hope it will use Bitcoin and not some shitty altcoin that could take more value otherwise directed toward Bitcoin.

 

[VeritasSapere]

@go1111111 Regarding UASF, I do think it is definitely vulnerable to a sybil attack, in many ways it is the reason why we even need POW in the first place, it is proof of positive incentive, proof of work. On the other hand @Zangelbert Bingledack has a point in that such a course of action is a viable strategy in a worse case scenario, since ultimately after the split the winner will be the chain with the most economic value regardless of UASF or any other method of forking and splitting the chain. In many ways it reveals how desperate the other side has becoming whether consciously or not.

A User Activated Soft Fork is almost the equivalent of doing a POW change, it is actually the small blockist equivalent of MVF over at r/btcfork, it is a secession from the Bitcoin protocol, which definitely can be justified and should even be viewed as a critical function of the Bitcoin protocol itself, it solves the problem of the tyranny of majority, this is one of the ways how Bitcoin can represent freedom.

 

[adamstgbit]

BU nodes appear to be under attack, someone has already crafted the garbage msg that will crash the nodes?

http://nodecounter.com/#bitcoin_unlimited

 

[go1111111]

I just published "Two Theories of Bitcoin": https://medium.com/@Mengerian/two-theories-of-bitcoin-f4da84468a7a#.x7yh3yqbg

It's a description of the theories of Extreme Consensus and Market Consensus.

Wow, this article is pretty much perfect. I was working (painfully slowly) on a less good version of the same article, which I alluded to here:

After a couple months of vacationing, I'm now ready to write this post [about hard fork governance].

I think I'll try to convert my half finished article into a more detailed market consensus FAQ. Mengerian if you're already working on something like that, let me know. I think you (and Roger and Zanglebert) are better at explaining this stuff clearly than I am, but maybe my raw notes would help you.

 

[Mengerian]

Thanks @go1111111, Glad you liked it!

You reminded me, I should thank @Roger_Murdock and @Zangelbert Bingledack who contributed editing and feedback for the article, which made it way better than it otherwise would have been!

My next one I'm working on will be about how Bitcoin can hopefully get around problems of diffuse cost / concentrated benefit that one often sees in traditional non-market based institutions. But who knows, often the topic shifts as I'm writing.

I'm not planning on an FAQ, I'd be happy to help review yours, look at your notes, or whatever you think would be of assistance.

 

[Zangelbert Bingledack]

@go1111111 I'd also be happy to review your notes.

 

[Windowly]

Coinbase has decided to stop paying miners' fees starting next week, citing the growing cost. This might cause the complaints about high fees to really escalate.

 

[lunar]

This might be psychological projection, but has anyone else noticed how the r/btc sub has seemed much more like the 2012/13 Bitcoin reddit recently?

I can feel an optimism and defiance that naturally develops from a bulletproof philosophy.

R/Bitcoin - The modern buttcoiners don't stand a chance. The intellectual vacuum, cognitive dissonance and festering toxicity that Theymos has created, leaves anyone outside it's walls, very ill prepared to face a harsh reality.

As a terrible coder, I found the most informative article of the day on R/Buttcoin of all places. Very clearly explained what happened yesterday.

http://blog.erratasec.com/2017/03/assert-in-hands-of-bad-coders.html

The Tide Has Turned.

 

[Dusty]

Thanks for the link to the erratasec article: it shows that the Core "top coders" use very bad coding practice, at least with the use of asserts.

 

[satoshis_sockpuppet]

As a terrible coder, I found the most informative article of the day on R/Buttcoin of all places. Very clearly explained what happened yesterday.

http://blog.erratasec.com/2017/03/assert-in-hands-of-bad-coders.html

The Tide Has Turned.

Example 4 isn't the feature that crashed BU yesterday (if I'm not mistaken) and doesn't directly depend on peer input.

The use of assert() actually seems to be very unusually so I guess someone had to make a mistake like that someday. (I guess, Peter Tschipper assumed the assert wouldn't survive the release compilation and didn't think of Bitcoin core's "special needs"... :/ )

I'm very surprised how fast the nodes were up again and the PR damage seems to be manageable. From an objective standpoint that showed pretty clear, that we need more implementations (and better not just forks of C++ Bitcoin). I have the feeling that a bug like that sleeps deep in the messy C++ code base BU, Core, Classic and XT share and waits to be attacked someday.

 

[dgenr8]

https://np.reddit.com/r/btc/comments/5yto3a/2_more_clients_signal_for_emergent_consensus/

@dgenr8 : are both the Satoshi and XT clients which signal this running your BIP100 modifications, or is there another group who is signaling with a modified client?

Those are both testing our BIP100 implementation.

 

[lunar]

@satoshis_sockpuppet How would you reword example#4 to make it correct for the BU Xthin situation?

 

[satoshis_sockpuppet]

Never mind, he was correct. But that doesn't exist in core, just in classic.

btw, the main.cpp is renamed validation.cpp or something like that in core.

 

[Zangelbert Bingledack]

The comments following this are a fascinating window into the mind of a BU detractor.