This would be a bigger issue if gavin used the funds for an Avalon unit or something instead of distributing it to miners.
I dont think people donated to the faucet so it could be distributed to miners.
Topic: Compensating miners on the wrong side of The Big Fork (Read 15047 times)
I dont think people donated to the faucet so it could be distributed to miners.
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable.
That's why a new limit (4500) was added.Pretending it was never a rule is just distorting the facts.
Also, note that in most cases the 48xx is an exact (unknown) number. It just wasn't worth anyone's time to figure out what it was.
You are basically saying that it is NOT an exact number. To be a rule, "most cases" is not enough, it has to be true for EVERY cases.
To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community. If you like, think of it as a bulk payment of transaction fees that the faucet would have paid if it had been operating over the last year instead of closed (due to lack of time for me to fight the scammers).
Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
It seems that Gavin wanted to give out the coins someway, since the faucets are not really working any more in this era of higher transaction fees. Also, don't you also think he has more important things to do other than to dole out money? I am no expert in mining, but I feel it is generally better not to sit on some pools of money that don't belong to you, and there is confusion to whom they should rightfully belong. Therefore I accept this decision.
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable.
That's why a new limit (4500) was added.Pretending it was never a rule is just distorting the facts.
Also, note that in most cases the 48xx is an exact (unknown) number. It just wasn't worth anyone's time to figure out what it was.
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable.
That's why a new limit (4500) was added.This is a NEW rule. Aren't we talking about the fork (when the bug (your so-called "rule") placed a limit at 48xx)?
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable.
That's why a new limit (4500) was added. https://en.bitcoin.it/wiki/BIP_0050
A rule should be something agreed to every nodes.
However, according to BIP0050:
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule.A rule should be something agreed to every nodes.
However, according to BIP0050:
Quote
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
Which part is you referring to? Please elaborate. A rule should be something reproducible in every single node of the same version. (e.g. the CHECKMULTISIG bug could be considered as a rule)
The exact number was never identified (a new limit of 4500 was added to be safer), and in some edge cases (due to the bug) could vary, but in no circumstance except a 50% attack would cause a blockchain fork.
To be a rule, you need an exact number like 4823, i.e. a block is accepted by every node if it has 4823 unique tx references, and rejected by every node if it has 4824 unique tx references. Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable.
By compatible the standard default is "backward compatible", include the old behavior
It is lucky that this time the fault is in BDB, what if the fault is located in levelDB?
Basically at the time of accident you had 4 choice:
0.8 is ok, fall back to pre-0.7 won't cause problem since it works already
0.8 is ok, force others to upgrade to 0.8 will solve the problem
0.8 is buggy, force others to upgrade to 0.8 will cause more problem
0.8 is buggy, fall back to pre-0.7 won't cause problem since it works already
If you fall back to 0.7, you have 100% chance to make it work again, and if you forward to 0.8, you have 50% (or other) chance to end up in a mess, it is possible that levelDB accepted some thing that it should not accept, who can be sure in advance, google is not god
It is lucky that this time the fault is in BDB, what if the fault is located in levelDB?
Basically at the time of accident you had 4 choice:
0.8 is ok, fall back to pre-0.7 won't cause problem since it works already
0.8 is ok, force others to upgrade to 0.8 will solve the problem
0.8 is buggy, force others to upgrade to 0.8 will cause more problem
0.8 is buggy, fall back to pre-0.7 won't cause problem since it works already
If you fall back to 0.7, you have 100% chance to make it work again, and if you forward to 0.8, you have 50% (or other) chance to end up in a mess, it is possible that levelDB accepted some thing that it should not accept, who can be sure in advance, google is not god
https://en.bitcoin.it/wiki/BIP_0050
A rule should be something agreed to every nodes.
However, according to BIP0050:
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule.A rule should be something agreed to every nodes.
However, according to BIP0050:
Quote
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
Which part is you referring to? Please elaborate. A rule should be something reproducible in every single node of the same version. (e.g. the CHECKMULTISIG bug could be considered as a rule)
The exact number was never identified (a new limit of 4500 was added to be safer), and in some edge cases (due to the bug) could vary, but in no circumstance except a 50% attack would cause a blockchain fork.
https://en.bitcoin.it/wiki/BIP_0050
A rule should be something agreed to every nodes.
However, according to BIP0050:
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule.A rule should be something agreed to every nodes.
However, according to BIP0050:
Quote
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
Which part is you referring to? Please elaborate. A rule should be something reproducible in every single node of the same version. (e.g. the CHECKMULTISIG bug could be considered as a rule)
https://en.bitcoin.it/wiki/BIP_0050
A rule should be something agreed to every nodes.
However, according to BIP0050:
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule. A rule should be something agreed to every nodes.
However, according to BIP0050:
Quote
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases.If you were testing against multiple implementations, you could have caught the problem as Eligius did.
(Not to say you are at fault for the hardfork, but these are the reality of it)
Slush was creating blocks with "official" client and following the dev's advise to increase the block size.
There is no such thing as official, and I already agreed he isn't at fault for the problem.The block is accepted by every 0.8 nodes. What do you mean by "an invalid block under the standing Bitcoin rules"?
EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules?
There was a hardfork around the move to 0.3, so that is the oldest that would work to any extent with the standing Bitcoin rules.EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules?
Changes in rules require advance planning and notification, and the consent of the economic majority (note, not the mining majority).
Nobody had any notice of 0.8's rule change (because nobody knew about the rule), and the majority of Bitcoin users (including the economic majority) enforced the standing rules.
0.8 was the "odd man out" disagreeing over the network rules. All* the other clients agreed the block was invalid.
The objective way to look at the situation is to pretend 0.8 was a completely new client with unknown source/origin introduced to the network by an unknown party.
* The only other exception I am aware of was Coinbase's proprietary node, which I think can be agreed does not make a difference on its own.
https://en.bitcoin.it/wiki/BIP_0050
A rule should be something agreed to every nodes.
However, according to BIP0050:
Quote
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases.If you were testing against multiple implementations, you could have caught the problem as Eligius did.
(Not to say you are at fault for the hardfork, but these are the reality of it)
Slush was creating blocks with "official" client and following the dev's advise to increase the block size.
There is no such thing as official, and I already agreed he isn't at fault for the problem.The block is accepted by every 0.8 nodes. What do you mean by "an invalid block under the standing Bitcoin rules"?
EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules?
There was a hardfork around the move to 0.3, so that is the oldest that would work to any extent with the standing Bitcoin rules.EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules?
Changes in rules require advance planning and notification, and the consent of the economic majority (note, not the mining majority).
Nobody had any notice of 0.8's rule change (because nobody knew about the rule), and the majority of Bitcoin users (including the economic majority) enforced the standing rules.
0.8 was the "odd man out" disagreeing over the network rules. All* the other clients agreed the block was invalid.
The objective way to look at the situation is to pretend 0.8 was a completely new client with unknown source/origin introduced to the network by an unknown party.
* The only other exception I am aware of was Coinbase's proprietary node, which I think can be agreed does not make a difference on its own.
Gavin can do what he wants with his personal bitcoins, but those funds were donated to the Bitcoin Faucet with the understanding that they would be distributed to new Bitcoin users, not as a bailout for miners.
Misappropriation of donated funds, sounds very Wall Street like!
I agree miners should not receive a bailout. The money would be better invested if it could prevent this in the future.
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases.If you were testing against multiple implementations, you could have caught the problem as Eligius did.
(Not to say you are at fault for the hardfork, but these are the reality of it)
You are really crazy. Slush was creating blocks with "official" client and following the dev's advise to increase the block size. The block is accepted by every 0.8 nodes. What do you mean by "an invalid block under the standing Bitcoin rules"?
EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules?
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
Eh, what? Can you point me to the rule which has been known at time of the fork, which has been violated by the pool?
You *know* that no known bitcoin rule has been violated and that it was a bug of previous implementations. Tell me why are you spreading new FUD.
Excuse me, but I'll ignore any your reaction. I'm just bored with your kind of communication.
I'm sorry you have a problem with the truth being presented accurately when you don't like the facts.
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
Eh, what? Can you point me to the rule which has been known at time of the fork, which has been violated by the pool?
You *know* that no known bitcoin rule has been violated and that it was a bug of previous implementations. Tell me why are you spreading new FUD.
Excuse me, but I'll ignore any your reaction. I'm just bored with your kind of communication.
To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community. If you like, think of it as a bulk payment of transaction fees that the faucet would have paid if it had been operating over the last year instead of closed (due to lack of time for me to fight the scammers).
Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
Who is EFF?Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
http://tinyurl.com/ckxn8bt
To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community. If you like, think of it as a bulk payment of transaction fees that the faucet would have paid if it had been operating over the last year instead of closed (due to lack of time for me to fight the scammers).
Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
Who is EFF? Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases.If you were testing against multiple implementations, you could have caught the problem as Eligius did.
(Not to say you are at fault for the hardfork, but these are the reality of it)
To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community.
This indeed makes a difference, since those funds were unable to be used for their intended purpose (EFF legal work). Thanks for clarifying. Jump to: