Bitcoin Forum
September 21, 2017, 07:27:47 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 [1172] 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1978027 times)
sickpig
Legendary
*
Offline Offline

Activity: 1204


View Profile
May 04, 2015, 10:16:33 PM
 #23421

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.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506022067
Hero Member
*
Offline Offline

Posts: 1506022067

View Profile Personal Message (Offline)

Ignore
1506022067
Reply with quote  #2

1506022067
Report to moderator
1506022067
Hero Member
*
Offline Offline

Posts: 1506022067

View Profile Personal Message (Offline)

Ignore
1506022067
Reply with quote  #2

1506022067
Report to moderator
HeliKopterBen
Hero Member
*****
Offline Offline

Activity: 622



View Profile
May 04, 2015, 10:19:11 PM
 #23422

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.

Counterfeit:  made in imitation of something else with intent to deceive:  merriam-webster
tabnloz
Legendary
*
Offline Offline

Activity: 962


View Profile
May 05, 2015, 01:09:55 AM
 #23423

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 02:23:55 AM
 #23424

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
Legendary
*
Offline Offline

Activity: 1204


View Profile
May 05, 2015, 06:16:53 AM
 #23425

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.


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 05, 2015, 06:41:34 AM
 #23426

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:
Quote
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
Hero Member
*****
Offline Offline

Activity: 544



View Profile
May 05, 2015, 07:03:16 AM
 #23427

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:
Quote
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
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 10:26:30 AM
 #23428

Don't forget to vote the poll.
NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
May 05, 2015, 12:02:15 PM
 #23429

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.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
sickpig
Legendary
*
Offline Offline

Activity: 1204


View Profile
May 05, 2015, 03:11:58 PM
 #23430


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.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
May 05, 2015, 03:53:23 PM
 #23431


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
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 05:12:35 PM
 #23432

weaker, weaker, and weaker:

thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 05, 2015, 07:48:29 PM
 #23433

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
Legendary
*
Offline Offline

Activity: 1036


View Profile
May 05, 2015, 07:52:18 PM
 #23434

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
Legendary
*
Offline Offline

Activity: 1036


View Profile
May 05, 2015, 08:03:13 PM
 #23435

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 08:08:23 PM
 #23436

great article by Mike Hearn:

https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
May 05, 2015, 08:11:32 PM
 #23437

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

Activity: 1764



View Profile
May 05, 2015, 08:48:32 PM
 #23438

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

what strikes me most about /nullc and LukeJr objections are that they revolve around incorrect perceptions of what the Bitcoin market looks like today.  for instance, /nullc believes that mining is centralizing.  i don't; look at the pie charts from mempool:



the distribution of miners has improved (decentralized) markedly since the ghash event.  i've regularly documented that improvement over the years and believe we may have in fact witnessed the very last time any pool gets anywhere near 50%.  i've argued using game theory and it appears to have been prescient.

also, he believes that the decrease in full nodes "creates huge systemic risk and undermines Bitcoin's value proposition".  give me a break; the decrease in nodes yes might be due partly to node dropout but i think it is mainly due to the proliferation of SPV clients.  furthermore, i was initially a part of the Bitnodes Incentive Program and was one of it's first payment recipients, however, due to the fact they require re-registration every month, i've dropped out.  it's too much of a hassle and involves relatively complex code to re-register while the payout is trivial.  but i still run my nodes and as i've said before, i'm actually looking forward to learning how to prune so i can run a dozen more nodes or so.

and what does he mean by this? "This is especially concerning as we've seen the deployment of full nodes fade out and even large commercial operations become dependant on third party hosted node services."  what's he talking about and where's the evidence?

and then he points to Kaminsky as some kind of prophet?:  "it should be noted that this outcome was already predicted years ago (e.g. by Dan Kaminsky's comments that I was writing about above), but we've still slid into it."  what sticks in my mind is the lost bet btwn Garzik and Kaminsky when DK predicted Bitcoin's underlying Proof-of-Work hash function (Sha-2) would be replaced within 12 months:  https://storify.com/socrates1024/bitcoin-pow-bet-10btc-jgarzik-vs-dakami-may-2014.   There haven't been any more famous tech experts who have been more wrong about Bitcoin.  even DK admits it now.

and then he points to Todd and MPOE as worthy colleagues against increased block sizes:  "Rather, the only push you see against larger blocks come from strong advocates of personal autonomy and decenteralization, like Peter Todd; or the MPOE crowd".   aligning one's self with these 2 is even more dangerous than Kaminsky.

he's always been almost bearish on Bitcoin; for years.  he's always said mining is centralizing despite the facts.  he's been a fan of Ripple in the past here:  https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&diff=14273&oldid=14112

you'll notice in the link below he admits to going back and deleting his posts of support for Ripple in the past.  who does that?  own up to it, don't try to cover it up.

here's all his concerns highlighted in gory detail  Roll Eyes:

https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqycy4h
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 05, 2015, 09:36:15 PM
 #23439

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 like this proposal a lot.

High-priority non-fee transactions that consume older coins are suppose to be just that, free and gain priority access to a block. Today's situation is even if your transaction has enough priority to qualify for free processing, they often take hours to confirm since most minors do not pick high priority transactions without a fee. This completely defeats the purpose of having the priority system at all.

Reserving a front space in each block for high-priority non-fee transactions does two things:
1) It would ensure that high-priority transactions are processed in a timely fashion
2) It would encourage more competition from low-priority transactions and possibly increase the fees they need to offer to be processed quickly

This would shift transaction fees more towards for profit services that are built on top of bitcoin and away from individual wallet users. I would consider this to be a good thing.

Anyone on this thread have contact with any of the core developers? Have they considered it? If not how could zerg propose it (provide people here also think it makes sense...)
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
May 05, 2015, 09:39:35 PM
 #23440


Quote from: nullc on redit
You've repeatedly made this accusation regarding me specifically-

LOL, bribing up that history is his response to this comment, for pointing out sidechains stand to benefit from a small transaction size.  I was not picking on him or even challenging his position merely pointing out why there was a debate at all.  

I originally stopped reading after the word specifically. but if it's any consolation ripple has always been a centralized system, and I have taken a lot of flack for pointing out that's its Achilles' heel and not supporting it, why not take some heat on the other side for not recognizing that fact at the start.  

I think nullc relates to sidechains on a very personal level and is feeling very threatened at the moment, my comment was an observation not an accusation for the record.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
Pages: « 1 ... 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 [1172] 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 ... 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!