Gold collapsing. Bitcoin UP. - page 222.

rocks

legendary

Activity: 1153

Merit: 1000

Quote from: cypherdoc on June 17, 2015, 03:08:02 PM

Quote from: rocks on June 17, 2015, 02:38:34 PM

Quote from: cypherdoc on June 17, 2015, 02:28:08 PM

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".

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

i get what you are saying but it assumes 2 things:

1. voting is good
2. IBLT is ready

i worry that voting can be gamed. you could argue that versioning is a form of voting i guess but it is different in that it is a commitment that only has to be done once by a miner to indicate the preference to double the block size acc to Gavin's proposal. all that then needs to be done is to flip the switch after 75% of the mining network is demonstrating the upversioned blocks.

i have hopes for IBLT as well but that seems like that will take a while and certainly not in time for what we need now.

Voting can best be gamed when the process is hidden behind closed side channels between pools, developers or anything else. The advantage of putting voting into the blockchain is it makes the process transparent and visible to individual miners, which makes it much less exposed to gaming as individual miners can see this and respond.

The POW process is Bitcoin's voting process. Yes users, merchants, etc. should have influence, and they do, they can choose to run which ever client they want that follows whatever rules they want. But that is the external world interacting with Bitcoin and deciding how they want to interact with Bitcoin.

Bitcoin as a self-contained system has only one voting mechanism, POW blocks. If anyone wants to vote within Bitcoin's self contained world, stand-up a miner and point it to the pool that best follows your preferences. In many ways this is better than representative democracy, you are much more likely to find a pool you agree with than a US D or R candidate you agree with.

tvbcof

legendary

Activity: 4690

Merit: 1276

Quote from: TPTB_need_war on June 17, 2015, 03:31:44 AM

...
Btw, in my coin's design the miners can not be paid with transaction fees that originate from prior balances because this is a source of censorship of transactions (even if the inputs are blinded by a mix because one blacklisted input in the mix could cause censorship of the entire mix). My design is 100% censorship free (no heuristic arguments, rather 100% provable).

Shit I am giving away too much of my design. I better STFU.

You will end up buying my coin if I create it, because it will blow your fucking mind or I mean to say the design will make your jaw drop to the floor and you will say, "I must buy this".

If your design is half as good as what I've been working on, I just might do that

Seriously, if I might be so bold as to suggest that you throw your ideas out there, some of them might be picked up and even enhanced in ways you don't initially imagine. That has happened to me over the years. If you don't get credit or money for them, so what? Speaking only for myself these things are quite secondary. If you are consumed with fame and fortune and what-not it cannot help but detract from your ability to focus on other things. I suppose it could be argued that fame and fortune might spur one to work harder, but I'll bet that in most cases working harder is actually counter-productive to doing quality work in certain important ways.

Erdogan

legendary

Activity: 1512

Merit: 1005

Quote from: Adrian-x on June 17, 2015, 02:51:42 PM

Quote from: Erdogan on June 17, 2015, 02:36:52 PM

Quote from: Adrian-x on June 17, 2015, 02:21:57 PM

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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.

I cant see it leading to a fork ever, in effect I like the idea of carrells limiting block-size through a cooperative effort, provided they have no say on what nodes will accept, inevitably some one will break from it and mine bigger blocks for transaction fees, if it gives them a sense of control sure let them have it. considering most miners mine to the 750KB default I don't think anyone needs to optimize this much until the TX mem pool is a little bigger and block subsidy smaller.

You got it. In general, we should not be afraid of cartels, it is just a way to increase productivity. It is currently not much liked by the regulators, but it is in fact the regulators messing with the cartels that is the market distortion. And there is no regulator for mining.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: rocks on June 17, 2015, 02:38:34 PM

Quote from: cypherdoc on June 17, 2015, 02:28:08 PM

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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".

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

i get what you are saying but it assumes 2 things:

1. voting is good
2. IBLT is ready

i worry that voting can be gamed. i don't see any proposed methods for the voting to even take place yet alone how to agree to it. but "voting" via BIP100 requires the initial vote, by whatever agreed upon means (that in itself will be controversial), and then a second time via versioning of blocks (assuming the increase needs to reach a certain % before it gets turned on).
with Gavin's latest proposal, the "vote", only has to takes place once and via a means we already know works well; block versioning.

i have hopes for IBLT as well but that seems like that will take a while and certainly not in time for what we need now.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: Adrian-x on June 17, 2015, 02:56:39 PM

Quote from: techgeek on June 17, 2015, 02:48:30 PM

so is the 20 mb going to happen before the unavoidable clogged confirmation times, or are we already in the process of something now?

I rather see this now then later in my view.

No, clogging can happen anytime, Gavan's proposal was for March next year.

not sure how Gmax and co would just quickly fix this if the clogging happened tomorrow. maybe the Chinese could increase the dealt from 750KB to 1MB and we could limp along until next year.

it just seems irresponsible to me to not put this change in now while the idea is debated.

revised to January as earliest implementation.

Adrian-x

legendary

Activity: 1372

Merit: 1000

Quote from: techgeek on June 17, 2015, 02:48:30 PM

so is the 20 mb going to happen before the unavoidable clogged confirmation times, or are we already in the process of something now?

I rather see this now then later in my view.

No, clogging can happen anytime, Gavan's proposal was for March next year.

not sure how Gmax and co would just quickly fix this if the clogging happened tomorrow. maybe the Chinese could increase the dealt from 750KB to 1MB and we could limp along until next year.

it just seems irresponsible to me to not put this change in now while the idea is debated.

Adrian-x

legendary

Activity: 1372

Merit: 1000

Quote from: Erdogan on June 17, 2015, 02:36:52 PM

Quote from: Adrian-x on June 17, 2015, 02:21:57 PM

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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.

I cant see it leading to a fork ever, in effect I like the idea of carrells limiting block-size through a cooperative effort, provided they have no say on what nodes will accept, inevitably some one will break from it and mine bigger blocks for transaction fees, if it gives them a sense of control sure let them have it. considering most miners mine to the 750KB default I don't think anyone needs to optimize this much until the TX mem pool is a little bigger and block subsidy smaller.

techgeek

hero member

Activity: 826

Merit: 1000

so is the 20 mb going to happen before the unavoidable clogged confirmation times, or are we already in the process of something now?

I rather see this now then later in my view.

rocks

legendary

Activity: 1153

Merit: 1000

Quote from: cypherdoc on June 17, 2015, 02:28:08 PM

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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".

I agree with this, what I was trying to get at is the outcome of this proposal (miner voting +IBLT) essentially forces or at least encourages maximum blocksize over time. This is in the interest of users and why I like the proposal.

Erdogan

legendary

Activity: 1512

Merit: 1005

Quote from: Adrian-x on June 17, 2015, 02:21:57 PM

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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.

thezerg

legendary

Activity: 1246

Merit: 1010

Quote from: TPTB_need_war on June 17, 2015, 10:13:09 AM

Quote from: thezerg on June 17, 2015, 09:45:08 AM

Quote from: TPTB_need_war on June 17, 2015, 09:20:59 AM

Quote from: thezerg on June 17, 2015, 09:06:52 AM

Quote from: TPTB_need_war on June 17, 2015, 02:50:25 AM

Quote from: thezerg on June 16, 2015, 05:29:20 PM

Quote from: TPTB_need_war on June 16, 2015, 05:24:15 PM

Quote from: thezerg on June 16, 2015, 05:17:00 PM

Quote from: cypherdoc on June 16, 2015, 03:39:51 PM

Quote from: thezerg on June 16, 2015, 03:38:09 PM

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://bitcointalksearch.org/topic/proof-of-storage-to-make-distributed-resource-consumption-costly-310323) "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).

rocks

legendary

Activity: 1153

Merit: 1000

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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.

rocks

legendary

Activity: 1153

Merit: 1000

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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".

Adrian-x

legendary

Activity: 1372

Merit: 1000

Quote from: Erdogan on June 17, 2015, 02:13:39 PM

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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."

cypherdoc

legendary

Activity: 1764

Merit: 1002

http://imgur.com/uCd0Vx1

Erdogan

legendary

Activity: 1512

Merit: 1005

Quote from: cypherdoc on June 17, 2015, 12:59:20 PM

Quote from: rocks on June 17, 2015, 12:54:00 PM

Quote from: NewLiberty on June 17, 2015, 04:58:44 AM

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

Activity: 1764

Merit: 1002

Quote from: _mr_e on June 17, 2015, 02:01:08 PM

Quote from: cypherdoc on June 17, 2015, 01:58:37 PM

Quote from: _mr_e on June 17, 2015, 01:56:09 PM

Quote from: cypherdoc on June 17, 2015, 01:53:45 PM

Quote from: _mr_e on June 17, 2015, 01:51:44 PM

Quote from: cypherdoc on June 17, 2015, 01:42:36 PM

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.

cypherdoc

legendary

Activity: 1764

Merit: 1002

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.

_mr_e

legendary

Activity: 817

Merit: 1000

Quote from: cypherdoc on June 17, 2015, 01:58:37 PM

Quote from: _mr_e on June 17, 2015, 01:56:09 PM

Quote from: cypherdoc on June 17, 2015, 01:53:45 PM

Quote from: _mr_e on June 17, 2015, 01:51:44 PM

Quote from: cypherdoc on June 17, 2015, 01:42:36 PM

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.

Topic: Gold collapsing. Bitcoin UP. - page 222. (Read 2032248 times)