Bitcoin Forum
December 18, 2017, 06:13:59 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   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 ... 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 [1336] 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2022644 times)
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 17, 2015, 06:01:42 PM
 #26701

I sold some btc this morning on localbitcoins and then went and bought 3 ounces of gold.
Did I make the right choice?
Never go full retarded - I did something similar when bitcoin as about $10 and gold $2000. I'm hanging in here to say I told you so to cypher.

I have patients (and this new feeling called regret)

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
1513577639
Hero Member
*
Offline Offline

Posts: 1513577639

View Profile Personal Message (Offline)

Ignore
1513577639
Reply with quote  #2

1513577639
Report to moderator
1513577639
Hero Member
*
Offline Offline

Posts: 1513577639

View Profile Personal Message (Offline)

Ignore
1513577639
Reply with quote  #2

1513577639
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 06:05:08 PM
 #26702

big move in mkts.

must have been an FOMC anncmt...

Information received since the Federal Open Market Committee met in April suggests that economic activity has been expanding moderately after having changed little during the first quarter. The pace of job gains picked up while the unemployment rate remained steady. On balance, a range of labor market indicators suggests that underutilization of labor resources diminished somewhat. Growth in household spending has been moderate and the housing sector has shown some improvement; however, business fixed investment and net exports stayed soft. Inflation continued to run below the Committee's longer-run objective, partly reflecting earlier declines in energy prices and decreasing prices of non-energy imports; energy prices appear to have stabilized. Market-based measures of inflation compensation remain low; survey-based measures of longer-term inflation expectations have remained stable.

Consistent with its statutory mandate, the Committee seeks to foster maximum employment and price stability. The Committee expects that, with appropriate policy accommodation, economic activity will expand at a moderate pace, with labor market indicators continuing to move toward levels the Committee judges consistent with its dual mandate. The Committee continues to see the risks to the outlook for economic activity and the labor market as nearly balanced. Inflation is anticipated to remain near its recent low level in the near term, but the Committee expects inflation to rise gradually toward 2 percent over the medium term as the labor market improves further and the transitory effects of earlier declines in energy and import prices dissipate. The Committee continues to monitor inflation developments closely.

To support continued progress toward maximum employment and price stability, the Committee today reaffirmed its view that the current 0 to 1/4 percent target range for the federal funds rate remains appropriate. In determining how long to maintain this target range, the Committee will assess progress--both realized and expected--toward its objectives of maximum employment and 2 percent inflation. This assessment will take into account a wide range of information, including measures of labor market conditions, indicators of inflation pressures and inflation expectations, and readings on financial and international developments. The Committee anticipates that it will be appropriate to raise the target range for the federal funds rate when it has seen further improvement in the labor market and is reasonably confident that inflation will move back to its 2 percent objective over the medium term.

The Committee is maintaining its existing policy of reinvesting principal payments from its holdings of agency debt and agency mortgage-backed securities in agency mortgage-backed securities and of rolling over maturing Treasury securities at auction. This policy, by keeping the Committee's holdings of longer-term securities at sizable levels, should help maintain accommodative financial conditions.

When the Committee decides to begin to remove policy accommodation, it will take a balanced approach consistent with its longer-run goals of maximum employment and inflation of 2 percent. The Committee currently anticipates that, even after employment and inflation are near mandate-consistent levels, economic conditions may, for some time, warrant keeping the target federal funds rate below levels the Committee views as normal in the longer run.

Voting for the FOMC monetary policy action were: Janet L. Yellen, Chair; William C. Dudley, Vice Chairman; Lael Brainard; Charles L. Evans; Stanley Fischer; Jeffrey M. Lacker; Dennis P. Lockhart; Jerome H. Powell; Daniel K. Tarullo; and John C. Williams.
Read more at http://www.calculatedriskblog.com/#HDdC6iT89HzpgKlA.99
molecular
Donator
Legendary
*
Offline Offline

Activity: 2436



View Profile
June 17, 2015, 06:30:45 PM
 #26703

I sold some btc this morning on localbitcoins and then went and bought 3 ounces of gold.
Did I make the right choice?
Never go full retarded - I did something similar when bitcoin as about $10 and gold $2000. I'm hanging in here to say I told you so to cypher.

I did something similar, too (when bitcoin reached silver partity) and I was planning to do it again with gold parity (but it wasn't quite reached).

Now I'm not so sure any more if I will swap BTC <-> gold when parity is reached.

To answer freakying99: there are no wrong choices, just choices. You never know what it's good for or how the alternative would've played out. Sure, you can always isolate things and say stuff like: "I should've sold at $1160 and rebought at $160". But everything's connected and who knows, maybe you would've been run over buy a bus or crashed your Ferrari on cocaine had you done that.

The important thing is that you make the choice (not someone else) and that you actually make it and not let time make a choice for you (inaction). And of course also that you use the information, the resources (includes opinions of others) and tools available to you. That way one can learn from mistakes, improve tools and resources and one doesn't get into the habit of blaming others.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 06:42:36 PM
 #26704

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)
_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 17, 2015, 06:51:44 PM
 #26705

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 06:52:48 PM
 #26706

volume is moving in:

https://twitter.com/barrysilbert/status/611242936370626560
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 06:53:45 PM
 #26707

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.
_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 17, 2015, 06:56:09 PM
 #26708

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.

Sure. But doesn't the 2 week grace period after 75% imply enough time?

https://www.youtube.com/watch?v=nuHfVn_cfHU
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 06:58:37 PM
 #26709

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.

Sure. But doesn't the 75% imply enough time?

https://www.youtube.com/watch?v=nuHfVn_cfHU

huh?  he's going to release the code probably within the week.  it'll probably take 6 mo for the miners to implement to get to the 75% level as indicated by the versioning of the blocks they will be releasing by that time.
_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 17, 2015, 07:01:08 PM
 #26710

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.

Sure. But doesn't the 75% imply enough time?

https://www.youtube.com/watch?v=nuHfVn_cfHU

huh?  he's going to release the code probably within the week.  it'll probably take 6 mo for the miners to implement to get to the 75% level as indicated by the versioning of the blocks they will be releasing by that time.

But this code will include a rule that even if we wanted to or are able to get it all deployed faster, it still cannot be activated. I mean how difficult is installing new software anyway? Took me all of 5 minutes to upgrade to XT. I understand it may be more difficult for a larger organization... but 6 months? Really? If we have a huge rally and the network starts you choke you better believe these people will be capable of rolling out the upgrade much more quickly.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 07:02:03 PM
 #26711

here's another big hint that Gavin has the support:

"Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)"

Blockstream and gmax take heed.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 07:07:05 PM
 #26712

this should work. nice and simple and pleases Chinese miners w/o giving miners in general any votes:

https://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xe9o



If 75% of hashing power is producing up-version blocks

AND after some brave miner decides to actually produce a >1MB block.

8MB max block size (chinese miners were unhappy with 20 for not-entirely-clear reasons)
Earliest fork date 11 Jan 2016 (miners and others want sooner rather than later)
Activation when 750 of last 1,000 blocks are up-version (version 0x20000004 to be compatible with sipa's new versioning bits scheme)
2 week 'grace period' after 75% threshold reached before first >1MB block allowed to be mined
8MB cap doubles every two years (so 16MB in 2018, etc: unless there is a soft fork before then because 16MB is too much)

Not sure why limiting the date is necessary. I feel like we should be able to pull this off sooner, especially if we are backed into a corner by some kind of big rally.

i agree but miners need time to switch over and indicate so with the versioning.

Sure. But doesn't the 75% imply enough time?

https://www.youtube.com/watch?v=nuHfVn_cfHU

huh?  he's going to release the code probably within the week.  it'll probably take 6 mo for the miners to implement to get to the 75% level as indicated by the versioning of the blocks they will be releasing by that time.

But this code will include a rule that even if we wanted to or are able to get it all deployed faster, it still cannot be activated. I mean how difficult is installing new software anyway? Took me all of 5 minutes to upgrade to XT. I understand it may be more difficult for a larger organization... but 6 months? Really? If we have a huge rally and the network starts you choke you better believe these people will be capable of rolling out the upgrade much more quickly.

we're talking about a worldwide "organization" not all of whom are paying attention like you.  believe it or not.  the most striking example is all the miners who keep hitting 750KB.  i totally hear you that if >75% is achieved sooner than Jan, ideally we could flip the switch.  first off, that might not happen and you have to accept the fact that it just takes some miners more time than others for whatever reason.  second, miners aren't the only ones that have to change their software.  exchanges and merchants will have to update as well.  so there are alot of ppl involved and they need a set, reliable deadline as opposed to a fuzzy, maybe tomorrow might happen, type switch.
Erdogan
Hero Member
*****
Offline Offline

Activity: 840


View Profile
June 17, 2015, 07:13:39 PM
 #26713

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 07:20:54 PM
 #26714

http://imgur.com/uCd0Vx1
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 17, 2015, 07:21:57 PM
 #26715

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


I think its worth expanding the obvious power the miners have, its not just: "dont make larger blocks, but build on larger blocks from others" as written but "dont make larger blocks, but build on larger blocks from others only if they are part of the longest chain as supported by the majority of nodes."

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 17, 2015, 07:28:08 PM
 #26716

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


giving miners a vote in terms of block size is paying them too much deference in terms of the market dynamics in Bitcoin. i've always said that no contingent is more powerful than another in Bitcoin.  everyone is important and needed and has power to a degree or so; users, merchants, miners, node operators.  which is why i always give that bucket analogy when i think in terms of which of those subspaces i would want to invest in.  some will always be more developed (filled) or over invested in than the others while the whole space can still be in a bull mkt w/o anyone of them being "in charge".  
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 07:28:18 PM
 #26717

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

The results of the voting adjustment are a part of the protocol. Miners could no more ignore the adjusted blocksize limit than they could ignore the difficulty adjustment. They are binding.

Yes, some miners could choose to issue smaller blocks, but: 1) that is not ignoring the limit, it is a max limit not a requirement 2) with IBLT issuing smaller blocks exposes the miner to a higher rate of orphaned blocks because they increase the probability of having to transmit the entire block and not just the IBLT diff.
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
June 17, 2015, 07:34:02 PM
 #26718

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.

The miners could agree on a soft limit .... The soft limit could be communicated in a side channel outside bitcoin. Pools could communicate preferences in a side channel outside of their miners visibility or knowledge.

Let's remember these are pools, not miners.

The advantage of the voting process, is it makes every pools' stated preferences fully public in the blockchain. This allows miners to join pools that reflect their views and in the process makes the behavior of centralized pools accurately reflect the voting preferences of individual miners. I think as much as possible should be done in this manner, rather than in non-public side channels that gives lots of power to pools at the expense of decentralized miners.
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
June 17, 2015, 07:35:16 PM
 #26719

For the expansionist here, what do you think?  Should we compromise at 8MB?  Personally I am ok with that, esp if an automatic periodic increase is baked in.

http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size

EDIT: page 1337!  gotta have something substantive on it :-)

i'm ok with it with the automatic expansion.  but i'm alittle concerned with the miner voting for expansion.  why just them and is voting really the way we want to go?

Yes the BIP 100 voting scheme seems a bit under developed at this point.  The problem is that POW mining is the only way to prove independent existence, this is the basis of distributed consensus -- you can easily create a bunch of fake AWS "full" nodes for example -- 1000 nodes just forward requests to a single full node.  And if you could solve the voting problem without using mining, you could use that solution to remove mining from consensus (i.e. from bitcoin).

One way to prove unique nodes is to require that every node use asymmetric functions to encode the data to be stored, with uniquifying "salt".  This is essentially hashing but backwards.

For example, every node chooses a unique 256bit identifier (salt).  Then for every 8 or 16 bits of blockchain data Di, it finds and stores Xi such that Hash(Xi + identifier + i) = Di (where "+" means "append").

This search happens continually as the blockchain is being created.

Now a client can validate the uniqueness of storage by another node by requesting random chunks of data from the node.  The node responds with its ID and Xi0-i1.  The client can then quickly validate this by running the hash function and comparing the result to its own blockchain.

A "full" node (one that is calculating this data and storing it as the blockchain is created) will be able to respond quickly where one that is not doing so will have to calculate the reverse hash function (essentially a random search like mining but easier because only 8 or 16 bits) on the fly.

Once you have this "proof of storage" you might be able to turn it into allowing node voting...

So someone rents hard disk space on Amazon AWS during the voting period and becomes many unique entities.

You were correct that there is no way to prove one computer, one vote. PoW doesn't work by voting. It works by random chance. The only problem PoW solves is consensus on ordering.

Ah I grow weary in this thread.

U repeated exactly what I said.  And then didn't read my partial soln

Ahem, try reading again. You proposed proof-of-storage as a potential means to voting.

Prior proof-of-storage (https://bitcointalk.org/index.php?topic=310323.0) "wastes" storage like POW "wastes" CPU.  It proves that storage exists.  The proposal above proves that a unique copy of the blockchain is stored somewhere.  This is much more valuable than proof that storage exists so it is perhaps better named proof-of-full-node.  The reason you can't just rent hard disk space on AWS to fake this out is because you need to calculate the inverse hash for every byte of the blockchain, salted by your node id.  The designer can choose how hard this is so it could take (say) a normal computer 6 months to do the entire 5 year blockchain. So the proof of storage is backed by POW which makes it hard to calculate the values on-the-fly.  You could rent a bunch of AWS storage AND separately rent a supercomputer to individually calculate the hash-1 blockchain data, storing the result into AWS.  But if you do that, you actually HAVE N individual copies of the blockchain so would receive N votes.

Because I am basically arguing with myself here I will now criticize the approach's limitations.  It is possible that modifications to this approach could solve them:

1. "Difficulty" is chosen in advance, not dynamically.  This is problematic as processing power increases.
2. It takes a long time for a new node to become a provably "full" node.  Of course, nodes could become non-provably "full" nodes just by downloading the blockchain as is done today, and nodes could advertise themselves as partly provable, receiving a partial vote...
3. The provable blockchain could be constructed by many CPUs running in parallel... is this a problem?  If so we could force serialization by salting Xi with Xi-1.
4. The system functions as a real-time interactive proof.  There is no way store a historical proof that a node was full on date D.  Bitcoin-style POW+blockchain does store historical proof of computation power.

Okay I got it now (I was very fatigued before prior reply and you didn't give any high level description). It is a historic proof that an entity was winning PoW blocks. So basically you have to set a threshold as to what level of cumulative PoW difficulty constitutes a vote, thus a centralized party decides what class of voter is included.

This is representative governance, because the users can't vote and those with more PoW can vote more times (creating numerous sockpuppets). Representative governance is even more prone to capture by the Logic of Collective Action.

Bitcoin has no choice but to head these sort of perilous directions because the fundamental design is flawed.

If Bitcoin's design would scale without intervention, we wouldn't be seeing the need to do this.

I don't think you get it.  It is a proof that an entity is storing a UNIQUE copy of the blockchain.  What little prior PoS work I've read seems to prove that storage exists, or that a file is being stored.  Unfortunately they do not address the idea that you want to store a file in 2 places A & B and ensure that A & B are not in collusion and so the file is only stored one of the 2 locations.

Honestly I'm less interested in the BIP 100 voting scheme (and the usefulness of voting in general as a governance mechanism) as I am in healing the rift between miners and full nodes.  Clearly no-one is going to implement the above proposal for bitcoin just so full nodes can vote on BIP 100! :-)

If you are not talking about its utility for voting, then how can you say I don't get it, when I was responding to its utility for voting, since that is the context in which you sold your idea initially.

I didn't mean to insult you when I said you didn't get it.  I just read this: "It is a historic proof that an entity was winning PoW blocks. So basically you have to set a threshold as to what level of cumulative PoW difficulty constitutes a vote, thus a centralized party decides what class of voter is included." This is interesting but orthogonal to my "proof-of-full-node" idea.  WRT voting I am responding to Cypherdoc's original question "why can't full nodes also vote?" without addressing the question of whether it is a good or bad idea to resolve this question by vote.  

Certainly the best resolution is to simply not need to ask the question in the first place (by creating a system with sub-linear per node O(t) where t=txns in the network).
Erdogan
Hero Member
*****
Offline Offline

Activity: 840


View Profile
June 17, 2015, 07:36:52 PM
 #26720

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

I originally thought of Garzik's voting proposal that it was brilliant. But now I think adding this would be unnecessarily complex.

If there is a need to hold back blocsize, it should be a hard increase based on previous blocks in the style of difficulty change. We can then continue the situation where the only link to the real world is the timestamps.

The miners could agree on a soft limit (dont make larger blocks, but build on larger blocks from others). The soft limit could be communicated in a side channel outside bitcoin. Call it a miner cartel, but before you dismiss it, know that a cartel is a very weak economic construct, with possible attacks from inside and outside. Don't forget that each miner is free to choose which block to base his mining on, he chooses that based on self interest.

So dynamically incremented hard limit for security, market based soft limit.


I think its worth expanding the obvious power the miners have, its not just: "dont make larger blocks, but build on larger blocks from others" as written but "dont make larger blocks, but build on larger blocks from others only if they are part of the longest chain as supported by the majority of nodes."

Yes, but it is at the same time in their interest. If they for some reason agree to have a limit, they could also agree to build on only blocks within the soft limit. I see no economical reason that this should lead to a fork, no more than in the current situation where two chains of near equal length (as defined in the protocol) appears.

EDIT: By the way, this IS the current reality, whatever the reference implementation says. You can complain that your orphan from last year should have been built on because it was slightly better. What is longest now matters, and there is randomness involved in the selection.


Pages: « 1 ... 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 [1336] 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 ... 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!