Alternative implementations such as Bitcoin Classic and Unlimited disrupt the network nodes, please refrain from recommending it. Also, bitcoin.com is a commercial/gambling site, we don't want to recommend this either.
Also, r/bitcoin and bitcointalk are much more popular/older than r/btc, we don't want to split the network as has been suggested by the recent pages to this page. -- Diegoviola (talk) 13:03, 29 December 2016 (UTC)
- "Disrupt the network" and "split the network"? No, that can't be right. Can you source your statements? Those clients are well established and have been operating for a long time. Some many years. I have never seen a bugreport about disruptions or splitting the network. In my opinion we there is no reason for arch to prefer one implementation of a protocol over another. Tommy5 (talk) 13:38, 29 December 2016 (UTC)
- I actually know what testnet is and it forks all the time. Its specifically meant to not be stable (hence the name). Its like a virtual machine you install packages in. This is a silly example from a brand new account which makes me think this is political, not technical. I hope Arch can stay out of politics and just provide the software people want. Tommy5 (talk) 14:06, 29 December 2016 (UTC)
- I created this account only now because I didn't need to contribute to the wiki before, but I'm a bitcoin developer (you're welcome to look at my github). The testnet splitting for months without being noticed by the Bitcoin Unlimited developers does not build good confidence in that implementation. Any kind of hard fork attempt can result in a split cryptocurrency unless _everyone_ agrees: controversial hard forks _cannot_ happen. We saw the damage a hard fork attempt did to Ethereum and don't want to repeat it with Bitcoin. A hard fork can be understood as creating a new cryptocurrency and trying to get ever old user to move to it. That's why Bitcoin Unlimited and Bitcoin Classic are alternate currencies and don't belong on the Bitcoin wiki page, despite their intentionally misleading names (Bitcoin "Classic"? It insults the intelligence) Belcher (talk) 14:20, 29 December 2016 (UTC)
- This will be my ONLY comment to this regard and dealing with this subject matter, as again this should be a place for purely technical matters. The only reason I am posting this is to have a visible account of the other side of this <-- this is a record of documented censorship from the other "side" of this debate. Again, this is being posted simply to provide a balanced account of something someone else interjected. NONE of these matters, which do not in any way relate to the objective technicals of Bitcoin, have any place here on this wiki, especially not as an influencer of how to structure the content on this wiki(which again, should be _purely technical_) Thehindmost (talk) 21:41, 29 December 2016 (UTC)
- In the same way we dont have Litecoin, Goldcoin or Trumpcoin on the Bitcoin page, we don't have Bitcoin "Classic" or Bitcoin Unlimited. Just because they pretend to be bitcoin doesn't make it so. reddit.com/r/bitcoin is just one community out of many and has nothing to do with the Bitcoin software project (which mostly takes place on IRC, github and the mailing list). Since this poster hasn't replied to any of my objections about splitting the currency and hard forks I recommend the altcoin clients be kept away from the bitcoin wiki page. Belcher (talk) 15:03, 29 December 2016 (UTC)
- So you say that linking to a AUR of Classic is not possible because Classic is not Bitcoin, just like GoldCoin is not Bitcoin? The website shows differently, though. How do you reconcile that? Also, I did respond to your accusation of disrupting Bitcoin by concluding it a political point, not a technical point that has any bugreports or similar documentation. And since Arch users actually want the package, reverting the changes which link to software you clearly feel threatened by, that is censorship. You are very new here, less than a day old account, so please read the Code of conduct pages. What do you base your idea on that ArchLinux should restrict its users on what software to run? Tommy5 (talk) 15:41, 29 December 2016 (UTC)
- Tommy: End of story, an alternate implementation, REGARDLESS of whether it attempts to implement different consensus rules, is DANGEROUS for the user of it. Period. Satoshi's words himself on the matter: “I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.” Thehindmost (talk) 19:18, 29 December 2016 (UTC)
- That quote, however meaningless it is without a supportive link, merely suggests that alternative implementations may pose danger for the network and not for the user as you claim in your first sentence. Either way, we assume that Arch users are adults so we shouldn't keep this away from them like drugs from children. -- Lahwaacz (talk) 20:05, 29 December 2016 (UTC)
- I apologize if it was inappropriate formatting wise, I am usually just a reader and not editer here so I just made an account. I posted a proposal at the top of this thread with both a citation, line of reasoning, and a proposal for a solution. I apologize again if this was an inappropriate way to format my response. Thehindmost (talk) 20:07, 29 December 2016 (UTC)
- The fact of the matter is that Satoshi left many years ago and there is nobody in Bitcoin actually running his software anymore, so the argument he made has already been ignored. There are only non-original implementations of Bitcoin running today! And if you read the post from Gavin just two items below your link listed in "proposal" you will see he made the same point. The fact of the matter is that Bitcoin was created such that nobody has control over it. Similarly, attempts to limit what software people can run on their own computers runs counter to open source and I think most will agree that it also goes against Arch Linux values. Tommy5 (talk) 20:55, 29 December 2016 (UTC)
- I think this discussion is not at all relevant for Archlinux, but I'd like to chime in anyway. One legitimate reason for not wanting competing implementations is that the standard gets a lot more difficult to improve when there is a big ecosystem of different implementations that needs to be upgraded; Satoshi clearly saw the need for the standard to evolve; he included a protocol version number in the transaction format (currently quite much stuck at one), and he clearly wrote that the 1 MB block size limit was temporary and should be lifted when/if needed. The anti-alternative-implementation-supporters also tend to be the anti-protocol-upgrade-supporters. It doesn't make sense. If we never should allow backwards-compatible changes to the protocol, then it would make sense to document the standard as a standard, rather than defining the bitcoin protocol to be "whatever bitcoin core implements it to be". Disagreements in software governance usually causes software forks, after a while quite often one software fork "wins" while the other gets abaondoned (i.e. xorg vs XFree86). In this case the supporters of the original branch is doing their very best to hide the fact that there exists forks. -- Tobixen (talk) 01:43, 30 December 2016 (UTC)
- This is completely non technical and entirely political nature. The social contract, or perceived social contract, as well as the intentions of a software maintainer have ZERO place here. Fact: Alterations to even the smallest thing such a how a piece of data such as a transaction or block is formatted can lead to a consensus failure and a bifurcation of the network based on which clients accept such alterations and which do not. This can happen regardless of whether it was intentional, a bug, or whatever the cause. _DO NOT BRING POLITICKING ABOUT WHAT BITCOIN IS, SHOULD BE, OR WHAT SOME AUTHORITY FIGURE SAID_ here. This is a place for purely technical discussions, period. And it is a fact that every single fringe behavior, alteration, or bug that could lead to a consensus failure is impossible to completely encapsulate in a conventional technical standard. You are bringing your politics here, check them at the door like I have. Consensus, as I have documented twice here, is a factual thing that can be discussed solely in technical language and concepts. DO SO. Stop fragmenting this conversation all over under different topics as often happens in general purpose bitcoin forums. This is _NOT_ a general purpose forum, it is a technical wiki. Thehindmost (talk) 21:38, 30 December 2016 (UTC)
I'd like to chime in on this. I'm a long-term archlinux user (with one package in the AUR), though never edited on the wiki before - and I must admit I'm arriving here through Reddit. I'll sign each of my viewpoints below separately so that it's easy to see that they are mine even if there will be discussions between. -- Tobixen (talk) 01:18, 30 December 2016 (UTC)
- Thank you for the overview of the situation, though it seems you've left an unfinished sentence in the third paragraph below ("Software not adhering to the standards"). Perhaps you'd like to finish? -- Lahwaacz (talk) 08:39, 30 December 2016 (UTC)
Unfortunately the software selection has become a hot political question. The great scaling debate has unfortunately split the bitcoin community into two camps. Running one variant of the software rather than the other can implicitly be seen as giving a vote. The debate itself is of course completely irrelevant in this context, but I believe it is worth mentioning that users may want to look into both sides of the debate before choosing software. The moderation policies of the most prominent forums (r/bitcoin on reddit, bitcointalk.org, bitcoin.it, bitcoin.org - all of them more or less controlled by the same person) are causing quite much of a bias, this is a problem. Yes, many of the alternative forums are unfortunately also "ugly groupthink echochambers" - but judging one over the other ought to be irrelevant for this wiki. bitcoin.com is indeed owned by a commercial entity, and I have indeed bought some t-shirts from said site, but at least the ownership structure is completely transparent - the same cannot be said about bitcoin.org and bitcoin.it. While we should avoid information overload, I believe bitcoin core and the forums should not be "endorsed" like it is now without mentioning the alternatives - and I also believe the alternative forums should be mentioned. -- Tobixen (talk) 01:18, 30 December 2016 (UTC)
The network does in no way get disrupted merely by node-owners using alternative software, hence this is not a valid argument against mentioning alternative node software on this wiki. While nodes do serve an important role in the network, they are marginal actors in the consensus-building process. Software not adhering to the standards -- Tobixen (talk) 01:18, 30 December 2016 (UTC)
The user is in no way shooting himself in the foot by choosing alternative full-node software, so this is not a valid argument against mentioning alternative node software on this wiki. With the current status-quo, BU, classic, knots and bitcore works completely compatibly with Bitcoin Core (this is not unproven software, this is software that is used in production settings, today). If a big majority of miners and the industry as such were to upgrade to BU or classic and replace the current hard-coded 1MB block size limit with a new de-facto 2MB-block size limit, then BU and classic would just continue work - while Bitcoin Core-users would simply experience that "bitcoin stops working", hence for the ordinary user it could even be safer to choose classic/unlimited. -- Tobixen (talk) 01:18, 30 December 2016 (UTC)
There are non-political technical benefits of using BU and Classic, one does get some unique technical benefits of using BU/classic rather than core (i.e. Extreme Thinblocks slashing the bandwidth consumption with ~50%, systemd-support straight out of the package and more). -- Tobixen (talk) 01:46, 30 December 2016 (UTC)
https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 “I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.” -Satoshi Nakamoto. This is the words of the CREATOR of this project, regardless of whether you adhere to appeals to authority or not. There is a very sound technical reasoning for this, you arriving at the EXACT same results of other nodes in the network is INTEGRAL to your ability to safely guarantee and validate your receipt of money with a fully validated client(other users of non-fully validating clients proxy their guarantee to other people's fully validating clients, meaning this potential for loss extends outwards beyond the immediate user of a fully validating client). As has been previously demonstrated in Bitcoins history, the slightest bug or difference in results produced by a differing codebase can put your money at risk. I propose a second wiki page be created for Bitcoin alternative clients, with a link from the main page issuing a warning along the same lines as I have given above. I propose Bitcoin Core be kept as the only client on the main page, as both the reference client and client run by a clear majority of the entire network. On the alternative client page, all other implementations can be linked to, categorized by those that attempt to alter consensus rules(and how they intend to, both in terms of changes to rules and the mechanisms to accomplish such to make risks clear to users), and those that implement the same rules as Bitcoin Core.
In my mind, regardless of any other line of arguing(which can only be politically, and not purely technical in nature), this is a warning about a potential security issue. A security issue with software that does not manage just your information, but _your money_. After some thought this seems to be the only solution that will prevent this issue from devolving into a totally non technical, he-said she-said, argument which I believe would be a much more exaggerated violation of the Arch Philosophy of remaining objective, technical, and allowing users to make an informed decision on their own. Thehindmost (talk) 19:59, 29 December 2016 (UTC)
- We split topics into multiple pages if they become too long and cluttered on the one page. That is not the case of Bitcoin yet and a separate section on the same page would serve this purpose equally well. Is everybody OK with that?
- Then I think it would also make sense to move the List of applications#Bitcoin section here, as apparently wider context is necessary to choose the favourite client.
- -- Lahwaacz (talk) 20:30, 29 December 2016 (UTC)
- Sounds good to me. All I am mostly concerned with is the false perception being spread that these clients implement the exact same protocol and have the same core consensus codebase, which half of them do not. So long as the distinction of Core as the reference client and dominantly run client on the network, and the difference of consensus rules and client mechanisms are made clear so users are properly informed of the potential risks, my concerns are satisfied. This is just a highly politicized issue right now within the Bitcoin community and I would like to not see that spill over here. As long as the technical risks are made clear, it is fully within the spirit of Bitcoin as well Arch for users to be able to run whatever client they choose to. I simply want to ensure the potential risks to individuals is made clear and fully understood. And thank you for the help with formatting. Thehindmost (talk) 20:34, 29 December 2016 (UTC)
- Having more choice visible and available sounds good.
- The reverts of my edits also removed things like links from the 'further reading' section to forums that are not censored, naturally such a section needs to have a list of multiple off-site support groups so we don't end up sending all users to the one biased forum. I can understand Thehindmost's point about this being a "highly politicized issue" and we should reflect this in what we suggest our readers for further research. For instance 'bitcoin.org' doesn't acknowledges many alternatives like Classic.
- -- Tommy5 (talk) 20:55, 29 December 2016 (UTC)
- Your edit of the 'further reading' section unfortunately did not achieve what you say, but replaced the info (from *.org to *com addresses). A revert of that was clearly ok.
- I think it would be nice to wait a day or two whether there are any objections to Lahwaacz's proposal to simply create a separate Bitcoin#Classic section (e.g. Diegoviola's ok, as the main contributor to the article lately) and, in absence of major objections, go ahead with it. In order to limit exhaustive explanations of the different software projects, my suggestion is that you link to w:Bitcoin Core and w:Bitcoin Classic at the beginning of those individual sections (i.e. link them before the package names), that should suffice fully for our readership. --Indigo (talk) 09:08, 30 December 2016 (UTC)
- Fact is, whether you like it or not, that currently around 10% of the reachable fullnodes are running either classic, unlimited or xt (you can see at bitnodes.21.co). So they definitely have to be mentioned imho.
- Please don't bring the r/bitcoin censorship here, if you think those things are wrong fight it with information instead. For example a note that if miners start producing blocks that are not accepted by all nodes
- will lead to a blockchain fork is fine - just hiding stuff is not. thanks.
- -- Hotchiliz (talk) 00:48, 30 December 2016 (UTC)
- I don't think that the wiki page should be divided between fork vs nonfork. I believe that the bitcoin network consists of a bunch of nodes working together to achieve some goal. This goal is mutable and left up to the network. Any software that these nodes run can differ in specification or implementation (e.g. bitcoinj following the core specification). As such we should provide a list of relatively popular software, regardless if its the most popular specification or implementation, that was made with the intention of interacting with the nodes of the Bitcoin network. It should be left up to the user to research and decide the most suitable software to fit their needs. As for classifying forks as a security risk that is subjective in nature. The wiki page should be unbiased about it and let the user come to their own conclusion. Nullifer (talk) 12:43, 30 December 2016 (UTC)
- It is factually incorrect that classifying a fork as a security risk is subjective. If you are not in consensus with the majority of the network, you are not in communication with anyone in that majority to relay a transaction, to see the current state of balances on that majority's network, or able to participate in any economic way with that majority and their network. You are isolated on a partitioned network, with its own economic token(assuming a fork is not temporary in nature due to software malfunction, but an intentional permanent act), and its own set of economic actors you can interact with. It is FACTUALLY a matter of the security of users funds to be both aware of this, and informed enough to respond how they choose, whether it is remain on the network they are on, switch to the new one, or sell their tokens on one or both of the networks and wash their hands of cryptocurrency in general. Any changes in the codebase with consensus related objects can cause a consensus fail, half of these clients are designed to intentionally initiate a consensus failure to fork off and create a new network upon certain conditions being met with new consensus rules un-upgraded clients will not enforce, and the creation of separate networks duplicating the Bitcoin token is most definitely of relevance to the security of economic value the users of any clients have stored on the Bitcoin network in the Bitcoin token, as it WILL have an effect on how the markets value both tokens. Thehindmost (talk) 22:02, 30 December 2016 (UTC)
- I like your started edits and agree with your statement here. I would suggest we limit it to well maintained and actually packaged-for-archlinux versions of Bitcoin. Two comments. First 'SegWit' is not a software on its own. I don't think its relevant on the page. Second, You state you sort them alphabetically, which I think is great, but you sorted Core before Classic. Its the other way around :) Tommy5 (talk) 13:10, 30 December 2016 (UTC)
- I agree we limit it to well maintained repos on arch linux. I don't know much about the proposed soft and hard forks, which was kind of why I left it to other more knowledgable people to fill out. If segwit has no associated software on arch linux then feel free to remove it. Also yeah its really late here I guess I can't alphabetize properly (it really was a mistake, not on purpose) Nullifer (talk) 13:20, 30 December 2016 (UTC)
- Absolutely not. This is the exact type of thing I was talking about being started. So far this page is beyond innaccurate. There is absolutely NO WARNINGS WHATSOEVER of the risk of falling out of consensus. Whether this is acknowledged by you is irrelevant, it is a factual statement that falling out of consensus can put your money at risk. There is absolutely no acknowledgement of the consensus change mechanisms, and what is changed. There is only pretending that the vast differences in consensus rules means absolutely nothing to the user, and does not in anyway potentially put in motion things the user must monitor and be aware to maintain the safety of his money, ESPECIALLY in the event that a fork was triggered. Not to mention there is absolutely no distinction between fully validating client and non-validating. I will be HEAVILLY editing this. If something is done to revert I will be going to moderators. This is the exact opposite that was seemingly settled on with the Proposal below, and SPECIFICALLY ignores placing any warnings up for users. Peter Todd's RBF is not even a CLIENT!!!! It is a tool for replacing a transaction with a low fee!!!!! -- Thehindmost
- Talk about consensus is quite irrelevant here, all clients that are available in arch repos or aur actually follow the protocol rules. If they don't they will not connect to the Bitcoin network making this topic quite irrelevant to the user. Please keep that kind of details out of this page. Tommy5 (talk) 18:30, 30 December 2016 (UTC)
- That is factually incorrect. Period. Consensus is REQUIRED for the network to function as a whole allowing ALL users to transact with ALL other users, and a break in consensus is factually the same thing as a network partition that removes the ability of users to transact with any user outside of their partition. You are being disingenuous, and factually incorrect. Thehindmost (talk) 19:33, 30 December 2016 (UTC)
- The original talk item was resolved by adding alternative implementations, as well as more background Thehindmost and others contributed to the article. The remaining stub discussion above was followed up in the #Consensus changes discussion first, and then #Alternative Client Warnings, so this stub is unrequired now. Thanks everyone for the provided input. Should there be another particular point missed, please point to it separately.
- Closing item. --Indigo (talk) 17:23, 13 January 2017 (UTC)
Add/Move mining section to Bitcoin#Bitcoin Software
- Mining at this point is not something profitably done at a home level. To have any chance at all of being profitable, highly specialized hardware is required, all of which that I am aware of is shipped with custom firmware/software to operate without the requirement to connect to a computer as a control device. Also, at the end of the day mining does require a fullnode. Both software clients listed under the Mining section are incapable of mining independently, and are either pointed at a full node client, or a service operating one. Mining these days is a highly specialized thing, and either requires software outside the scope of this wikipedia's ability cover, or has no need of the software here. Those I think are appropriately placed for now. They are only compatible with CPU mining or very old USB miners, neither of which generate any profit whatsoever and are best where they are as a sort introductory thing to tinker with requiring no significant investments. If anything I think topically the software links in the section should be removed, as they are irrelevant where profitable mining is concerned, and the subject simple touched on topically as it is above the links and left at that. All the in depth specialization required to go into the specifics, strategies, software clients, etc. involved in being aggressively profitable as a miner is _WELL_ beyond the scope of this wiki. Thehindmost (talk) 02:36, 31 December 2016 (UTC)
- Yes, that sounds like a good idea. Thehindmost claims you get software shipped, which is false. Most home miners connect to a mining pool and they use open source software for that. So, my answer is, sure, provided that that software is actually packaged by Arch and is useful to home miners connecting to a professional mining pool. -- Tommy5 (talk) 12:17, 3 January 2017 (UTC)
- https://github.com/bitmaintech Bitmain's site advertising its ability to use out of box with loaded software. That is a completely factually incorrect statement. Bitmain's Antminer line, and Bitmain as far as I know being one of the only consumer facing producers of mining chips, ships their own firmware and version of CGminer integrated with the mining hardware. You are able to directly connect to the device's IP over a web interface, and out of the box with the shipped software point your miner at a mining pool. I speak not only from personal experience as a miner, but have linked the appropriate github. Thehindmost (talk) 23:29, 3 January 2017 (UTC)
- https://bitnodes.21.co/nodes/?q=/BTCC:0.13.1/ Here as well, is _factually_ 55 nodes ran by a single mining pool BTCC(BTC China). Factual refutements to both instances I have found so far of me being accusing of spreading falsehoods or lies. Thehindmost (talk) 20:17, 4 January 2017 (UTC)
- Bitcoin#Mining achieves a good compromise by linking external resources to help Arch users with know-how on this special subject. Since none of the contributors appears to use Arch packages for mining, the current scope is just fine for coverage.
- Closing item. --Indigo (talk) 17:33, 13 January 2017 (UTC)
Removals at "mods direction"
I'm sorry, who exactly "directed" all of these removals? The edits removed highly relevant explanations and warnings that were recently added as a result of the discussions above.
For the record, here on the ArchWiki the "mods" are these admins and maintainers, me and Indigo who involved in the discussions above are two of them. Note that none of us two made this private direction, and I seriously doubt that any admin or maintainer would do such a thing behind the huge discussions above. Since I also doubt that Thehindmost would decide to suddenly revert the entire day of their work by themselves, the alternative explanations are that either somebody is pretending to be a "mod" or somebody hacked Thehindmost's account. Or does anybody have some better explanation?
For the time being, I will revert the page to this revision. We can easily redo the removals when discussed properly and agreed.
- A discussion was had with jasonwryan on the archlinux-wiki IRC channel. He made clear it was his opinion all of the material I removed was non-relevant as it was not specific to Arch Linux or operating software specifically on Arch Linux. He made clear in his opinion the removed material had no place on this wiki, and made clear his opinion was that the entire page be removed from the wiki. My removals were made with the intent of reaching a compromise where some level of user warning was still maintained as opposed to having the page completely reverted to before my changes, or removed all together. Obviously I am much more content with the full content you have restored being displayed. I guess until the two of you have a chance to talk, I will let your reversion stand. I feel like I am a little unclear at this point who exactly has the final say on the content of the page. Thehindmost (talk) 09:26, 2 January 2017 (UTC)
- The gist of the argument is that the content is not directly related to Arch, and should be documented in a more appropriate location. Glancing over the Wikipedia article, I can't find a section on the "consensus" term; so wikipedia may be a suitable place which can then be linked from this article. However, any merging of the information in this article should be coordinated with the wikipedia editors. So my suggestion is doing exactly that and then we can see from there. -- Alad (talk) 21:45, 2 January 2017 (UTC)
- I have done some looking around the wiki, and must say that after my conversation I was under the impression I had been issued an ultimatum from Jason, either remove the content or the page will be summarily deleted. Having realized that is not black and white the case(?) I would like to reiterate the gist of the case I made with Jason. There are a number of instances all over this wikipedia where general purpose configuration or explanatory information is made for software which extends well beyond the sphere of compatibility issues with Arch specifically. i3, OpenVPN, and Tor all have relatively speaking extensive coverage of general issues of all Linux systems. Tor in specific expounds much in the nature I have on this page to make clear things necessary for safe use, compatibility with other software, etc. I am a little unclear right now why the argument being used to remove content I have added here is not equally as valid and equally applied to pages like this? If I am being honest I feel as if this is a pre-emptive action taken under the assumption of further controversy, which unless you are being harassed through private channels, I do not see taking place yet. I have seen no serious objection whatsoever from anyone since I have started making my additions and edits except from moderators making specific requests for clarity and proper formatting. All of those requests were immediately met, and all were fulfilled prior to my conversation with Jason. I am very unclear right now as to 1) how this issue will be settled with finality, and 2) why the argument being used to justify the removal of added content is being specifically applied in this instance. Especially when most of the content added was added because of a specific request from moderation to clarify issues. Thehindmost (talk) 23:03, 2 January 2017 (UTC)
- The only reason I'm mentioning this is to possibly bring the content you've added to a wider audience—as I'm sure there's not only (Arch) Linux users that use Bitcoin—as well as let all sides be heard on this discussion page. And like I said, it would only matter if this content actually fits into the w:Bitcoin article. -- Alad (talk) 00:25, 3 January 2017 (UTC)
- Yes, but I don't think that would work out, with w:Bitcoin being too long already and discussing a lot of the social effects which make it an irrelevant source for software installation. If you look way up in the discussion, you will see I suggested placing links to w:Bitcoin core, that has mentions of "consensus" in the w:Bitcoin Core#Version history for example, and w:Bitcoin Classic - which fails to have a singular warning about it being "potentially concensus incompatible" (just as the homepage of the project itself!). We can't place a warning with a link to what's not there. --Indigo (talk) 11:02, 3 January 2017 (UTC)
- I've noticed you reverted my changes. I only saw that after I committed my last change. No mid-flight collision notice. Sorry for confusion.
- Following your "its too long already" and my explanation here, I followed up with the action to counter the people that have had the aim to make unattracitve non-core clients. Why did you revert that? -- Tommy5 (talk) 11:18, 3 January 2017 (UTC)
- Issues I see with the new edits:
- I've undone these for now. I don't claim the revisions before it are perfect or universally agreeable, but with the above we're back to going in circles. Please only make changes as they are agreed on by all parties. However, if you believe that information is not accurate or not well presented, add Template:Accuracy or Template:Style to the sections in question.
- @Indigo: I agree the Bitcoin Classic/Core wikipedia links should be added to the article. -- Alad (talk) 14:25, 3 January 2017 (UTC)
- (1) How is it an ad? It follows the simple rules we established here, on this talk page, before; we sort the clients alphabetically and it removes the unproven and nonsense claim of how it may be dangerous. If you think this changes a lot, thats most likely because of the dozens of edits that made Classic look harmful somehow. Remember that it looked almost exactly like this before this edit war started.
- (2) Well, this isn't git. The Summary can only be so long. All I did was remove useless jargon like ECDSA. Is there anything controversial at all? Its but a simpler, but still 100% correct version.
- (3) This change you removed was nothing but a simplification. Again removing useless jargon. Do we really want to describe technical details on how the software does things? I'd argue that what matters is the difference between full node and thin clients. The Warning there was also completely out of place, a made up statement that at minimum needs sourcing.
- Your reverting of this makes no sense to me, I've seen various admins claim that the goal of this wiki is to assist users in choosing software, installing and configuring. All the edits you reverted were aimed at that goal. After your revert this page looks more like a wikipedia, authoritative (but not sourced) article. :( The page looks horrible right now with lots of lies that clearly make the Core client look good and the rest as cheap but not very good copies. Which is just insulting and its infuriating that even simple and non-contested edits get reverted.
- Tommy5 (talk) 15:24, 3 January 2017 (UTC)
- (1) The language you used for describing your favourite client was definitely inappropriate. But most importantly, the proposal added here, which seems to be currently being implemented, does not contain any clause on alphabetical order or removing explanation of risks. If you don't like that, please make a new proposal in a separate section below.
- (2) This is simple - what can't be described in a single edit summary should be split into multiple edits.
- (3) Same as (1), this goes against the #Proposal 1 without any prior discussion.
- -- Lahwaacz (talk) 17:37, 3 January 2017 (UTC)
- I'd like to update on status of our mod discussion:
- It is understood you (Thehindmost) were just proactive in good faith after your discussion with Jason (which lead to your edits, initial subject of this talk item). So, we had an exchange how to improve ArchWiki:IRC and the banner in the IRC channel to clarify IRC discussions are not meant to bypass wiki discussions. With that the initial topic of this item is clarified.
- Given that discussions for this article continued to be highly controversial in the new year, we initially identified four options how to proceed with this article. In the course, these were then condensed to two:
- Removing references to individual packages and related install instructions. This stems from the inability of contributors to agree on descriptions which are regarded neutral yet comprehensive to describe differences between packages.
- I have just implemented that. Our intent is to keep the generic information on Bitcoin and contributions to improve the article as is, of course, welcome. In particular we welcome reductions of content by referencing external technical resources accepted as neutral in the bitcoin community. Anyone wanting to propose bigger changes: it is best if you prepare a draft in your userpage at current (copy the part you want to edit and do your changes there), and reference it in the talk page, leaving enough time (a week?) for others to reply before you go forward. Perhaps, that is an acceptable way to channel into productive collaborative editing for this article. We do hope but cannot anticipate if it is. Please all be aware the last option we identified to revert to is:
- Remove or Template:Archive the article, both of which will replace it with a placeholder.
- Thanks. --Indigo (talk) 23:08, 17 January 2017 (UTC)
- I'd like to update on status of our mod discussion:
Alternative Client Warnings
I see that notations warning users about the complete removal of a blocksize by Bitcoin Unlimited and Bitcoin Classic have been removed? Why? This is a very serious implication of these clients that is important to understand. I thought the entire rationale behind implementing my proposal was for the purpose of user safety. Now I see two very important warnings removed. What was the logic in this? Where was this discussed? These are NOT general warnings about Consensus, they are specific to those clients and the specific alterations to Consensus they are making. Thehindmost (talk) 04:01, 11 January 2017 (UTC)
- As well, why am I not being emailed about page modifications anymore? I have this page watched, I have it set to mail me notifications, why are they not being sent? I see changes being made now contrary to the previously established statements by mods, and see no discussion about it. What is going on? Is there an out of band conversation happening I am not privy to? I was told discussions about these pages happened here, and decisions made were based on the discussions happened here. Thehindmost (talk) 01:47, 12 January 2017 (UTC)
- There hasn't been any modification since Jan 8, which is what you complained about in the previous post, so I don't see the problem. As for email notifications, they are skipped until you visit the page. You can check the unvisited changes in [[Special::Watchlist]]. -- Lahwaacz (talk) 07:57, 12 January 2017 (UTC)
- You missed my last reply to you in Talk:Bitcoin#Consensus changes referencing the edits and seem to not understand my edit description for , so let me try to reformulate it: We need to add a general, client unspecific, warning, but I have not got round to work on it this week. For it I propose to shortly explain the wording differentiation re "(potential) consensus incompatible" you introduced for the clients, which I did not remove from the descriptions. It's meaning is much stronger anyway (potential incompatibility), but - even yourself - not taking it into account for your own argument above shows it is overlooked. The phrasing is self-speaking too, that it is in the own interest of every user not to customize BS to a non-con value. Re , we can re-add the extra hardware point you were referencing in the notes but (a) Arch users don't need spec handholding, they customize and watch their system resources and (b) to my understanding of the previous discussion between you and Tommy5 it was disputed as very theoretical. So, I considered that part as superfluous at current. --Indigo (talk) 09:15, 13 January 2017 (UTC)
- Client descriptions were removed with . Closing. --Indigo (talk) 23:10, 17 January 2017 (UTC)