The official bitcoind and bitcoin-qt in Gentoo enables patches which breaks Bitcoin by default. Please disable the ljr patches by default or preferably all together. Enabling the stupidmoralnazi aka ljr use flag results in errors like these: 2014-10-05 11:38:09 ERROR: AcceptToMemoryPool : ignoring transaction 289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice) A currency is worthless the moment you declare that you can use it to buy a bible but not the korean because we don't like that one. Reproducible: Always
PEBKAC, no sign anything is actually broken here. Looks like just a troll. Status: INVALID or WORKSFORME?
This is why it is a bad idea to allow a developer to maintain a package which depends on his own packages. Luke-Jr claimed "nobody is being forced to do anything" when asked why his patches are added to the bitcoind and bitcoin-qt builds by default. When I pointed out that the ebuild does in fact enable his patches by default he just called this "trolling". I find it quite funny that he just claims "troll" when he is called on a lie and can not argue. He also admits that it is his patches that blacklists outputs. This fundamentally breaks Bitcoin. His opinion is that Bitcoin works just fine. A bank would also probably argue that their bank works fine if they decide that groups they dislike can not have accounts there. Using his status as package maintainer to force his political opinions on others is not alright. My opinion is that it should simply not be up to him to decide if "ljr" should be the default for these packages or not since he has a personal interest in this technical (and political) question. Luke-Jr will probably call this trolling to. As someone watching the discussion on #bitcoin-dev on IRC pointed out privately: "Because he thinks hes is special and can not do nothing wrong. And if you point him out something he did not do quite right he ignores it. That's common behavior of these kind of ppl. I think there is a name for it in psychology, but I can't remember."
(In reply to xiando from comment #2) > He also admits that it is his patches that blacklists outputs. This > fundamentally breaks Bitcoin. His opinion is that Bitcoin works just fine. A > bank would also probably argue that their bank works fine if they decide > that groups they dislike can not have accounts there. Using his status as > package maintainer to force his political opinions on others is not alright. > I have not looked into this patch, but can you tell me how I might convince myself that his patch is doing what you say it is doing: namely blacklisting on the basis of discrimination?
(In reply to Anthony Basile from comment #3) > (In reply to xiando from comment #2) > > > He also admits that it is his patches that blacklists outputs. This > > fundamentally breaks Bitcoin. His opinion is that Bitcoin works just fine. A > > bank would also probably argue that their bank works fine if they decide > > that groups they dislike can not have accounts there. Using his status as > > package maintainer to force his political opinions on others is not alright. > > > > I have not looked into this patch, but can you tell me how I might convince > myself that his patch is doing what you say it is doing: namely blacklisting > on the basis of discrimination? #bitcoin-dev on freenode, today. [20:23:20] <xiando> luke-jr is the gentoo package maintainer, thus his patches are enabled by default where as I think they should be a use-flag _disabled_ by default. His opinion is that I am trolling. [20:23:45] <sipa> i have no problem with people enabling such a patch, or making it available, but people shouldn't end up running with such behaviour without being aware of it [20:23:58] <xiando> seeing [20:23:59] <xiando> 2014-10-05 11:38:09 ERROR: AcceptToMemoryPool : ignoring transaction 289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice) [20:24:03] <xiando> in the log is how I learned ... and upon personally inspecting the patch itself: +static struct BlacklistEntry BlacklistedPrefixes[] = { + {0x946cb2e0, 0x946cb2e0, "Mastercoin"}, + {0x06f1b600, 0x06f1b6ff, "SatoshiDice"}, + {0x74db3700, 0x74db59ff, "BetCoin Dice"}, + {0xc4c5d791, 0xc4c5d791, "CHBS"}, // 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T + {0x434e5452, 0x434e5452, "Counterparty"}, + {0x069532d8, 0x069532da, "SatoshiBones"}, + {0xda5dde84, 0xda5dde94, "Lucky Bit"}, +}; This "ljr" use flag, and another feature of the patchset in question is based on a series of contentious decisions which have not been widely supported by the community. Reference: https://bitcointalk.org/index.php?topic=334316.0 ^ bitcoin-0.9.3.ljr20141002.patch also contains the "address reuse" patch.
Anthony Basile: Bitcoin should not blacklist addresses period. As for his reasons, I did assume wrongly about them before Luke-Jr explained why. He wants to stop some users from doing what he considers "an attack" on the network. I noticed that addresses belonging to gambling-related sites were blacklisted when filing this bug, I did not know why at the time (when I see software blacklisting things the first thing that comes to mind is: what will be blacklisted next?). These patches are controversial. Having the patches available is alright, enabling them by default causes non-standard unexpected behavior from the software and I consider that a bug. Here is what the other bitcoin core (bitcoind/bitcoin-qt) think about this (#bitcoin-dev) today: sipa> Luke-Jr: i think making it enabled by default is going too far gmaxwell> Luke-Jr: it's sort of surprising if there is complex default policy that people wouldn't expect. gmaxwell> The defaults should be something that everyone could be comfortable using. Anything that singles out particular parties by definition fails that test. Luke-jr has indicated that he will close this as WORKSFORME (which I am sure it does, it is his patches) or INVALID in which case it would be a "Community Relations" bug/problem.
Just to want to clarify on why the censorship is happening: The (alleged) attack in question is nothing more than a popular business model which has been attractive and actively used to the point where a non-small amount of traffic was generated by the sites in question. Satoshi Dice, for instance, was widely used enough that it became a target for discrimination. Paraphrased: "Too popular, and therefore there is a risk of the bitcoin network running out of capacity because of such business plans and their subsequent usage of bitcoin as a method for conducting business operations" ^ not everyone agrees with this, so it should not be a default. Sipa, and a few other developers (and also admins of several mining pools) have all said that they do not support this policy as a default, or are opting not to use these patches on their pools, etc.
All entries on the blacklist are known DDoS attacks against the Bitcoin network, not political. The vanilla code already attempts to ignore (and thereby mitigate) these kind of attacks[1]. The blacklist feature is just an admittedly ugly hack to improve the reliability of the detection based on known factors - it is unsuitable for the reference code because it is ugly, but until a better solution is implemented, it is safe and appropriate for production use. A perfect long-term solution to these attacks is impractical (similar to other malware filtering) since it is an "arms race", and this interim solution works reliably for now without affecting Bitcoin users negatively (which is a risk for more complex solutions, that they could trigger false positives on legitimate traffic). It certainly does not harm the Bitcoin consensus system in any way, as the patchset is carefully maintained to not affect that code at all. The "address reuse" patch Sarah makes reference could be one of two things, neither of which are included in my patchset due to minor technical issues during testing. In any case, the change is in fact quite UNcontroversial (I believe there is unanimous agreement among Bitcoin experts that it is a good idea), and is likely to make its way into the vanilla codebase. Finally, please note that the quotes xiando posted to "support" his position are taken out of context. Those interested in reading the (rather long) full conversation can get channel logs from http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/06 [1] The vanilla code to handle such attacks is spread out, but mostly branches off https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L804
No, it's really not a DoS attack. There isn't a single reputable journalist or non-fringe blogger who refers to the popularity of the business model of satoshi dice and the other blocked businesses as a "DoS attack" There is nothing protocol-wise which is invalid about the transactions coming from the sources which are being blacklisted by this patch... They're popular enough to push the limits on the bitcoin network capacity, and you and a few other parties have chosen to label this activity with pejorative labels like "DoS attack". quote from mike hearn of the bitcoin foundation: [11:48:36] <hearn> we all use our computers for things ;) people who don't use linux still manage to be productive. anyway, i have no idea what that ebuild will do, but the fact that it's making such changes by default suggests it'd be better to stay away from it entirely. if they want to distribute a bitcoind with patches like luke's (which change behaviour in quite some fundamental ways) then they should do a proper upstream fork with a new name, so [11:48:36] <hearn> you are always sure what you're getting. ^ Source -- http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/05#l1412509714 Regardless of if you agree with the reasons luke wrote this patch, or if you believe that the blacklisted businesses whose successful business model generates enough bitcoin traffic to constitutes a "DoS attack"... ... this patch is actively censoring and changing the behaviors of bitcoin to no longer act the usual way as defined by the the official non-patched defaults.
(In reply to Luke-Jr from comment #7) > The "address reuse" patch Sarah makes reference could be one of two things, > neither of which are included in my patchset due to minor technical issues > during testing. In any case, the change is in fact quite UNcontroversial (I > believe there is unanimous agreement among Bitcoin experts that it is a good > idea), and is likely to make its way into the vanilla codebase. I guess this patch just injects code in a similar way into similar areas... I apologize for my confusion and misidentifying the method you used to filter address reuse for that other patch nobody wanted. It turns out this patch only censors the blacklisted things like Satoshi Dice, BetCoin Dice, Satoshi Bones, Lucky Bit, and a couple other things which are normally allowed by unpatched bitcoin.
Sarah, I really wish you would stop misrepresenting things. Lots of (more) popular services and merchants use Bitcoin just fine without creating a DDoS attack on the network. Their business model is also equally possible (and in fact easier to implement) without creating such an attack. You can argue intentions all you like, but the fact is that objectively, that is what they are doing. If you disagree, or want to help them attack the network, you are free to turn off the USE flag. You can also remove the vanilla filtering by dropping a patch in /etc/portage/patches.
This derailment has gotten a little out of hand. I'm not misrepresenting anything, but rather, I'm pointing the other side to this contentious issue which feels [to you] as though "it's a DoS attack" A lot of people feel that there is no attack, and your patch is just censorship (singling out a few businesses with high transaction volume, and blocking them under the banner of "to protect bitcoin users from a DoS attack") You're a developer on the bitcoin codebase... This sort of blacklisting is a centralized policy decision which was too extreme to be included in the official bitcoin codebase itself. If this censorship policy was intended to be part of bitcoin (by consensus of the community, and the rest of the devs) you wouldn't have needed to create this patch to block gambling websites in the first place. Logically, if this patch wasn't an attempt at outright censorship (like instead, if the code in this patch was a fix for something wrong with the protocol like an actual vulnerability which was a vector for a attack of the sort which gets assigned CVE-YYYY-NNN identifiers) it would've already been included without needing to be a separate patch instead. It can be optional, and enabled via use flag, as suggested by the original submitter for this bug: At the very least this behavior shouldn't be "active by default". At the very least it might be nice if there was some documentation to explain what the patch (and LJR use flag) actually blocks as compared to unpatched bitcoin :)
(In reply to Sarah White from comment #8) > No, it's really not a DoS attack. Let's take the question of intentionality out of this. A DoS "attack" implies that there was an intention to be disruptive. For the sake of argument, assume there is no such intention on the part of Satoshi Dice et al., the question still remains: "do their actions have the consequence of being a disruption to the network?" I'd like to see evidence in some metrics that show the disruption. > > There isn't a single reputable journalist or non-fringe blogger who refers > to the popularity of the business model of satoshi dice and the other > blocked businesses as a "DoS attack" I'm not interested in hear-say. > > There is nothing protocol-wise which is invalid about the transactions > coming from the sources which are being blacklisted by this patch... This is an irrelavent point. There is nothing wrong in the http protocol about 1,000,000 requests per second, however, such a situation would drive any server to the ground. > > They're popular enough to push the limits on the bitcoin network capacity, > and you and a few other parties have chosen to label this activity with > pejorative labels like "DoS attack". Please take into consideration the above point. In a similar situation, people often push the Tor network (as another example) to its limit for either good or malicious reasons. Whatever the intentions, tor nodes are mark "bad" by the network because they disruptive others. There is a presidence for doing this kind of blacklisting in distributed networks where the health of the network is essential to its usefulness. If Satoshi Dice is being distruptive this way (and I don't know that it is, convince me one way or the other with metrics), then I am in favor of blacklisting it until such time the the bitcoin protocol can handle this new type of (ab)use. > > quote from mike hearn of the bitcoin foundation: > > [11:48:36] <hearn> we all use our computers for things ;) people who don't > use linux still manage to be productive. anyway, i have no idea what that > ebuild will do, but the fact that it's making such changes by default > suggests it'd be better to stay away from it entirely. if they want to > distribute a bitcoind with patches like luke's (which change behaviour in > quite some fundamental ways) then they should do a proper upstream fork with > a new name, so > [11:48:36] <hearn> you are always sure what you're getting. > > ^ Source -- > http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/05#l1412509714 > > Regardless of if you agree with the reasons luke wrote this patch, or if you > believe that the blacklisted businesses whose successful business model > generates enough bitcoin traffic to constitutes a "DoS attack"... > > ... this patch is actively censoring and changing the behaviors of bitcoin > to no longer act the usual way as defined by the the official non-patched > defaults. Censoring also implies intentionality. There may exist purely technical reason why certain uses of the network should be limited so that others may enjoy it. Let me put my point as concisely as possible. I'm uninterested in any judgments about the moral implications of this patch. I'd like to see metrics showing conclusively whether or not it is disruptive.
Anthony Basile: I see no reason to provide more proof that none of the sites blacklisted are disruptive beyond the simple fact that the Bitcoin network works just fine without this patch. The burden of evidence here lies with the censor. It must also be noted that a solution would be implemented in the Bitcoin Core if this was an actual problem. It is not. These patches are rejected upstream. There would be no need for these patches if there were an actual problem to be solved since a solution would be implemented upstream. Satoshidice and the others are as good as any other users of Bitcoin. If the network can not keep up with normal use-cases then a Bitcoin is worthless and without any use outside of academia. The more fundamental questions are actually: * the very clear and strong conflict of interest the maintainer of this package has and what Gentoo's policy towards such conflicts of interest is and will be in the future. * is netflix doing a DDOS on the Internet because of their above-average traffic? * do we want a blacklist of "bad" people? And please think about this last point for a moment: If we do accept blacklists of "bad people" who do not get to use Bitcoin: Who should get to decide who is "good" and "bad"? Why should this solely be up to LukeJr? As for Tor nodes, that is a bad example to cite. Tor exit nodes are sometimes marked bad because they modify traffic coming through them (man in the middle ssl attacks etc) and that is hardly the same thing. No Tor nodes or users have ever been banned for using the network in "unapproved" ways.
My 2c after talking to Xiando in the IRC. My main issue is that stuff like blacklists should not be hardcoded into code, unless it causes hardware issues or the like. The other issue is usability. Even if these addresses are known to be bad, a: the user of the software should decide if they are, and b: its just bad programming. Its just bad programming to add lists like that into code, we all should know this by now. Things change, and having to recompile a program to add a bad actor is just wrong. It should be a dynamically loaded file on start up, or a way though the program to change the list of bad actors.
(In reply to xiando from comment #13) > Anthony Basile: I see no reason to provide more proof that none of the sites > blacklisted are disruptive beyond the simple fact that the Bitcoin network > works just fine without this patch. The burden of evidence here lies with > the censor. The request for evidence is for both sides. Luke-jr can also present me with something to prove what he's saying is true. In the absense of anything concrete, I'm going with upstream. > > It must also be noted that a solution would be implemented in the Bitcoin > Core if this was an actual problem. It is not. These patches are rejected > upstream. There would be no need for these patches if there were an actual > problem to be solved since a solution would be implemented upstream. > > Satoshidice and the others are as good as any other users of Bitcoin. If the > network can not keep up with normal use-cases then a Bitcoin is worthless > and without any use outside of academia. > > The more fundamental questions are actually: > > * the very clear and strong conflict of interest the maintainer of this > package has and what Gentoo's policy towards such conflicts of interest is > and will be in the future. > * is netflix doing a DDOS on the Internet because of their above-average > traffic? > * do we want a blacklist of "bad" people? > > And please think about this last point for a moment: > > If we do accept blacklists of "bad people" who do not get to use Bitcoin: > Who should get to decide who is "good" and "bad"? Why should this solely be > up to LukeJr? > > As for Tor nodes, that is a bad example to cite. Tor exit nodes are > sometimes marked bad because they modify traffic coming through them (man in > the middle ssl attacks etc) and that is hardly the same thing. No Tor nodes > or users have ever been banned for using the network in "unapproved" ways. All of bhe above statements simply assume that there is nothing disruptive going on. If so then you're right. If not then you're wrong. I'm trying to get as much information before I act.
(In reply to Trevor Benedict from comment #14) > My 2c after talking to Xiando in the IRC. > > My main issue is that stuff like blacklists should not be hardcoded into > code, unless it causes hardware issues or the like. > > The other issue is usability. Even if these addresses are known to be bad, > a: the user of the software should decide if they are, and b: its just bad > programming. > I will put the power back in the user's hands to decide if I don't get something to coninvce me otherwise. Sometimes users can't decide (or shouldn't) because something subtle is at stake. I don't think that's the case here. > Its just bad programming to add lists like that into code, we all should > know this by now. Things change, and having to recompile a program to add a > bad actor is just wrong. It should be a dynamically loaded file on start up, > or a way though the program to change the list of bad actors. Agreed.
To ensure users are aware of the USE flag, how about adding something like this? einfo Two flavours of Bitcoin Core are available in Gentoo, depending on the 'ljr' USE flag. einfo With USE=ljr (default), you will get a number of improvements by Luke Dashjr. This includes (among many other things) a blacklist-based spam filter which extends the vanilla spam filtering to explicitly match for known attacks on the Bitcoin network. einfo If you build with USE=-ljr, you will get the vanilla code as released upstream. This is not as effective in filtering spam, and is not appropriate for mining, but has had more review and testing.
(In reply to Luke-Jr from comment #17) > To ensure users are aware of the USE flag, how about adding something like > this? > > einfo Two flavours of Bitcoin Core are available in Gentoo, depending on the > 'ljr' USE flag. > einfo With USE=ljr (default), you will get a number of improvements by Luke > Dashjr. This includes (among many other things) a blacklist-based spam > filter which extends the vanilla spam filtering to explicitly match for > known attacks on the Bitcoin network. > einfo If you build with USE=-ljr, you will get the vanilla code as released > upstream. This is not as effective in filtering spam, and is not appropriate > for mining, but has had more review and testing. Why is it "appropriate" for gentoo to have a default which uses this hardcoded patch to blacklist things [which you consider to be spam], as contrasted to "not appropriate" to set up a mining pool (or solo mine, or use p2pool distributed pool, etc.) which uses the vanilla policies from upstream?
After having spoken with some people here's what I've come up with 1) Sitoshi Dice's practice of creating transactions that never get spent does add cruft to the UTXO and affects the future efficiency of all bitcoin nodes. While not a DoS, it does negatively impact the community. The degree of negativity is difficult to assess but it is not a good practice. 2) Most users are probably ignorant of this issue and should be informed so they can make an intelligent decision about what the ljr patch does. 4) Luke-jr's patch addresses a technical issue. It also does other things, but those are not contraversial. Luke-jr is upstream with bitcoin and so I trust the quality of the patch. 5) Luke-jr's critics did not address the technical issue or even admit it, rather they focused on censorship which they failed to demonstrate. The sites in question are poluting the UTXO while there exist many other sites of greater moral turpitude which do not polute the UTXO and are not blacklisted. Here's what I'm going to do: 1) The patch stays. 2) I will leave the patch on by default. 3) There will be an einfo pkg_postint message describing what's going and direct the user to this bug for more information. I will listen to responses to this decision for a few days and then make a final decision.
(In reply to Anthony Basile from comment #19) > > 4) Luke-jr's patch addresses a technical issue. It also does other things, > but those are not contraversial. Luke-jr is upstream with bitcoin and so I > trust the quality of the patch. > This is poorly written. What I meant to say is "Luke-jr's patch addresses this technical issue."
(In reply to Anthony Basile from comment #19) > 1) Sitoshi Dice's practice of creating transactions that never get spent > does add cruft to the UTXO and affects the future efficiency of all bitcoin > nodes. While not a DoS, it does negatively impact the community. The > degree of negativity is difficult to assess but it is not a good practice. I don't know where you got this information, but it's not current. Any strange transactions which may have occurred in the past are not relevant for the purposes of blacklisting current operations, and there doesn't seem to be anything unspendable taking place these days. randomly selected satoshi dice transactions from today: https://blockchain.info/tx/a3b8f07e170c93534ddc8fcabfe9ea7d6c0659e5762a93dd08bb945b97b0b42d https://blockchain.info/tx/b17aa98be1f3cc0bbcf9982950223a8159dfb198900aac8289ab496c723ef43a 0.12016391 payout VS 0.0614532 bet, and the transaction for this "win" bet was: 1) NOT creating any smaller "dust" outputs (unspendable UTXOs) 2) scooped up three smaller UTXOs (average size 0.11972971 BTC) and resulted in two UTXOs (which are a new average size of aprox 0.175 BTC, and the transaction "winning bet" transaction even paid a fee) ... on the point of "practice of creating transactions that never get spent", I say [citation needed] -- and make it something current please, at least as recent as 1st quarter 2014
(In reply to Sarah White from comment #21) > > I don't know where you got this information, but it's not current. > Two upstream developers not including Luke-jr. While I don't fully understand bitcoin, what they said fits my intuition about what's going on here.
For reference, " Two upstream developers not including Luke-jr." conversation: http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/06#l1412618837 I guess the Gentoo policy will be that it is alright for a payment network to accept a transaction fee for a service without delivering said service because someone decided to blacklisting them for using this service. :) 1) My practice of creating transactions add cruft to the blackchain and affects the future efficiency of all bitcoin nodes because this transaction is then stored in the blockchain (which is how Bitcoin works). While not a DoS, it does negatively impact the community because they have to provide the service I've paid a transaction fee for. The degree of negativity is difficult to assess but it is supposedly not a good practice. Well, there is always the option of USE="-ljr" or git glone upstream. :)
(In reply to xiando from comment #23) > I guess the Gentoo policy will be that it is alright for a payment network > to accept a transaction fee for a service without delivering said service > because someone decided to blacklisting them for using this service. :) Total non-argument. Nodes which do not relay or mine transactions do not collect the fee offered for them. More notably, nodes which *do* relay them still do not collect the fee for them. Finally, nodes which are burdened by them, do not collect the fee for them. The fee is only collected by the miner who puts them in a block, by his free market choice to do so. Fees exist to discourage spam, not to compensate for the costs of the transaction. > 1) My practice of creating transactions add cruft to the blackchain and > affects the future efficiency of all bitcoin nodes because this transaction > is then stored in the blockchain (which is how Bitcoin works). Also a non-argument. The blockchain was created for financial transactions. That doesn't mean it's acceptable or equivalent to use it for other purposes such as spammy messaging, especially when such abuses make legitimate use more difficult and/or costly. Basically you're saying that a personal email from Joe to his friend is the same as a recurring unsolicited bulk advertisement from a botnet to everyone in the world.
I dont like extra options that arent required for base functionality being forced in to my programs by default. Thats why I use Gentoo, because I have the choice of adding or not adding the extra options depending on my needs. I believe this patch as it is now should be disabled by default. I think the blacklist part should be separated and named a different use flag from the rest of the patch, maybe +ljr and +ljrnospam. That would solve being able to include the technical fixes while still disagreeing entirely with the blacklist. The blacklist patch has been floating around for years. My opinion is that the bigger part of this patch is a vehicle to get this controversial code installed by default on as many machines as possible.
(In reply to ddube from comment #25) > I dont like extra options that arent required for base functionality being > forced in to my programs by default. Thats why I use Gentoo, because I have > the choice of adding or not adding the extra options depending on my needs. > > I believe this patch as it is now should be disabled by default. I think the > blacklist part should be separated and named a different use flag from the > rest of the patch, maybe +ljr and +ljrnospam. That would solve being able to > include the technical fixes while still disagreeing entirely with the > blacklist. > > The blacklist patch has been floating around for years. My opinion is that > the bigger part of this patch is a vehicle to get this controversial code > installed by default on as many machines as possible. Agreed on all points. Documentation please on the LJR patchset please (as exhaustive as possible) before anything gets flagged as a default. Not everyone has time to audit code like this, and the "all or nothing" monolithic nature for this patchset which changes so many things is probably bad practice, particularly as a default. When I did further auditing today on the LJR patchset, I noticed the "child pays for parent" patch which really stood out as being desirable -- I'd definitely be interested having an atomic non-monolithic use flag for the "child pays for parent" portion of this patchset WITHOUT all the other cruft I have no interest in. I DO NOT feel that any functionality from this optional patchset, even portions which I'd personally be interested in should be forced on anyone since it's not required for core bitcoin functionality. Please change the defaults for to being 100% vanilla bitcoind / bitcoin-qt from upstream :)
(In reply to Sarah White from comment #26) > (In reply to ddube from comment #25) > When I did further auditing today on the LJR patchset, I noticed the "child > pays for parent" patch which really stood out as being desirable -- I'd > definitely be interested having an atomic non-monolithic use flag for the > "child pays for parent" portion of this patchset WITHOUT all the other cruft > I have no interest in. What I meant was: I'd like it if the "child pays for parent" feature should be a standalone patch [with a corresponding use flag] (The reference to atomicity was a brainfart, sorry... All I'm saying is that this patchset really does have too many things in it which are "all or nothing", I do not agree with all of it, but portions are highly desirable)
(In reply to Sarah White from comment #21) > > ... on the point of "practice of creating transactions that never get > spent", I say [citation needed] -- and make it something current please, at > least as recent as 1st quarter 2014 Are you denying the negative impact of Satoshi Dice's practice of adding non-spendable transactions which fill the UTXO? This occurs when Satoshi Dice tells users that they lost. An example is 855d1acfbfce4cabd07ee6581b920460a04576e67260d4a2b22932d90a14fedf. I am convinced that this is a bad practice.
(In reply to Anthony Basile from comment #28) > (In reply to Sarah White from comment #21) > > > > ... on the point of "practice of creating transactions that never get > > spent", I say [citation needed] -- and make it something current please, at > > least as recent as 1st quarter 2014 > > Are you denying the negative impact of Satoshi Dice's practice of adding > non-spendable transactions which fill the UTXO? This occurs when Satoshi > Dice tells users that they lost. An example is > 855d1acfbfce4cabd07ee6581b920460a04576e67260d4a2b22932d90a14fedf. > > I am convinced that this is a bad practice. Sure what Satoshidice does may be inconvenient in different ways to different people. That part isnt in dispute here. What does matter is if Gentoo should be dictating a default blacklist to its users about which services their programs are allowed to interact with. It should be disabled by default, and then allow the user to choose later if they want the blacklist, through education and a separate use flag.
> Are you denying the negative impact of Satoshi Dice's practice of adding > non-spendable transactions which fill the UTXO? This occurs when Satoshi Dice > tells users that they lost. An example is > 855d1acfbfce4cabd07ee6581b920460a04576e67260d4a2b22932d90a14fedf. > I am convinced that this is a bad practice. As I said before, I view this as irrelevant. If you see a nail then you do not "solve" that by detonating a nuclear warhead. Is the concept of a blacklist compatible with threating all players equal? Allowing one person to dictatorially choose who does and not does get to be on a blacklist is not something I view as an acceptable solution nor do I view it as acceptable Gentoo policy. There is a word for this: 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 If you actually believe there is a problem then look for a solution which is equal for everyone. >Total non-argument. Nodes which do not relay or mine transactions do not >collect the fee offered for them. More notably, nodes which *do* relay them >still do not collect the fee for them. Finally, nodes which are burdened by >them, do not collect the fee for them. The fee is only collected by the miner >who puts them in a block, by his free market choice to do so. Fees exist to >discourage spam, not to compensate for the costs of the transaction. You pay $10 for a coffee. You pay and then they tell you that you can not have it because you are on a blacklist. Would it matter to you who got the $10? Or did you just pay for a service you did not get?
Have you think in renaming the flag to "vanilla"? That way, most people would still get the patches applies by default (as currently) but, as "vanilla" is more widely used and more "self-explanatory", people would more likely know that they are not running the "upstream" version :/
(In reply to Pacho Ramos from comment #31) > Have you think in renaming the flag to "vanilla"? That way, most people > would still get the patches applies by default (as currently) but, as > "vanilla" is more widely used and more "self-explanatory", people would more > likely know that they are not running the "upstream" version :/ The reason I opted to use "ljr" instead of "vanilla" was the hope that someday there will be multiple patchsets to choose from.
I guess we can rethink then about what to do when that unofficial patchsets are included (maybe some patches should be under "experimental" USE like the one used in gentoo-sources). Also, I guess that if more USE flags are used (and enabled by default) some people will prefer to be able to not apply all of them to follow upstream (via "vanilla" USE flag for example) to not need to disable each USE flag by separate
I think there is an issue here that is clearly misunderstood. Luke-Jr is not the main developer of the Core Bitcoin software which is the source of this. He is in fact a minor developer who happens to want people to think he is a main developer. He doesn't even appear to have merge privileges on the Core Bitcoin software on github. The main developers such as Sipa and Gavin have rejected these patches for quite some time now. Thus Luke-Jr is trying to get around this decision by the main developers who are rejecting these specific changes. Why are there people in gentoo who think they know better than the main Bitcoin architects? Take their decision to ignore these patches with the appropriate level of respect thanks and make them optional and off by default, as they should be.
This USE flag should be default-off. While I support the right of node operators to make their informated decisions about what transaction to relay or not, this isn't an informed decision - it's a backdoor attempt for Luke to enforce a policy that he's so far failed to get the greater community to agree with for the last two years. It's Luke-jr's opinion that gambling sites are an attack on the network, but his opinion is not the network consensus. Let the people who agree with him explicitly turn on this flag, and let everybody else get the upstream behavior.
This flag should be off, junk like this belongs in the bitcoin-overlay.
Document the useflag better or rename like I suggest below. There are legitimate reasons this should be enabled as Luke-Jr described, but I wish he wouldn't call it a DDOS. It is spam. If you don't like it, back the useflag out. Simple choice. And Gentoo is about choice. These patches were meant to be an enhancement and a deterrent to an ongoing problem of blockchain spam. The businesses in question were asked to play ball and to stop bloating the chain with small tx's, they decided not to when it was technically feasible to do it a better way. It's been a major issue and mainline took some steps to mitigate it indirectly, but most would agree it is not enough. Spam bloat continues: high network utilization and storage. Why not create a new useflag named "spam" and allow users to choose that? So they can continue to spam and screw things up for everyone else. Document that as well. I really fail to see any compelling arguments for WHY this shouldn't be default. The theme of this thread has already been "yeah it's a problem, but you're a nazi if you do anything about it". Miners haven't had an easy choice to enable these features, Gentoo is providing that out of the box. Adoption has been low because patching is required. The choice remains, it's just a lot easier now.
Joe, your comments are purely opinionated and not subjective or backed by numbers. Again, the lead architects of Bitcoin have repeatedly rejected these changes made by Luke. He is simply trying to get people to do what he wants by subversion - which is how he does things. They should be off by default, not on by default. Yes you get choice, choice to add options that even the lead architects of bitcoin consider inappropriate, if you want. Luke-Jr is the source of the earliest spam in the blockchain when he filled it with religious quotes. cd ~/.bitcoin/blocks strings -n 20 blk0000[0-6].dat and of course :) strings -n 20 blk0000[0-6].dat | grep -i luke
And your comment isn't opinionated? This entire bug report and the thread attached is an opinion forum that Anthony left the door open to while deciding. For numbers? Scale is entirely different on the text spam. Way to throw a red herring into the conversation. I ran the first command and had it dump the output into a file. Came up with 11K. Opening the file, about half is Luke's prayers, the rest are tributes, randomness, or things spamming him back. Meanwhile, here's a paper from last year that asserts that SatoshiDice alone accounted for around 60% of the transaction volume of the bitcoin network: http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf The blockchain is over 25GB at this point. It's safe to assume at least half of that is from parties this patch is attempting to blacklist. Or are you going to tell me otherwise? Distros make customizations all the time, this is nothing new and there's a ton of policy versions running about for bitcoin mainline and the other clients. Sipa was the only mainline dev that called this move dishonest, and only because there wasn't a notice before it was pushed default. Anthony has remedied that situation. In the future I'm hoping Gregory's suggestion to make the policy pluggable at runtime will be used. This would be more ideal if a "standard" algorithmic policy can't solve these problems. I think most of the devs are just shying away from a hardcoded bandaid until a better solution comes along. This actually does something now until that happens.
(In reply to Luke-Jr from comment #24) > Also a non-argument. The blockchain was created for financial transactions. > That doesn't mean it's acceptable or equivalent to use it for other purposes > such as spammy messaging, especially when such abuses make legitimate use > more difficult and/or costly. Basically you're saying that a personal email > from Joe to his friend is the same as a recurring unsolicited bulk > advertisement from a botnet to everyone in the world. This comparison you made breaks down pretty quickly: The blacklist portion of this patch doesn't block "just spam", it also blocks ANY bitcoin traffic (and even relaying messages) which are associated with the addresses on the blacklist, irrespective of the size, fee, or type of transactions, the packet rate, or any other considerations. Potentially a 100% false positive rate once the perceived ** spam problem stops. The equivalent would be more like a hypothetical patch to be enabled by default so that Gentoo's default iptables installation would blacklist and block all netblocks associated with any ISPs known to be associated with the grum botnet as of a few years ago (at the time, this hypothetical blacklisting decision could have stopped gentoo servers from interacting with the networks which were allegedly responsible for creating 18% of the world's email spam) My reason for a "straw man argument" on this extreme hypothetical example is that the blacklisting portion of this LJR patch doesn't inspect the transactions to tell if the traffic being blocked is spammy or not, it just blacklists all traffic to and from the targets 100% of the time, and with no way to unblacklist the targets other than recompiling without the patch, or recompiling with a newly written hardcoded blacklist patch. iptables blacklisting can at least be changed without a recompile O_O **: "perceived spam" because not everyone objects to the traffic, nor does everyone consider it to be abusive or spam. Just because a few people feel strongly about this type of usage doesn't justify a default policy of blocking any and all traffic to the hardcoded targets (the blocking occurs no matter what the fee, and no matter how big the transaction is)
There are ~15 active developers operating on the bitcoin core code. If the behavior Luke-JR is attempting to censor really was considered a threat to the networks health, then agreement would have been reached quite independently of the gentoo branch and this conversation simply wouldn't come up. There is no-one, yes no-one but Luke-JR in favor and allowing him to get away with this here simply diminishes gentoo. If you go down this route your going to have to start deciding which addresses/operations get censored and how are you planning to come to such a decision? Simply follow luke-Jr in his self appointed role? Take a vote? What about edge cases? Do you understand what censorship is? Get a grip.
There are three issues I have not seen anyone address. 1. False positives due to broad prefix matching 2. Patch is *punitive*, not mitigating. 3. Bitcoin network already has sufficient mitigation 1. This patch blocks address prefixes. This means it blocks addresses generated randomly by users, as well as specific vanity address prefixes. SatoshiDICE is not the only site that uses addresses starting with 1Dice[..]. For example, the cold storage address (aka: 1-2 transactions a week, no UXTO 'dust') of another Dice site also has a vanity address beginning with 1Dice[..]. Furthermore, a user may randomly generate an address that matches one of these prefixes. If there is widespread adoption of this patch, unlucky users who generated something that matches the hardcoded prefixes will see transactions to them not relayed, and therefore, not mined. As a currency, I believe such impact is unacceptable, *especially* as the default setting. This is like blocking all hidden service connections to /abcde.+\.onion/ ---- 2. Bitcoin Core already blocks UXTO dust by default. All SatoshiDice's transactions containing UXTO dust *is already considered non-standard*. This patch intends to *punish* certain address prefixes, instead of mitigating anything. Transactions with the matching prefix that do not include any UXTO dust would be normally accepted by Bitcoin core. This patch aims to punish those addresses. Such behavior should not be default. --- 3. Bitcoin Core is already effective in addressing 'transaction spam'. For example, take a look at this transaction: b30679bf3c688ad8f8b674a25c33399be23234934a488c04b8666f9486c1e5f3 It is 81kb in size. It was only relayed with a 0.082 BTC fee, paying over 0.001 BTC per KB. Bitcoin Core rules expect fees of 0.0001 BTC per KB, however it places limitations on other features that made this transaction non-standard. A custom miner has only accepted this TX for 10x the fees it would cost to send 81 one-kilobyte transactions (same size on Blockchain). There is no need for this patch. This patch has political motivations - not political in the sense of moral turpitude, but political in the sense of attitudes towards the Blockchain. --- Overall, there is no consensus for this patch. Luke-Jr has never demonstrated that this patch is *necessary*, as the default Bitcoin Core client rejects what is considered UXTO spam. This patch is purely political, and not mitigatory.
(In reply to Anthony Basile from comment #19) > After having spoken with some people here's what I've come up with > > 1) Sitoshi Dice's practice of creating transactions that never get spent > does add cruft to the UTXO and affects the future efficiency of all bitcoin > nodes. While not a DoS, it does negatively impact the community. > > Luke-jr's patch addresses this technical issue. I'm sorry, but this is false, and shows that you don't understand how Bitcoin works. The blacklist will not prevent the "cruft" from getting added to the blockchain. If the client attempted to block it from being included on the blockchain level, it would no longer be able to participate in the Bitcoin network since the hashes would no longer be correct. What it does do is prevent anyone with a client that includes this flawed blacklist from sending BTC to any of the gambling sites that have been arbitrarily added (and there are more than SatoshiDice), as well as from seeing any results until after it has been included in the blockchain. It has no effect in preventing a DoS, so the addition appears to have other (possibly religious) motives. It would be similar to hard-coding Firefox to block gambling or adult sites, or making Apache automatically drop connections from China. A patch like that would never be accepted, and neither should this.
OK, so, currently we are in the situation where both Anthony and Lukejr are holding the position that it is both the place and obligation of Gentoo to defacto police usage of bitcoind for users. As it stands, I see two fundamental problems with what is going on: 1. The patch is added by default and requires user intervention to disable. 2. The USEflag is named after the creator rather than what it does. It strikes me as perhaps deliberately disingenuous that you chose to name the flag "ljr" rather than "blacklist" or at least something that makes it clear what will be different and to then make the USE flag be enabled by default. Whether or not there are any technical merits to inserting your blacklist is irrelevant because it should not be the position of a Linux distribution to impose such things in the first place. Given the significant political and moral implications of this patch, due process would be to bring it before the entire council rather than Anthony making a unilateral decision as this will set a very significant precedent going forward.
Community relations bug about this bug: https://bugs.gentoo.org/show_bug.cgi?id=524600
Deploying the 'ljr' USE flag to Gentoo as a default quietly was wrong, and has been disabled, as well as splitting the spam filtering off to an independent 'ljr-antispam' USE flag so the rest of my patch is not tied to it. Currently, these changes are only available in the “bitcoin” overlay, but should make it to the main Portage tree within a few days. When I deployed the patch as part of the 0.9.3 ebuild for Gentoo, it did not occur to me at the time that the spam filter was even included, much less that it would be controversial. For some reason, I assumed everyone already knew what was included in my patch (ironic, considering I obviously forgot that part myself) and would see the new USE flag when upgrading. When it was pointed out, I should have just taken the more conservative approach and flipped it off by default. I should have known better (I did make the patch after all), and so I apologise for my lack of prudence. While I still believe the full patch is the best solution for users today (I have been using it for years myself), I recognise that it should not be enabled without ensuring everyone receiving it is well-aware. What I should have done, in hindsight, was at the very least have a pre-installation notice informing users of the patch and a link to more details on what exactly is included in it and what those changes mean. I will put more effort into ensuring future patches are clearly disclosed upfront. Over the long term, my hope is to see a BITCOIN_NODE_POLICY variable that can be specified as “ljr”, “vanilla”, or hopefully many other policies to match people’s many different preference in how their own system’s resources are used. If there are any further concerns or suggestions, please don't hesitate to contact me. Luke
> It strikes me as perhaps deliberately disingenuous that you chose to name the flag "ljr" rather than "blacklist" or at least something that makes it clear what will be different and to then make the USE flag be enabled by default. I share this opinion, but it is furthermore worth to mention that "ljr" goes far beyond blacklisting of certain transactions with specific properties, but it mixes several responsibilities. This includes to my understanding: - no relaying of any bare multisig transaction - relaying of non-standard transactions - temporary storage of appearingly parent-less transactions - changes of transaction prioritisation - GUI modifications - introduction of uncommon units of measurements ("Bong-Bitcoins (1,0000 tonal)") - blacklisting of transactions with certain properties based on a hardcoded list Furthermore I believe help messages do not reflect actual behavior and are sort of misleading, e.g.: + strUsage += " -permitbaremultisig " + _("Relay non-P2SH multisig (default: 1)") + "\n"; + strUsage += " -permitbaremultisig " + _("Relay non-P2SH multisig (default: 0)") + "\n"; Each of those options and modifications are debatable on it's own and I like some, but I don't like others. I would welcome, if this modification is broken down into several parts and the default behavior of the Bitcoin Core client is mirrored and not altered - unless a user explicitly decides to do otherwise.
> While I still believe the full patch is the best solution for users today (I > have been using it for years myself), I recognise that it should not be > enabled without ensuring everyone receiving it is well-aware. What I should > have done, in hindsight, was at the very least have a pre-installation > notice informing users of the patch and a link to more details on what > exactly is included in it and what those changes mean. I will put more > effort into ensuring future patches are clearly disclosed upfront. It's something of a moot point and relatively obvious given that you are said author of the patch. If you truly believe that it is "the best solution for users today" then you should be focusing your efforts on getting it into upstream, not using Gentoo as a refuge for pushing your agenda because you know full well that upstream will reject it at best and lambast you at worst. > Over the long term, my hope is to see a BITCOIN_NODE_POLICY variable that > can be specified as “ljr”, “vanilla”, or hopefully many other policies to > match people’s many different preference in how their own system’s resources > are used. making it more granular is fine, but I still strongly disagree with using "ljr" as the flag name as it conveys absolutely no meaning to users. These changes should be disabled by default. There are additionally plenty of people who provision Gentoo systems in ways other than interacting directly with emerge. Bottom line: Any user emerging bitcoind will ostensibly expect it to have the same functionality as upstream. These patches markedly change the behaviour of the software in a way that is highly controversial. It should not be enabled by default and if this is still a topic of debate it should be brought before the Gentoo Council to give the matter its due process.
As an update to my previous comment - I just saw that you have indeed made good on removing it as a default in the bitcoin overlay. I look forward to seeing the change in mainline portage.
(In reply to Joe Kappus from comment #39) > Meanwhile, here's a paper from last year that asserts that SatoshiDice alone > accounted for around 60% of the transaction volume of the bitcoin network: > http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf > Thanks for the reference. Section 5.1 is most relevant and fits my understanding of what's going on here. While it was not the purpose of that paper to unearth spamming, its method of characterizing payments does expose the problem with Satoshi Dice's practice. This is a clear weakness in Bitcoins and does not have a good solution. Blacklisting (Luke-jr's patch) is imperfect but at least has the correct intentions, much like spam filters in email. Luke-jr has decided to turn off his patch by default. I have respected his wishes pushed the changes to the tree, despite the fact that I hold the contrary opinion. I'll leave this bug open for more discussion, but I question the wisdom of doing so. Those who resorted to ad hominems above ought to be ashamed of themselves. They are not allowing this bug to be an intelligent response and so do the bitcoin community a great diservice. We are not upstream, but it does not mean that we can't contribute a better solution. If the ad hominems continue, or the discussion doesn't center on a technical issues, I will close/lock this bug.
Hi Anthony Basile! (sorry for my non-native English) > This is a clear weakness in Bitcoins and does not have a good solution. > Blacklisting (Luke-jr's patch) is imperfect but at least has the correct > intentions, much like spam filters in email. It is no consensus that this is a weakness of Bitcoin, and very different from email spam filters, blacklists make bitcoin totally worthless and must keep away from Bitcoin. I have no doubt that the intention was good, but remember this rule: keep blacklists away from Bitcoin! It is a core rule. I love Gentoo, and I love Bitcoin, I was very sad when I woke up and see this big mistake here. Blacklists are in general very controversial and is very dangerous to Bitcoin. See this thread for example: https://bitcointalk.org/index.php?topic=333824.msg3581480#msg3581480 A hardcoded blacklist affects the decentralization and the fungibility of Bitcoin.
Use flag 1stclassmsg depends on ljr so ljr cann't be simply disabled.
(In reply to Oleg from comment #52) > Use flag 1stclassmsg depends on ljr so ljr cann't be simply disabled. 1stclassmsg is not supported by vanilla Bitcoin-Qt, so yes, that's inherently necessary... 1stclassmsg is also not enabled by default, so just turn it off if you don't want it.
(In reply to Luke-Jr from comment #53) > (In reply to Oleg from comment #52) > > Use flag 1stclassmsg depends on ljr so ljr cann't be simply disabled. > > 1stclassmsg is not supported by vanilla Bitcoin-Qt, so yes, that's > inherently necessary... Let's not confuse the issue by using terms like "inherently necessary" (or any other type of necessary) ... It's not [necessary]. There's no reason this should have been added as a monolithic patchset in the first place. Please split off the individual use flags to their own self-contained patches, that way nobody runs the risk of accidentally pulling in patch X, Y, and Z-nospam just because they opted for USE flag Z. Just an example I found worrisome in the newly pushed version of the bitcoin 0.9.3 ebuild: Upon auditing the difference between the ljr and ljr-nospam USE flags, it appears that the way it was implemented is to just use the original monolithic patch, and then apply second patch to break the test conditions for blacklisting by always injecting "return false" in the middle of the original blacklisting code (the code which gets compiled still has the blacklisting code, as it's had the flow control broken rather than the code being omitted altogether) I actually had trouble confirming the program flow of this "ljr-nospam" patch without having to use a debugger, so I can't say for sure if the blacklisting is actually disabled or if it's just the code responsible for emitting a log message that a transaction has been blocked. Please, someone who has time to use a debugger, please trace the execution on this, or try to do a better job at auditing the code from the new patch(es) Reference: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/bitcoin-qt/files/0.9.x-ljr_noblacklist.patch?content-type=text%2Fplain&revision=1.1
(In reply to Sarah White from comment #54) > Please, someone who has time to use a debugger, please trace the execution > on this, or try to do a better job at auditing the code from the new > patch(es) ^ I left a couple words out. It should have read: [...] please trace the execution on this, or try to do a better job [than me] at auditing [...] I hadn't intended to imply that someone should be auditing this other than me, or that they did a poor job. I only meant that my own efforts were probably inadequate, and that someone should try to do a better job [than me] at auditing this code.
(In reply to Sarah White from comment #55) > (In reply to Sarah White from comment #54) > > Please, someone who has time to use a debugger, please trace the execution > > on this, or try to do a better job at auditing the code from the new > > patch(es) > > ^ I left a couple words out. It should have read: > > [...] please trace the execution on this, or try to do a better job [than > me] at auditing [...] > > I hadn't intended to imply that someone should be auditing this other than > me, or that they did a poor job. > > I only meant that my own efforts were probably inadequate, and that someone > should try to do a better job [than me] at auditing this code. Please produce an alternative patch.
Created attachment 386536 [details] [obsolete] an alternative to the gentoo "bitcoind-0.9.3 which includes the LJR patch(es)" ebuild
Created attachment 386538 [details] [FIXED] bitcoind-0.9.3 which does not include LJR patch(es) Accidentally left the src_prepare section with the handler logic for the LJR USE flag. This version is completely fixed.
Created attachment 386544 [details] Verified attachment 386538 [details] as a working ebuild by adding it to my local overlay and emerging bitcoind I just tested the ebuild in attachment 386538 [details], and confirmed ... this is bugfix works for bug #524512 as originally described: > net-p2p/bitcoind and net-p2p/bitcoin-qt enables ljr use flag by default, breaks bitcoin The usual gentoo-provided default for bitcoin.conf / bitcoind.logrotate, etc. etc. etc. Those all still work attachment 386538 [details] requires 0.9.0-sys_leveldb.patch which is the same as the one used in: > # Copyright 2010-2014 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: /var/cvsroot/gentoo-x86/net-p2p/bitcoind/bitcoind-0.9.2.1.ebuild,v 1.4 2014/08/29 00:46:19 blueness Exp $ and was also used by: > # Copyright 2010-2014 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: /var/cvsroot/gentoo-x86/net-p2p/bitcoind/bitcoind-0.9.3.ebuild,v 1.2 2014/10/10 11:37:31 blueness Exp $ Only substantial change is that I've elected to ommiti bitcoin-0.9.3.ljr20141002.patch.xz entirely (my version doesn't fetch or use any of that code, neither by default nor otherwise) Probably an identical result as forward-porting the bitcoind-0.9.2.1.ebuild for the 0.9.3 version bump
(In reply to Anthony Basile from comment #56) > (In reply to Sarah White from comment #55) > > (In reply to Sarah White from comment #54) > > > Please, someone who has time to use a debugger, please trace the execution > > > on this, or try to do a better job at auditing the code from the new > > > patch(es) > > > > ^ I left a couple words out. It should have read: > > > > [...] please trace the execution on this, or try to do a better job [than > > me] at auditing [...] > > > > I hadn't intended to imply that someone should be auditing this other than > > me, or that they did a poor job. > > > > I only meant that my own efforts were probably inadequate, and that someone > > should try to do a better job [than me] at auditing this code. > > Please produce an alternative patch. As a compromise, I produced a new ebuild which only includes well-audited, known working code, minus any optional patches (and the easiest way to accomplish this was to follow upstream as closely as previous the versions) In doing so, please don't take this to mean that I'm making a judgement call about anything in the patches being contentious / political / undesirable, widely supported, major improvement, good, bad, or otherwise... Partly, the reason for this is: "This is what I had time for" -- I don't have time to audit a monolithic patchset which is this complicated, and which does so many different things that it requires other patches to be able to manipulate and disable portions of the code, and then confirm it all works as intended or expected. I really agree with the original statement: (In reply to xiando from comment #0) > The official bitcoind and bitcoin-qt in Gentoo enables patches which breaks Bitcoin by default. Please disable the ljr patches by default or preferably all together. The language "breaks bitcoin" is key here, and I'm inclined to agree with xiando in that the introduction of code which makes major changes to this expected behavior is a "broken" implementation. It's a common enough expectation that bitcoin users think they're getting a content-agnostic, blind approach to relaying, forwarding, and including transactions in the blockchain. Let's not fork this behavior, yet attempt to still call it "bitcoind" or "bitcoin-qt" as though it's equivalent: (In reply to Sarah White from comment #8) > quote from mike hearn of the bitcoin foundation: > > [11:48:36] <hearn> we all use our computers for things ;) people who don't > use linux still manage to be productive. anyway, i have no idea what that > ebuild will do, but the fact that it's making such changes by default > suggests it'd be better to stay away from it entirely. if they want to > distribute a bitcoind with patches like luke's (which change behaviour in > quite some fundamental ways) then they should do a proper upstream fork with > a new name, so > [11:48:36] <hearn> you are always sure what you're getting. > > ^ Source -- > http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/05#l1412509714
(In reply to Sarah White from comment #58) > Created attachment 386538 [details] > [FIXED] bitcoind-0.9.3 which does not include LJR patch(es) > > Accidentally left the src_prepare section with the handler logic for the LJR > USE flag. This version is completely fixed. Luke-jr, comment on these patches?
(In reply to Anthony Basile from comment #61) > (In reply to Sarah White from comment #58) > > Created attachment 386538 [details] > > [FIXED] bitcoind-0.9.3 which does not include LJR patch(es) > > > > Accidentally left the src_prepare section with the handler logic for the LJR > > USE flag. This version is completely fixed. > > Luke-jr, comment on these patches? Um never mind. This is not a patch to the ebuild, it is an entire ebuild. 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.
(In reply to Anthony Basile from comment #56) > (In reply to Sarah White from comment #55) > > (In reply to Sarah White from comment #54) > > > Please, someone who has time to use a debugger, please trace the execution > > > on this, or try to do a better job at auditing the code from the new > > > patch(es) > > > > ^ I left a couple words out. It should have read: > > > > [...] please trace the execution on this, or try to do a better job [than > > me] at auditing [...] > > > > I hadn't intended to imply that someone should be auditing this other than > > me, or that they did a poor job. > > > > I only meant that my own efforts were probably inadequate, and that someone > > should try to do a better job [than me] at auditing this code. > > Please produce an alternative patch. This is not intended to reopen the bug. ... but rather, to make it easier for anyone who intends to use any portion of the monolithic LJR patch, and wants to know what it does (or alternatively, anyone who wants to reverse engineer the behavior for other purposes) https://github.com/luke-jr/bitcoin/compare/bitcoin:0.9.3...0.9.x-ljr?diff=unified Luke has confirmed that this is most likely the entire commit history for the LJR patchset [paraphrased]. Exact quote / reference: https://bitcointalk.org/index.php?topic=816578.msg9182915#msg9182915 << message 15: > That should be identical to it.
I think there are a few things to talk about. IMO: * it seems there is some confusion about what "upstream" is in this case * when we apply 3rd-party patches from users, we should review them * gentoo should strive to keep downstream hackery to a minimum and work close with upstream * I'd expect the USE flag to be called 'vanilla' too which makes it obvious that there are some 3rd party patches applied that change RUNTIME behavior. That's sort of standard.
Call for review by interested parties... Bug 531634
