Bitcoin Forum
November 22, 2017, 09:07:31 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Compensating miners on the wrong side of The Big Fork  (Read 14677 times)
BookLover
Hero Member
*****
Offline Offline

Activity: 535


^Bitcoin Library of Congress.


View Profile
March 23, 2013, 03:29:29 PM
 #21

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?

1511384851
Hero Member
*
Offline Offline

Posts: 1511384851

View Profile Personal Message (Offline)

Ignore
1511384851
Reply with quote  #2

1511384851
Report to moderator
1511384851
Hero Member
*
Offline Offline

Posts: 1511384851

View Profile Personal Message (Offline)

Ignore
1511384851
Reply with quote  #2

1511384851
Report to moderator
1511384851
Hero Member
*
Offline Offline

Posts: 1511384851

View Profile Personal Message (Offline)

Ignore
1511384851
Reply with quote  #2

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

Posts: 1511384851

View Profile Personal Message (Offline)

Ignore
1511384851
Reply with quote  #2

1511384851
Report to moderator
1511384851
Hero Member
*
Offline Offline

Posts: 1511384851

View Profile Personal Message (Offline)

Ignore
1511384851
Reply with quote  #2

1511384851
Report to moderator
1511384851
Hero Member
*
Offline Offline

Posts: 1511384851

View Profile Personal Message (Offline)

Ignore
1511384851
Reply with quote  #2

1511384851
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
March 23, 2013, 04:50:09 PM
 #22

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?

http://tinyurl.com/ckxn8bt

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
slush
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
March 23, 2013, 05:55:33 PM
 #23

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.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
March 23, 2013, 06:07:12 PM
 #24

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.
Nobody ever said the rule was known, and that's why I made a clear point that you weren't at fault.
I'm sorry you have a problem with the truth being presented accurately when you don't like the facts.

jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
March 23, 2013, 06:07:46 PM
 #25

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.
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
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?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
mc_lovin
Legendary
*
Offline Offline

Activity: 1162


www.bitcointrading.com


View Profile WWW
March 23, 2013, 06:14:21 PM
 #26

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.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
March 23, 2013, 06:18:41 PM
 #27

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.
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
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.
Yes, start off with an ad hominem. Fits your post pretty well.

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

jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
March 23, 2013, 06:31:06 PM
 #28

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.
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
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.
Yes, start off with an ad hominem. Fits your post pretty well.

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

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
March 23, 2013, 06:54:35 PM
 #29

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.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule.

jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
March 23, 2013, 07:03:40 PM
 #30

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.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol 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)


Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
March 23, 2013, 07:08:41 PM
 #31

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.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol 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)
"No more than 48xx unique transaction references per block"

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.

johnyj
Legendary
*
Offline Offline

Activity: 1834


Beyond Imagination


View Profile
March 23, 2013, 07:24:48 PM
 #32

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




jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
March 23, 2013, 07:26:25 PM
 #33

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.
There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol 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)
"No more than 48xx unique transaction references per block"

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.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
March 23, 2013, 07:28:19 PM
 #34

Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable.
That's why a new limit (4500) was added.

jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
March 23, 2013, 07:31:36 PM
 #35

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)?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
March 23, 2013, 07:32:28 PM
 #36

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)?
Yes, the unacceptable nature of that rule is why we created a new rule as soon as we learned about it.
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.

rpietila
Donator
Legendary
*
Offline Offline

Activity: 1666



View Profile
March 23, 2013, 07:37:40 PM
 #37

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

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

Activity: 1722


View Profile
March 23, 2013, 07:39:42 PM
 #38

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)?
Yes, the unacceptable nature of that rule is why we created a new rule as soon as we learned about it.
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.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Monster Tent
Full Member
***
Offline Offline

Activity: 238



View Profile
March 24, 2013, 08:44:53 AM
 #39

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.

Pages: « 1 [2]  All
  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!