Gold collapsing. Bitcoin UP.

[Erdogan]

new poll

Cool, but this time there is no "unlimited" option.

well, certainly i'm no expert in polling; i just feed 'em like i see 'em.

if you have any suggestions, lemme know.

edit:  given Gavin's proposal, it looks like the "unlimited" option is off the table for now, so in this sense, this latest poll is heading in the right direction.

Yes, let's get 20 MB going, then new poll

[1714006764]

1714006764

[1714006764]

1714006764

[1714006764]

1714006764

[1714006764]

1714006764

[Natalia_AnatolioPAMM]

Multiply that by 100M and pretty soon you're making real money.

Here's an example of a money protocol that allowed for "only" 3%/year worth of double spending:

never realized it's that bad unless saw the graphs like this one

[rocks]

Multiply that by 100M and pretty soon you're making real money.

Here's an example of a money protocol that allowed for "only" 3%/year worth of double spending:

never realized it's that bad unless saw the graphs like this one

Even this chart is misleading, since it is linear it does not show how the dollar continued drop over the past 30 years. Instead it looks relatively flat.

The log chart shows how this process is continuing. Even though the dollar has already lost 98% purchasing power, dropping to 99% is really another 50% lose, not the 1% drop shown on this chart.

[sickpig]

With UTXO merkle tree the whole thing does not need to be in phone RAM.  Or even on the phone.  phone clients could validate and fwd txns iff they are connected to wifi.  The only parts of the UTXO merkle tree that needs to be processed is the logn route from each UTXO involved in a txn to the tree root.  So very doable on today's mid range smart phone esp with a good sized uSD expansion.

On that matter I've just found out an etotheipi's (armory core dev) proposal "Ultimate blockchain compression w/ trust-free lite nodes" that he made in June 2012. This is the summary:

Use a special tree data structure to organize all unspent-TxOuts on the network, and use the root of this tree to communicate its "signature" between nodes.  The leaves of this tree actually correspond to addresses/scripts, and the data at the leaf is actually a root of the unspent-TxOut list for that address/script.  To maintain security of the tree signatures, it will be included in the header of an alternate blockchain, which will be secured by merged mining.  

This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders.  Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB).  

More recently TierNolan with his "Locally verifiable unspent transaction output commitments" is "sketching" his idea of a potential implementation. 

A proposal to help SPV nodes verify blocks is to commit the root of an (unbalanced) Merkle tree containing all unspent (and spendable) transaction outputs.

It is possible to create proofs of validity for each modification of the set.  The proof would prove that inserting an entry into a tree with a root of X will give a new tree with a root of Y.  There would also be proofs for removing entries.

it seems that the idea of an "UTXO" light node to add to the the list of the already implemented nodes (full, spv, pruned) is gaining momentum.

[HeliKopterBen]

Bitcoin, while its issuance is capped at 21M, the software can be duplicated thousands of times.

The ability to clone/fork the software is a feature, not a bug.  Take the Euro for example, which is under a round of QE right now.  Imagine if Euro savers could easily clone the entire Euro monetary system, take out the QE, and put the QE_less system into production to compete.  Which fork would win?  I imagine sound money would win.

The only thing that cannot be duplicated is processing power.  Processing power is in finite supply, so whichever fork garners the most processing power wins.  The ability to clone the software keeps the system honest.

[tabnloz]

Grabbed this off ZH

Australia to Introduce Bank Deposits tax in upcoming budget.

http://www.zerohedge.com/news/2015-05-04/war-cash-australia-leads-new-age-economic-totalitarianism

From a google search

http://www.theaustralian.com.au/business/financial-services/deposit-tax-banks-oppose-budget-tax-plan/story-fn91wd6x-1227284293520

ZH sees it as a trial balloon with US watching the reaction carefully.

[cypherdoc]

interesting logarithmic Monte Carlo simulation of tx confirmation delays related to progressive filling of current 1MB block size.  bottom line is we need an increase in the block size otherwise confirmation delays will exponentially increase as the fill reaches the max.  note in the conclusion who would benefit from NOT increasing the block size; "SC's".  no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

http://hashingit.com/analysis/34-bitcoin-traffic-bulletin

[sickpig]

interesting logarithmic Monte Carlo simulation of tx confirmation delays related to progressive filling of current 1MB block size.  bottom line is we need an increase in the block size otherwise confirmation delays will exponentially increase as the fill reaches the max.  note in the conclusion who would benefit from NOT increasing the block size; "SC's".  no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

http://hashingit.com/analysis/34-bitcoin-traffic-bulletin

Nice graph! Thanks for sharing. So with a 100% filled block you have a 0.1 probability of having your tx confirmed after 1000/sec. This is nasty.

As I already said  multiple times I'm a big supporter of Justus proposal to eliminate false block size scarcity and introducing economic incentive in the p2p nodes network.

Nonetheless I think that a part of txs will occur out of bitcoin main chain, through payment hub, lightning network, you name it. In fact the very solution Justus proposed to implement a price discovery mechanism in Bitcoin p2p network is based on micropayment channels.

[solex]

no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

I just scanned their recent reddit posts about the proposal and to be fair their position leans more to "open mind but cautious" than "outright rejection". This is good as obviously they contribute a lot to core dev, and hopefully that will continue.

Luke mentions increasing the block size in an emergency:

Those are all scalability issues that will not be fixed by making the blocks larger. We should fix them, not put them off. Maybe we can increase the max block size just in case of emergency, but we most definitely should not increase the actual block sizes simply to ignore real problems.

http://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqye7m6

Well, frankly, passing the point of average blocks being 40% full, where confirmation times start to decay exponentially (as per the hashingit graph) is an emergency, something rightly addressed now because everyone who runs a full node needs to upgrade.

[lunarboy]

no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

I just scanned their recent reddit posts about the proposal and to be fair their position leans more to "open mind but cautious" than "outright rejection". This is good as obviously they contribute a lot to core dev, and hopefully that will continue.

Luke mentions increasing the block size in an emergency:

Those are all scalability issues that will not be fixed by making the blocks larger. We should fix them, not put them off. Maybe we can increase the max block size just in case of emergency, but we most definitely should not increase the actual block sizes simply to ignore real problems.

http://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqye7m6

Well, frankly, passing the point of average blocks being 40% full, where confirmation times start to decay exponentially (as per the hashingit graph) is an emergency, something rightly addressed now because everyone who runs a full node needs to upgrade.

Actually Nullc / Gmax is positive about an increased blocksize WRT sidechains see here:

Are 20mb blocks good or bad for Sidechains?
https://www.reddit.com/r/Bitcoin/comments/34riua/hard_fork_allow_20mb_blocks_after_1_march_2016/cqxhs1o

[cypherdoc]

Don't forget to vote the poll.

[NewLiberty]

interesting logarithmic Monte Carlo simulation of tx confirmation delays related to progressive filling of current 1MB block size.  bottom line is we need an increase in the block size otherwise confirmation delays will exponentially increase as the fill reaches the max.  note in the conclusion who would benefit from NOT increasing the block size; "SC's".  no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

http://hashingit.com/analysis/34-bitcoin-traffic-bulletin

Nice graph! Thanks for sharing. So with a 100% filled block you have a 0.1 probability of having your tx confirmed after 1000/sec. This is nasty.

As I already said  multiple times I'm a big supporter of Justus proposal to eliminate false block size scarcity and introducing economic incentive in the p2p nodes network.

Nonetheless I think that a part of txs will occur out of bitcoin main chain, through payment hub, lightning network, you name it. In fact the very solution Justus proposed to implement a price discovery mechanism in Bitcoin p2p network is based on micropayment channels.

Justus laid out a structure.  There are a great number of missing pieces between what exists today in the consensus code and that structure.  There are also undefined and missing elements in the ecosystem.  I like the structure too, but we aren't anywhere close to it yet and it won't be soon.

The current proposal is Gavin's most reasonable one yet.  He dropped the assumptions about the future, took out most of the guesswork, and is implementing the method satoshi offered when the antispam 1mb limit was created in 0.3 or so.

More would be great, and future proof would be even better, no limit best....  but... remember, we are still in beta.  The pieces to do any of that are not written, tested, integrated, accepted and secured.

Bitcoin is still a baby.  So as eager as we all are to get there, we will get there by baby steps or end up not getting at all.  There are a great many looking for us to fail (check the short interest lately?) we help that failure by over-extending what can be done.

20mb gives us some room to build more of the missing pieces.  Its enough for now.

[sickpig]

Justus laid out a structure.  There are a great number of missing pieces between what exists today in the consensus code and that structure.  There are also undefined and missing elements in the ecosystem.  I like the structure too, but we aren't anywhere close to it yet and it won't be soon.

The current proposal is Gavin's most reasonable one yet.  He dropped the assumptions about the future, took out most of the guesswork, and is implementing the method satoshi offered when the antispam 1mb limit was created in 0.3 or so.

More would be great, and future proof would be even better, no limit best....  but... remember, we are still in beta.  The pieces to do any of that are not written, tested, integrated, accepted and secured.

Bitcoin is still a baby.  So as eager as we all are to get there, we will get there by baby steps or end up not getting at all.  There are a great many looking for us to fail (check the short interest lately?) we help that failure by over-extending what can be done.

20mb gives us some room to build more of the missing pieces.  Its enough for now.

I can't have said it better, really.

I'm aware that bitcoin development is quite peculiar and there's little to no margin for errors.
And this is the reason why I think it's important to start spreading Justus's idea in advance,
because as you rightly said we need a lot of time to get there. So the sooner we start the better.

That said I wonder what are the link you see between the price discovering mechanism sketched by Justus
and the Bitcoin consensus code? I see them as quite unrelated pieces of the system, but maybe I am missing
something obvious.

[justusranvier]

Justus laid out a structure.  There are a great number of missing pieces between what exists today in the consensus code and that structure.  There are also undefined and missing elements in the ecosystem.  I like the structure too, but we aren't anywhere close to it yet and it won't be soon.

The current proposal is Gavin's most reasonable one yet.  He dropped the assumptions about the future, took out most of the guesswork, and is implementing the method satoshi offered when the antispam 1mb limit was created in 0.3 or so.

More would be great, and future proof would be even better, no limit best....  but... remember, we are still in beta.  The pieces to do any of that are not written, tested, integrated, accepted and secured.

Bitcoin is still a baby.  So as eager as we all are to get there, we will get there by baby steps or end up not getting at all.  There are a great many looking for us to fail (check the short interest lately?) we help that failure by over-extending what can be done.

20mb gives us some room to build more of the missing pieces.  Its enough for now.

I can't have said it better, really.

I'm aware that bitcoin development is quite peculiar and there's little to no margin for errors.
And this is the reason why I think it's important to start spreading Justus's idea in advance,
because as you rightly said we need a lot of time to get there. So the sooner we start the better.

That said I wonder what are the link you see between the price discovering mechanism sketched by Justus
and the Bitcoin consensus code? I see them as quite unrelated pieces of the system, but maybe I am missing
something obvious.

I'll devote more time to explaining how the price discovery mechanism could be rolled out as an incremental upgrade after I finish with this:

https://github.com/justusranvier/wallet-ratings/tree/2015-1/2015-1

[cypherdoc]

weaker, weaker, and weaker:

[thezerg]

I'm for Gavin's 20MB increase.  But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works.  The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).

So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit).  In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve).  So supply (space in a block) can actually increase as demand increases.

You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit.  The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high.  In that case, we are no worse than today's proposal.

[Zangelbert Bingledack]

I don't think we need the same security model for buying loaves of bread that we use for buying homes,.

Of course you do, once you understand what the security problem is.

The entire job of the Bitcoin network is to make sure that the number of currency units is exactly correct at all times.

There's probably a hundred million loaves of bread sold every day, which represents a hundred million opportunities to improperly expand the currency supply.

I don't know if there's much hope of avoiding every possible improper expansion. I'm undecided on whether it really matters to have everything be on blockchain (or otherwise completely un-finagle-able like through OT).

[Zangelbert Bingledack]

I'm for Gavin's 20MB increase.  But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works.  The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).

So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit).  In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve).  So supply (space in a block) can actually increase as demand increases.

You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit.  The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high.  In that case, we are no worse than today's proposal.

I assume a fee market will be ready by then, or by whenever block scarcity becomes an issue.

[cypherdoc]

great article by Mike Hearn:

https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

[Zangelbert Bingledack]

Blocksize debate blowing up all over /r/Bitcoin right now, though it's mostly pro-increase.