Why I see the bitcoind currently distributed in Gentoo Linux as broken

[oyvinds]

What is needed is an electronic payment system based on cryptographic proof instead of trust,
allowing any two willing parties to transact directly with each other without the need for a trusted third party. https://bitcoin.org/bitcoin.pdf

To me an ideal payment network has the following properties:

- All funds ("coins" in the case of Bitcoin) are equal
- All parties are equal

I like Bitcoin because it does have these properties (for now).

The differnece between the "bitcoind" and "bitcoin-qt" distributed by Gentoo Linux and github

Gentoo Linux currently distribues a version of bitcoind and bitcoin-qt which includes a set of patches by "Luke-Jr". These patches include a hardcoded blacklist. Who gets to be on this blacklist is solely up to "Luke-Jr".

This decision is currently being debated as Gentoo Bug #524512

My main problem with this is that all parties are NOT equal when you have a few select players who are put on a blacklist.

If there is more than an imaginary problem to be solved then the solution should be something which applies equal to everyone. A "solution" which singles out a few select players is not fair, or good.

"If this were a dictatorship, it'd be a heck of a lot easier, just so long as I'm the dictator."

-President-elect George W. Bush, at a photo-op with congressional leaders during his first trip to Capitol Hill, Washington, D.C., Dec. 19, 2000

There is a word for a management style like the one used to choose who gets to be blacklisted and who does not.

Authoritarianism -noun

1. A form of government characterized by strict obedience to the authority of the state, which often maintains and enforces social control thorugh the use of oppressive measures. A dictatorial system which views the state of nation as superior to the individuals or groups composing it.

2. The personality or management style of an individual, organization or collective which seeks to dominate those within its sphere of influence and enforces rather than builds concensus.

3. See Contemporary Military/Industrial/Governmental/Legislative/Corporate/Media Complex

This is not the kind of management style I prefer for Bitcoin or GNU/Linux distributions in general. I am specially sceptical when the person who solely gets to decide who gets blacklisted or not has this to day about his political views:

"I will freely admit to being an enemy of libertarianism. The form of government that seems to work out best in practice is a monarchy. bitcointalk: Is one of the devs (Luke-Jr) an enemy of Bitcoin?

The technical argument

Luke-Jr has been arguing that SD and sites like it are a "DDOS" on the Bitcoin network for years and years. There is no concensus on this. I personally do not care too much about the technical argument. SD is paying transaction fees for their transactions. If I pay $10 for a cup of coffee then I expect to get one, I do not expect the cafe to take my money and then complain loudly that I am a problem because they have to spend energy boiling the water to make my coffee for me nor do I expect them to tell me that I am doing a DOS attack because I am denying the other customers their coffee while they are making mine.

If there is an actual problem to be solved then this needs to be solved in a way which is fair and equal to all.

Why do I care about this at all? Simple. I like Bitcoin. It has poential. My view is that if the properties "All funds are equal" and "All parties are equal" go out the window then it is as good as dead and both the currency and the payment network becomes worthless. It may be a good thing that there are altcoins in case more GNU/Linux distributions decide to distribute Luke-Jr's bitcoin-qt fork instead of the real thing.

If you have an opinion on this then please comment on Gentoo Bug #524512.

One last little thing: Luke-Jr as repeatedly claimed that I am "trolling" for raising this issue. If you wake up in the morning and you meet a troll then that's just bad luck. If you wake up and meet a troll and the next person you meet is also a troll and you meet trolls all day.. well. you be the judge.

[1714783124]

1714783124

[1714783124]

1714783124

[1714783124]

1714783124

[1714783124]

1714783124

[1714783124]

1714783124

[kuzetsa]

((...snip...))

Luke-Jr has been arguing that SD and sites like it are a "DDOS" on the Bitcoin network for years and years. There is no concensus on this. I personally do not care too much about the technical argument. SD is paying transaction fees for their transactions. If I pay $10 for a cup of coffee then I expect to get one, I do not expect the cafe to take my money and then complain loudly that I am a problem because they have to spend energy boiling the water to make my coffee for me nor do I expect them to tell me that I am doing a DOS attack because I am denying the other customers their coffee while they are making mine.

If there is an actual problem to be solved then this needs to be solved in a way which is fair and equal to all.

Yes, I agree.

"equal to all" is also called fungibility.

Bitcoin is broken once you start breaking fungibility by censoring otherwise valid, fee-paying transactions because they're on a blacklist.

The worst part is, this patch doesn't even check to see how big the transaction is. If someone ran this patchset and doesn't update for several months, the blacklisting would still persist because it really is just hardcoded as:

[ "block this list of addresses used by such and such companies" ] ... rather than:

[ "block transactions which match such and such well-defined pattern" ]

If the blacklist wasn't there, and there was a clear definition for what was being blocked (and it was done so in a procedural way, rather than a static blacklist) then this patchset would at least be closer to being fungible for all (but still not 100% fair, since it's still blacklisting a type of pattern which is otherwise valid and pays fees)

((...snip...))

One last little thing: Luke-Jr as repeatedly claimed that I am "trolling" for raising this issue. If you wake up in the morning and you meet a troll then that's just bad luck. If you wake up and meet a troll and the next person you meet is also a troll and you meet trolls all day.. well. you be the judge.

Yes. I believe that's called "crying wolf" as the old story goes.

Code:

There was a boy tending the sheep who would continually go up to the embankment and shout:

"Help, there's a wolf!"

The farmers would all come running only to find out that what the boy said was not true.

Then one day there really was a wolf but when the boy shouted, they didn't believe him and no one came to his aid.

The whole flock was eaten by the wolf.

-- An english transaction of "Aesop's Fable" about the boy who cried wolf.

This patchset really has a bunch of "less scary" patches too, but that doesn't make the contentious blacklisting any less harmful to the fungibility of bitcoin.

[mpdas108]

I don't see why Luke Jr.'s patches should be default, they should be an optional flag. If someone wants to use their BTC to gamble they should be able to.

A second thought though is what about blacklisting known theft addresses, i.e. destination addresses that stolen funds have ended up in. This would help to deter thieves from being able to spend their stolen BTC.

Just a thought.

[Sukrim]

It is up to every single node operator to decide what transactions to forward and having more tools to decide on this is a good thing to have.

The only objectional feature to me is that there is a small default set of blocked addresses and that it defaults to "enabled" with no further notice. This is unexpected, as this is not a feature of vanilla bitcoin-core, so if you ship it, it should either give a clear indication what has been added or be disabled by default, to match upstream more closely.

[oyvinds]

It is up to every single node operator to decide what transactions to forward and having more tools to decide on this is a good thing to have.

My issue with that Gentoo is doing is that they are not making it up to every single node operator, they have made it the default policy.

I did a emerge -u world which updated my bitcoind and bitcoin-qt and I only found out that I got this patchset when I looked in the log and found entries about "blacklisted transactions". I would still have no idea if I had not looked in the log and actively taken action in order to not get this patchset.

I was indeed duped into running this code.

I am fine with people having a choice, that is what Gentoo's USE flags are all about. Making it the _default_ behaviour is making this choice for you.

[gmaxwell]

FWIW, it's off now (in the overlay, in the real package when it's pulled) http://www.reddit.com/r/Bitcoin/comments/2iuf4s/lukejrs_public_apology_for_poor_gentoo_packaging/

[oyvinds]

FWIW, it's off now (in the overlay, in the real package when it's pulled) http://www.reddit.com/r/Bitcoin/comments/2iuf4s/lukejrs_public_apology_for_poor_gentoo_packaging/

I for one think Luke-Jr is the bigger man here.

We all make mistakes. That is alright, the important thing is to learn from them.

[Matt Y]

Thank you for making this public.

[defaced]

FWIW, it's off now (in the overlay, in the real package when it's pulled) http://www.reddit.com/r/Bitcoin/comments/2iuf4s/lukejrs_public_apology_for_poor_gentoo_packaging/

I for one think Luke-Jr is the bigger man here.

We all make mistakes. That is alright, the important thing is to learn from them.

I agree

[kuzetsa]

The bug is closed now, and flagged as "Resolved + Fixed".

If there are any further issues with weird patches enabled by default in the official gentoo build we should just re-open the bug.

Reference:

Okay, I think this bug is done.  If people want to write alternative ebuilds on overlays, that's fine.  If we need to discuss the ebuild in the tree wrt to this issue, then reopen this bug, else open a different one.

Quote is from comment #62 from gentoo bug #524512.

hotlink: bugs.gentoo.org/show_bug.cgi?id=524512#c62

[Luke-Jr]

If there are any further issues with weird patches enabled by default in the official gentoo build we should just re-open the bug.

No, please file a new bug for new issues.

[kuzetsa]

If there are any further issues with weird patches enabled by default in the official gentoo build we should just re-open the bug.

No, please file a new bug for new issues.

Perhaps, sure. At least I guess that'd make sense if it's actually a new & completely unrelated issue...

But if the issue is the same substance (an ebuild with patches which breaks the expected behavior in one or more ways) it would seems appropriate to reuse the existing bug ID.

For future reference:

Please don't add monolithic "change all of the things" patchsets, as they're harder to debug when everything is just shoved together into a single patch with no commit history available to see which thing was added when and why.

Do you have a repository for this patchset somewhere?

Preferably with concise, yet still informative commit messages for each change as it was made?

Access to that information would be great for anyone who needs to help with the maintenance on this ebuild for the purposes of splitting things off to their own self-contained patches so each use flag has its own patch.

[Luke-Jr]

If there are any further issues with weird patches enabled by default in the official gentoo build we should just re-open the bug.

No, please file a new bug for new issues.

Perhaps, sure. At least I guess that'd make sense if it's actually a new & completely unrelated issue...

But if the issue is the same substance (an ebuild with patches which breaks the expected behavior in one or more ways) it would seems appropriate to reuse the existing bug ID.

For future reference:

Please don't add monolithic "change all of the things" patchsets, as they're harder to debug when everything is just shoved together into a single patch with no commit history available to see which thing was added when and why.

Do you have a repository for this patchset somewhere?

Preferably with concise, yet still informative commit messages for each change as it was made?

Access to that information would be great for anyone who needs to help with the maintenance on this ebuild for the purposes of splitting things off to their own self-contained patches so each use flag has its own patch.

The patch is my 0.9.x-ljr branch.
You'll find splitting it up is not so easy (you'll get merge conflicts with different combinations).

[kuzetsa]

(...snip...)

[...] commit history available to see which thing was added when and why.

Do you have a repository for this patchset somewhere?

Preferably with concise, yet still informative commit messages for each change as it was made?

Access to that information would be great for anyone who needs to help with the maintenance on this ebuild for the purposes of splitting things off to their own self-contained patches so each use flag has its own patch.

The patch is my 0.9.x-ljr branch.
You'll find splitting it up is not so easy (you'll get merge conflicts with different combinations).

I haven't checked yet, but is this most of the relevant code from your patch?

https://github.com/luke-jr/bitcoin/compare/bitcoin:0.9.3...0.9.x-ljr?diff=unified

[Luke-Jr]

(...snip...)

[...] commit history available to see which thing was added when and why.

Do you have a repository for this patchset somewhere?

Preferably with concise, yet still informative commit messages for each change as it was made?

Access to that information would be great for anyone who needs to help with the maintenance on this ebuild for the purposes of splitting things off to their own self-contained patches so each use flag has its own patch.

The patch is my 0.9.x-ljr branch.
You'll find splitting it up is not so easy (you'll get merge conflicts with different combinations).

I haven't checked yet, but is this most of the relevant code from your patch?

https://github.com/luke-jr/bitcoin/compare/bitcoin:0.9.3...0.9.x-ljr?diff=unified

That should be identical to it.

[kuzetsa]

The patch is my 0.9.x-ljr branch.
You'll find splitting it up is not so easy (you'll get merge conflicts with different combinations).

I haven't checked yet, but is this most of the relevant code from your patch?

https://github.com/luke-jr/bitcoin/compare/bitcoin:0.9.3...0.9.x-ljr?diff=unified

That should be identical to it.

Yes, I can see now why you mentioned potential merge conflicts...

Initially I was more concerned with making it as easy as possible to identify the purpose of various sections of the patch before any attempts could be made at a non-monolithic version.

Even if it's just for auditing and reverse engineering purposes, this still helps a lot.

Thanks.

[kuzetsa]

It might be back to a broken state^* soon.

https://bugs.gentoo.org/show_bug.cgi?id=531634 (new tracker ID for proposed gentoo ebuild)


^* broken as defined by the original poster of this thread.