Topic: Compensating miners on the wrong side of The Big Fork (Read 15039 times)

I dont think people donated to the faucet so it could be distributed to miners.

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.

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.

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.

This is a NEW rule. Aren't we talking about the fork (when the bug (your so-called "rule") placed a limit at 48xx)?

That's why a new limit (4500) was added.

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

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

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)

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

Yes, start off with an ad hominem. Fits your post pretty well.

There is no such thing as official, and I already agreed he isn't at fault for the problem.

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.

I agree miners should not receive a bailout.  The money would be better invested if it could prevent this in the future.

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?

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.

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.

http://tinyurl.com/ckxn8bt

Who is EFF?

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)

This indeed makes a difference, since those funds were unable to be used for their intended purpose (EFF legal work). Thanks for clarifying.

I'm sure HHTT Pool appreciate this (I mine there), as well as any other Pool operators there was 3 Orphaned blocks this month for HHTT.
Not sure how many of these were related to the "Big Fork".

According to the stats, it's still running at a loss due to their low fees, to being able to recoup something, will be nice for Fireduck.

So as a miner, I thank you. I didn't gain anything, other than to know you probably kept my pool operator happy.

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

This is wrong.
Funds not donated for this purpose were used without the permission of the donators.
Return the coins.

What about OKPay? Have they gotten their money back or been compensated?

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.

 Nice. Me also mined when the orphaned blocks occured. How long is this compensation valid? Currently I am mining on another pool but want to switch back later

This would be a bigger issue if gavin used the funds for an Avalon unit or something instead of distributing it to miners.

Something bugs me about this... I feel like losing money thanks to chain forks kind of comes with the territory. This is not the first or the last time a big fork is going to happen, and small forks happen quite frequently. That, combined with the fact that faucet funds were supposed to be used for, well, the faucet, rubs me the wrong way. I guess this is all Gavin's money to do with as he pleases, but it seems to show some disregard for the implicit wishes of people who donated to the faucet.

Misappropriation of donated funds, sounds very Wall Street like!

Hmm, so by that logic miners should be okay to continue mining on the 0.8 chain now... the line has to be drawn somewhere.

The problems I see with this (and why I think it was a bad idea):

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

Edit: That said, what's done is done, and arguing over it isn't going to get anywhere.

Looks like 31 orphan blocks paid.  200 BTC to a change address (you'll notice one address was paid 200 BTC, which would indicate an address that a pool mines directly to, but the address has never been used before).  This matches the length of the orphan chain:  225430 - 225461.

The only minor concern is that the 0.7 chain was restored at 07:30 UTC, which means 6 blocks in the 0.8 orphan fork were mined AFTER the issue should have been resolved if running a standard bitcoind (as far as I'm aware).  However, if the decision was made to pay out the orphan chain, it would seem unfair to withhold that compensation on certain blocks in the chain.

Obviously, this is pretty popular, based on the last few posts.  But I am completely baffled.

1.  It's not unlike the Cyprus government bailing out the failing banks by giving them 10% of the citizens bank accounts.  [Is there nobody aside from the big bankers (miners) who could use Faucet funds?]

2.  It rewards miners who ignored the advice of the night of the event.  Paraphrasing the advice:  "If you can't mine the 0.7 fork, please stop mining."  OK.  So many miners and individuals stopped mining the 0.8 fork.  Their compensation?  Nothing.  But for those who ignored your advice and continued to mine the 0.8 fork?  Here's some coin to compensate for your efforts.  Even though those efforts were against our posted request.  And even though those efforts caused the fork to be longer than it otherwise might have been.  And even though those efforts are causing us to compensate more miners like yourself who mined the wrong fork after we asked you to stop.

3.  I don't know if Eligius mined any block on the bad fork.  But if Eligius (or other mining pols who pay directly to the end-users) did mine any orphan blocks, won't your policy of paying to the addresses in the coinbases of the orphaned blocks result in a windfall double-payment for a few individual miners, and nothing for the rest of their pool?  Update:  I don't see any such payouts.

I'm sorry I sound so negative, but it seems the big mining pools are pulling the strings of BItcoin, just like big banks are pull the strings of their governments.

4.  I thought there were 25 orphaned blocks.  It appears the referenced transaction is reimbursing approximately 40 25-coin transactions.

I thought Bitcoin decisions were originally to be voted on by the masses of users, not a handful of elite mining conglomerates and/or "a few groups of people".  "Groups of people" can do what they want with their bitcoin.  But, coming through Gavin, this sounds like an official bitcoin decision.

Wow, what an amazing gesture. Thank you on behalf of the community.

Thank you for being a good person and an outstanding member of the community. 

Gavin, I love you.

I think everyone knows that already, since there is a big picture of you my the wall at the BitInstant office.

Thank you Gavin for such surprising decision. Pool is adding rewards for these orphaned blocks to user accounts right now.

BTC Guild miners have already/always been paid for orphaned blocks, but this is a greatly appreciated gesture after the losses incurred by the pool earlier that week.  Thank you very much Gavin & "few groups of people".

P2pool miners thank you for the kind donation!

After talking with a few groups of people, I decided a good use of Bitcoin Faucet funds would be compensating miners who had blocks that were orphaned in last week's Bit Chain Fork.

This is a one-time thing-- don't expect orphaned blocks in the future to be compensated! It is just a coincidence that I haven't had time to fix the Faucet, and have a bunch of coins waiting to be given away.

Transaction id paying the to the addresses in the coinbases of the orphaned blocks: c931f1aa9f0d211dca085342ec472e77b538b55980a2c7b0ff9fab9a20a9acd2