| Summary: | net-p2p/bitcoind (and related): 0.10 preparation | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Luke-Jr <luke-jr+gentoobugs> |
| Component: | Current packages | Assignee: | Luke-Jr <luke-jr+gentoobugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | blueness, flow, pacho, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Luke-Jr
2014-12-04 10:17:11 UTC
This proposed ebuild has a default setting of non-vanilla patches. I don't understand --- Non-vanilla patches being enabled by default was the reason bug #524512 was created in the first place. Specifically, this ebuild is renaming the ljr flag to "extras". I think we should rename the flag back to ljr so people know it's related to the same code as before. Brief comment on the new "policy variables" --- It's not defined by the original bitcoin whitepaper by satoshi nakamoto, and neither is this idea of what you're calling spam as it's defined and censored by these patches. Sarah White, as a reminder, the original report of bug #524512 was invalid, and the defaults were changed only due to lack of sufficient documentation until that is resolved, which this version intends to do. I changed "ljr" to "extras" to match what is common in other ebuilds, but I'm not opposed to renaming it back to "ljr" if that is desirable in general. Keep the flag named "ljr" so it's easily identifiable, or rename it but keep it disabled by default. By renaming it and changing its default value, you're forcing all users who already set "-ljr" for this package in package.use to make a configuration change just to keep the same behavior. What hasufell said in https://bugs.gentoo.org/show_bug.cgi?id=524512#c64: Create a 'vanilla' use flag that is enabled per default, and only add non-vanilla/upstream patches if it's disabled. That is what I would expect from Gentoo and nothing else (Not sure if there is even a policy about this). There is also no need to rename the 'ljr' use flag to 'extras'. One could be tempted think that it's an fishy attempt to re-enable the patches on hosts that have "USE=-ljr". Also if use extras; then einfo "Extra functionality improvements to Bitcoin Core are enabled." fi sounds like a commercial advertisement for those modifications, but it does not explain *what* is actually changed. If an einfo is really deemed necessary, then please explain the behavioral changes: if use ljr; then einfo "Bitcoin will be built with Luke Dashirs patches, which filter certain transactions, <do this and do that>" einfo "You can read more about it at http://url.for.more.info" fi (In reply to Florian Schmaus from comment #4) > There is also no need to rename the 'ljr' use flag to 'extras'. One could be > tempted think that it's an fishy attempt to re-enable the patches on hosts > that have "USE=-ljr". Agreed, I plan to change this back already. (no need to further comment in favour of it, unless someone else shows up arguing for "extras") > Also > > if use extras; then > einfo "Extra functionality improvements to Bitcoin Core are enabled." > fi > > sounds like a commercial advertisement for those modifications, but it does > not explain *what* is actually changed. If an einfo is really deemed > necessary, then please explain the behavioral changes: > > if use ljr; then > einfo "Bitcoin will be built with Luke Dashirs patches, which filter > certain transactions, <do this and do that>" > einfo "You can read more about it at http://url.for.more.info" > fi Please read the whole ebuild... only a few lines lower (after the policy-specific) explanations, there is an unconditional: einfo "For more information, see ${LJR_PATCH_DESC}" It would be nice to explain in the description which are the real implications with this patch. For example (just an example!): it will prevent the user to use services listed on spam filter list, like SatoshiDICE, Mastercoin etc. (It is unclear how these services are impacted) but in counterpart the client will consume less memory and less CPU, also relieving the Bitcoin network. I've bumped the bitcoincore-0.10.x branch of the overlay: - USE=extras has been renamed back to USE=ljr - USE=ljr now includes many more enhancements than the previous draft. - USE=zeromq has been added as an additional-but-separate patch. - USE=1stclassmsg (only applicable to bitcoin-qt, not updated yet) can be easily split from the main patch and therefore will no longer require USE=ljr. - BITCOIN_POLICY=dcmp has been added to apply Peter Todd's "data carrier multiple-push" policy. - libsecp256k1's git is no longer API compatible with Bitcoin Core 0.10, so a snapshot has been added. (In reply to Felipe Micaroni Lalli from comment #6) > It would be nice to explain in the description which are the real > implications with this patch. For example (just an example!): it will > prevent the user to use services listed on spam filter list, like > SatoshiDICE, Mastercoin etc. (It is unclear how these services are impacted) > but in counterpart the client will consume less memory and less CPU, also > relieving the Bitcoin network. Elaborated a bit on this in the einfo, please review. Is LJR going to be enabled or disabled by default? (In reply to arichnad from comment #8) > Is LJR going to be enabled or disabled by default? Most likely enabled. > Most likely enabled. I am strongly against this move. bitcoin-0.10_pre20141217.spamfilter-20141217.patch is problematic. To enable it by default is a controversial move: filtering these transactions goes against the desires of the community and goes against the desires of the upstream developers (I hate to speak for others but I believe this to be true based on many conversations I've read on the matter). Filtering addresses like this is analogous to freezing a bank account. Running nodes that have this patch will prevent transactions that are sent to any address that begins with f0dd368c. You can see that this prefix is used regularly by hundreds of users around the world: https://blockchain.info/address/1NxaBCFQwejSZbQfWcYNwgqML5wWoE3rK4 Luke-Jr uses language that would suggest these are noncontroversial changes: "Notorious spammers will not be assisted by your node. This may impact your ability to use some spammy services". I disagree with his assessment of what the patch actually does. Please don't write me off: this is not a minor change to the codebase. Saying that you can disable this feature is nonsense, defaulting it to enabled is a problem. If it's so easy to turn off, why not default it to disabled, and then enable it if that is what you desire. (In reply to arichnad from comment #10) > Filtering addresses like this is analogous to freezing a bank account. No, it isn't. Addresses are single-use tokens/invoices for payments. The filter only affects spam. A good analogy would be like SpamAssassin uses RBLs. > Running nodes that have this patch will prevent transactions that are sent to any address > that begins with f0dd368c. You can see that this prefix is used regularly > by hundreds of users around the world: > https://blockchain.info/address/1NxaBCFQwejSZbQfWcYNwgqML5wWoE3rK4 No, this address is only misused by spam. While it's possible for the prefix to match legitimate use, the probability of that is far less than any other spam filter's false positives, including the one built-in to the mainline code. > Luke-Jr uses language that would suggest these are noncontroversial changes: > "Notorious spammers will not be assisted by your node. This may impact your > ability to use some spammy services". I disagree with his assessment of > what the patch actually does. Your disagreement appears to be entirely because you don't understand how Bitcoin works. I would suggest studying that if you want to understand it better. A good resource is https://bitcoin.org/en/developer-documentation Note that blockchain.info is almost entirely misinformation, and thus a terrible resource if you want to learn about Bitcoin. (In reply to Luke-Jr from comment #11) I disagree with almost everything you have said. Addresses don't have to be single-use, the filter does not only affect spam, bitcoin-0.10_pre20141217.spamfilter-20141217.patch is nothing like an RBL, the address you refer to is not only misused by spam, blockchain.info/address is not almost entirely misinformation, and my disagreement has nothing to do with my understanding of Bitcoin. Despite all of this, you failed to respond to my thesis: that this is a controversial change against consensus of pretty much everybody and should not be default enabled. I'll let others reply though, I don't want you to think I'm the only dissenting voice. This patch should not be enabled by default. Only optionally enabled. This same issue was brought up https://bugs.gentoo.org/show_bug.cgi?id=524512 a few months ago, and the overwhelming majority did not support enabling this patch by default. Nothing has changed since then. Infact, Luke-jr has added more addresses and transaction types to his personal blacklist. Bitcoin Core developers/maintainers do not support blacklisting addresses, which is why this patch was never added to upstream code. Luke-jr's motivations to enable this patch are purely based on his own minority views. Some further reading: The 150,000 strong Bitcoin reddit community overwhelmingly made their opinion clear that they don't want this: https://www.reddit.com/r/Bitcoin/comments/2ityg2/warning_bitcoin_address_blacklists_have_been/ Luke-jr's apology last time he forced this patch by default: https://www.reddit.com/r/Bitcoin/comments/2iuf4s/lukejrs_public_apology_for_poor_gentoo_packaging/ And this is the community's response to his recent attempts to do it again: https://www.reddit.com/r/Bitcoin/comments/2pfgjg/exposed_lukejr_plans_on_forcing_blacklists_on_all/ To summarize: - The 150,000 strong Bitcoin community does not want this patch enabled by default - A majority of Gentoo users do not want this patch enabled by default (see https://bugs.gentoo.org/show_bug.cgi?id=524512) - The Bitcoin core developers do not support address blacklisting, which is exactly what this patch does The overwhemling opinion of the community is that this patch cripples bitcoind rather then 'enhances' it. Given that the community has spoken and does not want this patch, it makes no sense to enable it by default. Optional, sure. Default, no. I'd suggest keeping the flag but not enabling it by default. I also don't think using somebody's initials as the flag name makes sense - name it based on what it does. Getting offtopic a bit, if somebody doesn't like tons of little transactions shouldn't they just configure their miner with a minimum transaction fee before they'll accept them? That would seem like the simplest solution to prevent spam, and I can't see what incentive a miner has to include a transaction without a fee anyway. (In reply to Richard Freeman from comment #14) > I also don't think using somebody's initials as the flag name makes sense - name it based on what it does. Yes, I agree - but keeping it the same as previous versions used seems more important for now. > Getting offtopic a bit, if somebody doesn't like tons of little transactions > shouldn't they just configure their miner with a minimum transaction fee > before they'll accept them? That would seem like the simplest solution to > prevent spam, and I can't see what incentive a miner has to include a > transaction without a fee anyway. Many people want to process gratis transactions for the good of Bitcoin and/or to help adoption. The effect of a minimum fee too high for spammers, is the same as the spam-specific filter anyway (for the spammers). 0.10.0 has hit the main tree, so this is resolved. Please open a new bug for any technical problems, or contact me directly if you have other reasonable concerns. |
