Gold collapsing. Bitcoin UP.

[sickpig]

@awemany re node pruning: as far as I know regardless the way you apply pruning the node has to download the entire blockchain before discard part of it, maybe this is the reason why gmax state that pruned nodes.are still full validating nodes.

 

[Melbustus]

@Melbustus I agree and think that these companies really ought to invest in mining as a strategic move to help ensure their vision happens. And its not like its even a losing proposition -- they could band together and situate a co-mining space near a hydro dam in Canada or northern USA.

WRT BU, we could put redundant relay nodes just outside of the GFC and work with Chinese miners to solve whatever connectivity problems they are having, even if it means communicating blocks via skype or something.

Agree on both points.

I think historically the mainstream VC and startup space has largely been looked at mining as sort of the dirty underbelly of bitcoin. While many VCs and bitcoin-company founders personally hold bitcoin (and therefore understand and appreciate PoW mining), the businesses they're interested in building are targeted to specifically solving a problem, building new platforms, etc. Mining, by comparison, just looks like an uninteresting, somewhat greedy, endeavor.

That's obviously shortsighted, and I think the timing is ripe for companies to financially get behind the right sort of mining enterprise, which I think is a non-profit as defined in the BU Articles.

And the overlay component can work to attract and accumulate small-miner hashpower...

Let's use $500/btc... After the halving, that's $900,000/day = $328M/yr. If the pool had 20% of hashpower, it'd be paying out ~$66M/yr. A 2% overlay to miners would only require $1.3M in donations for the year.

 

[awemany]

@awemany

I don't think pos stakeholder voting has a chance in hell. I for one would never pull out all my cold wallets simply to vote.

Yes, that's probably the big blocker (no pun). Though that's why I described stakeholder voting by first transferring your voting rights from your cold storage coins to a (otherwise useless, low-value) voting address.
Which is probably still something most people with cold storage wouldn't implement, unless they start using it. In any case, I think this is still a 'hard' fall-back should blocksize progress stall completely.
I have to say I like the idea, but I also have to admit the security issues make me wary to ever use it - unless absolutely necessary.

Anyone else notice how many people are hanging around this forum today reading this thread?

Be on your best behavior

Oh, hi Greg, hi Adam, you're all welcome to join the discussion

 

[cypherdoc]

@awemany re node pruning: as far as I know regardless the way you apply pruning the node has to download the entire blockchain before discard part of it, maybe this is the reason why gmax state that pruned nodes.are still full validating nodes.

yep, that should be a given.

 

[theZerg]

What is your idea to transfer voting rights between coins? I had the idea that you could generate a separate key pair, sign the public key once with your coins and then use the corresponding private key to vote multiple times so long as the coins aren't moved.

But it sounds like your idea may be more elegant or at least more easily accomplished within the bitcoin framework.

 

[awemany]

@awemany re node pruning: as far as I know regardless the way you apply pruning the node has to download the entire blockchain before discard part of it, maybe this is the reason why gmax state that pruned nodes.are still full validating nodes.

Yes, that is what I first thought, too, and I have to say I cut up the quote parts not how I actually wanted to. The interesting bit (and what I am actually refering to) is the following statement:

The proposed fraud proofs elevate lite clients to full node security when some connectivity assumptions are met.

[doublepost=1449523187][/doublepost]

What is your idea to transfer voting rights between coins? I had the idea that you could generate a separate key pair, sign the public key once with your coins and then use the corresponding private key to vote multiple times so long as the coins aren't moved.

But it sounds like your idea may be more elegant or at least more easily accomplished within the bitcoin framework.

No that would be about my idea. Basically you have coins on addr A and you sign statement 'addr B can vote for me / signed, A'. And then you just sign using B. The statement would of course be formalized and machine-readable to automate this all.

 

[cypherdoc]

i did say "bullish flag" the other day, didn't i? boing, boing!:

 

[awemany]

@cypherdoc

Maybe just the statement/announcement that Coinbase, Bitpay, Bitstamp or whoever are going to build miners to proceed with BIP101 would be enough to get this issue solved?

EDIT: Oops, sorry, wrong nick.

 

[rocks]

@awemany re node pruning: as far as I know regardless the way you apply pruning the node has to download the entire blockchain before discard part of it, maybe this is the reason why gmax state that pruned nodes.are still full validating nodes.

Pruned nodes first establish for themselves a provably correct UTXO set by validating all nodes from the genesis block. Once the UTXO set is established a full node can throw away all historical blocks and still function as a full node with the current UTXO set and new blocks as they are created. Today the only way to create a provably correct UTXO set is to valid all historical blocks.

This is why I still believe we will move to some sort of UTXO confirmation set at some point. A full node does not need to store or even process the full history, it only needs a UTXO set it can trust and the header chain. In 100 years it would be absurd to expect a new node to process the full history, and completely unnecessary.

 

[awemany]

@rocks: Exactly. It sounds like Greg is actually starting to call that full node security, too. As you say, they seemingly completely moved...

Its hard to get definite statements from Greg, though.

 

[rocks]

@rocks: Do you remember where or when Greg expressed a different view what a full node is?

I really think he changed his opinion, too, but I'd like to see that change explicitly by looking at an old post.

Not off the top of my head. But I do remember him stating that SPV wallets are not secure because they do not perform all validations themselves. Segregated Witness also does not perform full validation.

It seems with segregated witness that you have the same reliance problem. Here a node can verifythat a previous transaction provided was connected to a full block in a side block, but the node has to trust that the side block attached to the full block is valid. The node can not verify this itself unless it downloads every side block in existence and performs a full historical validation.

If we are going to go there, we might as well just implement a version of UTXO commits which allow nodes to quickly startup and efficiently store history. Here nodes also have to trust that the UTXO commit attached to a full node in the past was valid, this is similar to segregated witness nodes having to trust that a side block attached to a full node in the past was valid.

They seem to have similar trust models to me.

 

[sickpig]

@Melbustus I agree and think that these companies really ought to invest in mining as a strategic move to help ensure their vision happens. And its not like its even a losing proposition -- they could band together and situate a co-mining space near a hydro dam in Canada or northern USA.

WRT BU, we could put redundant relay nodes just outside of the GFC and work with Chinese miners to solve whatever connectivity problems they are having, even if it means communicating blocks via skype or something.

re solving relay issues from/to GFWC: jonhatan toomin (xt dev) in his talk at scalingbitcooin honkong just proposed something along this line to solve this problems: stratum servers could stay in China, block creation and publishing should be done where internet is fast. basically the coinbase tx will be created in china and everything wrt of txs done outside.

https://youtu.be/ivgxcEOyWNs?t=165m

edit: fix link
edit2: just to say that I found his talk very insightful. he even mentioned the perf bug @theZerg referred t, along with two othoers that could lead to a long execution time for fastpath code like getblocktemplate.

 

[awemany]

Not off the top of my head. But I do remember him stating that SPV wallets are not secure because they do not perform all validations themselves. Segregated Witness also does not perform full validation.

A while back, I have seen Greg arguing with someone on IRC that Mike never implemented an SPV client because SPV doesn't exist yet (according to Greg's twisted thinking). If there's interest, I can try to find it in my logs.

They seem to have similar trust models to me.

Indeed. And I think that trust model is fine for >95% of full(?) nodes.

 

[rocks]

@rocks - so frustrating. I feel pretty darn good about almost everything happening in the bitcoin space right now, *except* the disaster that is this whole blocksize nonsense. Ask me 4 years ago whether I thought raising the blocksize would be any sort of controversy, and I would've thought the question itself was just nuts.

And this is why I believe Satoshi did not fix it before leaving, it was simply too absurd for him (or anyone) to think raising the limit would be a problem. However since the cap is the only internal limitation to Bitcoin, the cap is the only effective vector to attack it, it was an oversight that might cost the project dearly.
[doublepost=1449524901][/doublepost]

Given the behavior of the mining community as shown at the conference, I'm beginning to think even more that we need the mining-pool component of Bitcoin Unlimited:

Article 4: The Bitcoin Unlimited Mining Pool
Increasingly, users who have a strong vested interest in the success of Bitcoin control proportionally little hash power. The Bitcoin Unlimited Mining Pool seeks to provide companies and users a transparently run, not-for-profit, high payout, mining pool which explicitly supports global bitcoin adoption through Bitcoin Unlimited block creation.

If Coinbase and others become donators, it could work. Brian Armstrong's pre-conference comments are encouraging.

Given how short sighted some in the mining community seem to be proving to be, the most effective method to influence miners might be to implement scaling techniques in other clients.

If XT or BU or any other client started to offer functionality that lowers miners' orphan rates (IBLT, etc) and that functionality directly helps to improve revenue, I think you would see miner adoption regardless of the politics. This would prove a real advantage over the blockstream client since none of those developers are working on improving the client anymore and instead focusing on there own off chain products.

 

[cypherdoc]

i just want to reiterate that the big advantage of 101 over 100 is it's predictability. economic actors can know in advance what block sizes will be for years and plan their budgets/investments accordingly. they like certainty. 100 is anything but. you have no idea what miners will vote for from quarter to quarter (maybe even blocksize contraction) so any planning for merchants regarding growth, which all of them need, goes out the door.

 

[sickpig]

@rocks in your opinion what's the most effective way to remove this internal liability?

edit: scratch that I've just read your last post, I.e. develop scaling mechanisms in alternative clients to guide miners adoptions.

 

[cypherdoc]

 

[albin]

It seems like there's a significant amount of delusion in the micromanaged subreddit that segwit / current blocksize / 4 mb witness is somehow the "consensus" that came out of Hong Kong.

 

[sickpig]

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

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

TL;DR: I propose we work immediately towards the segwit 4MB block
soft-fork which increases capacity and scalability, and recent speedups
and incoming relay improvements make segwit a reasonable risk. BIP9
and segwit will also make further improvements easier and faster to
deploy. We’ll continue to set the stage for non-bandwidth-increase-based
scaling, while building additional tools that would make bandwidth
increases safer long term. Further work will prepare Bitcoin for further
increases, which will become possible when justified, while also providing
the groundwork to make them justifiable.

 

[Mengerian]

Complementary concepts.

Committed UTXO sets without fraud proofs are dangerous, because you have to blindly trust the source of the committed set.

If you add in a mechanism via which a fraudulent UTXO set can be conclusively proven incorrect, the risk of relying on committed UTXO sets is vastly diminished.

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.

I guess the difference with a fraud proof, is that a non-full-node could check the validity of the fraud proof itself. Ie, if the fraud proof information for the transaction says "this transaction's inputs come from a particular output in a particular transaction in a particular block", then it is possible to show the fraud proof information is non-valid without needing access to the full blockchain.