Gold collapsing. Bitcoin UP.

[albin]

@sickpig

Very interesting subtle bait-and-switch going on with respect to fee markets, it looks like he's given up on the economics of regular monetary transactions and wants to turn op_return into the bogeyman:

Since Bitcoin is an electronic cash, it _isn't_ a generic database;
the demand for cheap highly-replicated perpetual storage is unbounded,
and Bitcoin cannot and will not satisfy that demand for non-ecash
(non-Bitcoin) usage, and there is no shame in that.

 

[Justus Ranvier]

OK, the way I imagine UTXO commits is that the miner, when building a block, would include hash of the UTXO set corresponding to that block (or a previous block). All the other miners and nodes would then validate this hash, and refuse to mine on top of the block if the corresponding UTXO is deemed non-valid. So it's not really blind trust, it would be validated just like the rest of the block. UTXO commits buried under long proof-of-work chains should be fairly trustworthy.

The key point is that right now full node security means that no mining majority, not even 99.9% of the hashing power, can fool you with invalid blocks.

If the miners try to raise the block reward, or allow spends of non-existent coins, or anything else that violates the protocol, your node will reject those blocks as if they were never mined at all. As far as your node is concerned, those messages might as well have been a Rickroll video mistakenly broadcast on the Bitcoin network instead of a block no matter how much proof of work they represents.

SPV nodes (as they are currently implemented) can't do that. All they can do is some basic header checks. If a majority of the miners started giving themselves a 100 btc/block reward today, every SPV client in the world will happily follow their chain because it has the highest proof of work.

Fraud proofs are about allowing clients that do not have a complete blockchain to conclusively know that the chain with the most proof of work is invalid and thus should be ignored.

The situation model where fraud proofs are relevant and needed is the situation where a majority of hashing power is extending an invalid chain, so you can't say that fraud proofs are unnecessary because a majority of miners have agreed on something (like a UTXO set commitment).

 

[Mengerian]

@Justus Ranvier OK, thanks for the clarification. I think the subtlety I was missing is that the information needed for fraud proofs can itself be checked by a fraud proof. Ie, the "fraud proof" is not just a tacked on piece of information that you need to trust miners to validate.

 

[Melbustus]

gmax latest email on btc dev -
Capacity increases for the Bitcoin system

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Some excerpts:

Since Bitcoin is an electronic cash, it _isn't_ a generic database; the demand for cheap highly-replicated perpetual storage is unbounded, and Bitcoin cannot and will not satisfy that demand for non-ecash (non-Bitcoin) usage...

Trying to engineer exactly what people use Bitcoin for...

...and without its anticipation and earlier work such as headers-first I probably would have been arguing for a block size decrease last year.

Yikes.

...while still catching up on our decentralization deficit.

"deficit" defined how so?

I had good success deploying an earlier (hard-fork) version of segwit in the Elements Alpha sidechain; the soft-fork segwit now proposed is a second-generation design.

I like parts of segwit, but as a solution for scaling, it's far more dangerously complex than the simple solutions (BIP101/BU) on the table.

Further out, there are several proposals related to flex caps or incentive-aligned dynamic block size controls based on allowing miners to produce larger blocks at some cost.

No. This is both more complexity, and more econo-engineering. This is sort of thinking is exactly what needs to stop.

...will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase).

So what's being offered is an eventual can-kick *iff* segwit and some other stuff happens.


That email makes a near-term BIP101 hard-fork *more* desirable in my opinion.

 

[cypherdoc]

@sickpig

Very interesting subtle bait-and-switch going on with respect to fee markets, it looks like he's given up on the economics of regular monetary transactions and wants to turn op_return into the bogeyman:

of course. if he can kill all Bitcoin 2.0 hash insertions into OP_RETURN, this might force not only regular tx's from MC to SC's but also asset riders, like NASDAQ or Fidelity assets to SC's.

what's disgusting is how fast they move when they want their own pet projects inserted into code via "soft forks" (must be OK!) vs. competing upgrades like 101 which would kill all uses for their Blockstream products.

 

[Justus Ranvier]

@Justus Ranvier OK, thanks for the clarification. I think the subtlety I was missing is that the information needed for fraud proofs can itself be checked by a fraud proof. Ie, the "fraud proof" is not just a tacked on piece of information that you need to trust miners to validate.

For fraud proofs to work, you have to add a requirement to the protocol that miners include the information needed to falsify their blocks in order for those blocks to be accepted by non-miners.

The non-inclusion of this information (which can be demonstrated by a fraud proof) then becomes grounds for rejecting a block even if it would otherwise be valid.

 

[solex]

gmax latest email on btc dev -
Capacity increases for the Bitcoin system

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

So, the latest transition is complete and a new chapter is started for Bitcoin Core:

Bitcoin Chief Architects
Satoshi Nakamoto: 2008 (whitepaper) - Dec 2010
Gavin Andresen: Dec 2010 - April 2014
Wladimir van der Laan: April 2014 - Dec 2015
Gregory Maxwell: Dec 2015 - ?

The question is now for the Bitcoin ecosystem. Will the Maxwellian vision of small blocks, segwit first, high main-chain tx fees, privileged side chains & LN-type off-chain solutions encapsulate the demands of present and future Bitcoiners? Or will alternative clients with an emphasis on main-chain scaling, IBLT, segwit later, LN-type off-chain solutions having to compete with the main-chain for user tx rise to the fore?

 

[Mengerian]

@Justus Ranvier Thanks, got it

gmax latest email on btc dev -
Capacity increases for the Bitcoin system

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

My summary: "Let's not increase blocksize at all anytime soon, instead we'll do all these fancy technical whiz-bang changes to the protocol that may marginally increase transaction capacity"

Reading some of the reaction on Reddit reminds me of peoples' initial reaction to sidechains. It comes across as a magic bullet that is supposed to solve all our problems. Over time though, reality will set in, and all the little technical details won't seem so little anymore.

If I understand, all wallets, even SPV wallets, would have to be upgraded to handle the new transaction type.

 

[rocks]

The key point is that right now full node security means that no mining majority, not even 99.9% of the hashing power, can fool you with invalid blocks.

If the miners try to raise the block reward, or allow spends of non-existent coins, or anything else that violates the protocol, your node will reject those blocks as if they were never mined at all. As far as your node is concerned, those messages might as well have been a Rickroll video mistakenly broadcast on the Bitcoin network instead of a block no matter how much proof of work they represents.

SPV nodes (as they are currently implemented) can't do that. All they can do is some basic header checks. If a majority of the miners started giving themselves a 100 btc/block reward today, every SPV client in the world will happily follow their chain because it has the highest proof of work.

Fraud proofs are about allowing clients that do not have a complete blockchain to conclusively know that the chain with the most proof of work is invalid and thus should be ignored.

The situation model where fraud proofs are relevant and needed is the situation where a majority of hashing power is extending an invalid chain, so you can't say that fraud proofs are unnecessary because a majority of miners have agreed on something (like a UTXO set commitment).

Thanks for the explanation. Even without fraud proofs it is still possible to have a high degree of confidence in a system. Fraud proofs provide absolute cryptographic certainty, but there are other mechanisms that almost full certainty.

Let's use the UTXO commit set example, where each block contains a hash of the current UTXO set and fully validating nodes start assuming the UTXO commit set for the latest block is valid. And let's also assume that 60% of the miners started to create a false chain giving themselves 100BTC/block rewards. Yes a new node entering the system would and using the UTXO commit set would not be able to detect this. However that node does not have to.

There only needs to be a single node in the entire world that maintains the full transaction history to identify, flag and provide proof of the corruption. That single node would be able to provide cryptographic evidence to the world that the current UTXO set is invalid and which chain all nodes should reject.

As long as no entities are shouting that the current P2P chain is corrupted, you can be very confident it is secure. It the current P2P chain ever does become corrupted, it is very easy for 1 node to highlight this to the world.

Personally that is enough confidence for me. Maybe it is only 99.9999999999999999999% secure, I can live with that. The problem with the blockstream devs is they are trying to force 100% confidence into the system, and breaking it for everyone else in the process.

Edit: BTW, This method of probability based economic or market confidence is the exact same as the cryptography Bitcoin already relies on. The hashes Bitcoin relies on are NOT 100% secure, they are only 99.999999999999999% secure. Same with the private keys. They are not 100% secure, it's just the odds of someone replicating one are extremely small. But the odds are not zero.

 

[cypherdoc]

"I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically
important long term."

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

 

[Justus Ranvier]

"I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically
important long term."

I know somebody personally who is working on a startup that intends to add 100 million new daily Bitcoin users before the end of 2017.

Who knows how many other projects like that are floating around in the background?

 

[lunar]

@theZerg

Would the idea of BUIP commit voting work? Imagine every commiter is issued a colored coin voting right, say one for every successful commit accepted, they get a right to vote whether certain future BUIP ideas are accepted into the main repo(or every 5, whatever?)
At this point once BitcoinUnlimited is up and running, if a BUIP gained 51% positive vote it would automatically be merged?

This could work like an Augur prediction market. It would incentivise companies to have developers working directly on BitcoinUnlimited, thus also having a voting right (anonymous?) on project direction. Furthermore it would provide and clear predictable path for the project development, that the whole world could follow.

 

[AdrianX]

yes... I can see your perspective. BUT I feel that the traffic shaping code is very important for scalability. I mean, just because you have a 5, 25 or 50 MB connection doesn't mean that Bitcoin should be allowed to consume all of it.

Bitcoin is driving users away because Bitcoin Core does not play nice with other network uses like Netflix or Amazon video streaming. With traffic shaping on, you really just start it up and can completely forget that its even running.

You could head over to the BUIP discussion and make an argument; voting happens in a few days...

A barrier to BU adoption imo will be FUD. I'd start with just the block cap change and add the other changes in as needed or even at the slightest hint of need.

Just changing the CAP vastly reduces the risk of FUD when it comes to understanding of other features.

 

[lebing]

This segwit solution is looking pretty solid to me. Here are some great explanations that helped me get to this position:
https://www.reddit.com/r/btc/comments/3vt1ov/pieter_wuilles_segregated_witness_and_fraud/

 

[theZerg]

This is being run as a benevolent dictatorship until jan 15. Normally the Developer would produce a counter BUIP... since that can't happen if a counter emerges from discussion I say let's add it to the vote. BUT we need discussion to take place in the BUIP001 thread because we can't expect ppl to wade thru this one just to pull out the relevant parts.

We'd need to address stuff like longevity testing because I can't run a non shaped node on my home network for more than a day or 2.

 

[theZerg]

@ lunarboy I've been considering some very fun integrations between git, voting and bitcoin similar to what you are thinking about.

But in the context of BU there are issues:
1. We feel it is important to include people from other disciplines.
2. Better to concentrate dev time on bitcoin right now.
3. There IS a system of checks and balances. In this case the Dev's commit access can be revoked.
4. Its important to be able to vote on unimplemented BUIPs. This will allow a company or individual to not waste time and $ on an effort that gets voted down.

 

[Justus Ranvier]

After I read this article, it occurred to me that ransomware is going to bring down governments.

https://securityledger.com/2015/12/senators-probe-governments-history-with-ransomware/

Sooner or later, disgruntled public sector workers are going to realize that if somebody on the other side of the world can infect the office computers and get a bitcoin payout, then so can they.

The odds of getting caught will be low, and even if the agency decides not to pay they'll still get a day or two off because it will be impossible to work with the network down.

A lot of people talk about the monetary problem Bitcoin represents for governments, but I actually think the HR problem Bitcoin represents is even more significant.

 

[JVWVU]

@Justus Ranvier - I am watching tonights episode of Scorpion and just what you are saying is what the show is about. Including the ransonware "kidnappers" asking for a quarter of a billion dollars of bitcoin.

That would be almost 1/24th of all coins right now, what would that drive the price to?

 

[Justus Ranvier]

I am watching tonights episode of Scorpion and just what you are saying is what the show is about.

If the idea of insider-spread ransomware has already reached mainstream television, then it's probably too late to start a "ransomware as a service" business catering to that market segment because somebody is already about to launch one.

 

[Zangelbert Bingledack]

@theZerg

On traffic shaping, while I agree with others that KISS is the right approach for dealing with FUD, it seems that if the traffic shaping is completely optional and off by default, there should be no problem.

It could be marketed as "Core+No cap+Optional traffic shaping."