Remove bolt-on accounting system #3816

issue jgarzik openend this issue on March 7, 2014
  1. jgarzik commented at 5:24 pm on March 7, 2014: contributor

    The recent malleability issues exposed some cases not covered by the accounting system. Rather than fix it, the consensus seems to lean towards scrapping the accounting system entirely, and returning to a system where keys may have labels (or tags, as I prefer to call them).

    The accounting system can easily result in negative or odd balances if misused or misunderstood, which has happened in the field. Use of raw tx API or direct spends exacerbates this. Users are used to seemingly-odd practices of transferring imaginary money from a dummy account, to eliminate a negative number in some cases.

    Practically speaking, this seems likely to be a large, incompatible change to RPC. This implies

    • other incompatible RPC changes are possible
    • the following line in rpcserver.cpp should be updated along standard REST API versioning conventions, changing the standard URI path from “/” to “/v2/” or somesuch.
    0        if (strURI != "/") {
  2. jgarzik added the label Brainstorming on Mar 7, 2014
  3. gavinandresen commented at 5:32 pm on March 7, 2014: contributor

    Actually… the “weird balances” issues should be fixed by the transaction malleability fixes. If you find one, please write a regression test and submit a bug.

    There is still an issue with CoinJoin balances being reported incorrectly, but that is separate from the accounts system (e.g. listtransactions will give you wacky amounts for CoinJoin txns).

    I do think we should deprecate and remove the accounts feature, I think it encourages lazy development of systems that hold Other People’s Money, when it was designed to help keep track of your own money, and it doesn’t mesh with fees in a satisfying way.

  4. ghost commented at 5:34 pm on March 7, 2014: none

    I love the idea of versioning the RPC but what about backwards compatibility with a predetermined deprecation policy for “/” version 1 RPC? Changes like this are going to break stuff for some implementations but eventually the code must all be gone. Would users not wishing to upgrade need to continue using an oder version of the client or would they run side by side for X amount of time? Google has spent a lot of time on these policies maybe something can be gleaned from it http://googledevelopers. blogspot.ca/2012/04/changes-to-deprecation-policies-and-api.html

    On Fri, Mar 7, 2014 at 12:25 PM, Jeff Garzik notifications@github.comwrote:

    The recent malleability issues exposed some cases not covered by the accounting system. Rather than fix it, the consensus seems to lean towards scrapping the accounting system entirely, and returning to a system where keys may have labels (or tags, as I prefer to call them).

    The accounting system can easily result in negative or odd balances if misused or misunderstood, which has happened in the field. Use of raw tx API or direct spends exacerbates this. Users are used to seemingly-odd practices of transferring imaginary money from a dummy account, to eliminate a negative number in some cases.

    Practically speaking, this seems likely to be a large, incompatible change to RPC. This implies

    • other incompatible RPC changes are possible

    • the following line in rpcserver.cpp should be updated along standard REST API versioning conventions, changing the standard URI path from “/” to “/v2/” or somesuch.

      0if (strURI != "/") {

    Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/issues/3816 .

  5. laanwj commented at 5:38 pm on March 7, 2014: member

    Yes, let’s finally get rid of it.

    I think we should keep labeling of addresses (like the GUI), but remove anything related to accounting or ledgers (such as the ‘move’ command, and faux balances).

    I already made a proposal once #3664 (it can be worded stronger if this is going to be a fully new RPC version):

    • Rename
      • setaccount to setlabel
      • getaccount to getlabel
      • getaddressesbyaccount to getaddresseswithlabel
    • Rename optional account argument of listtransactions to label
    • Deprecate the move RPC command and any account ledger usage
    • Deprecate the use of the account argument in sendmany and sendfrom as well as getbalance
    • Deprecate the following:
      • getreceivedbyaccount
      • listreceivedbyaccount
      • Not sure about: getaccountaddress. Probably deprecate it. “label address” wouldn’t really be a sensible thing.
  6. bananas2 commented at 6:08 pm on March 7, 2014: none

    I think the main reason of misunderstood is the Wiki “Customer creates an account on the website: web server either assigns them a unique customer id number or uses their email address or other unique identifier, calls getaccountaddress “userid” and tells the customer to send to that address to fund their account. “.

    By the name “account” in the api commands i just supposed what it was designed to, then i went to the Wiki that made me sure that it was what i thought. Then everyone here says it should not be used fot hat purpose.

  7. bananas2 commented at 6:15 pm on March 7, 2014: none
    My opinion is that should be made a proper basic accounting system, account based third party services are very important to bitcoin itself. I understand that as a feature it may be out of focus, but it will help bitcoin itself.
  8. gmaxwell commented at 6:26 pm on March 7, 2014: contributor
    It’s impossible to make account data in the current Bitcoin software durable against hardware failure, anyone who is directly using it for accounting third party funds is behaving irresponsibly on this basis alone. I think the bitcoin daemon / reference wallet is the wrong layer of the stack to support multiuser accounting.
  9. ghost commented at 6:28 pm on March 7, 2014: none

    @bananas2 I’m dealing with the exact same challenges right now and from the looks of it this will need to be solved sooner than later in my implementation to read for a newer version of the RPC API. Let me know want to collaborate on something but as of right now my understanding is that this is not something to be considered going forward as part of the bitcoind/QT product.

    On Fri, Mar 7, 2014 at 1:15 PM, bananas2 notifications@github.com wrote:

    My opinion is that should be made a proper basic accounting system, account based third party services are very important to bitcoin itself. I understand it is not the focus, but some help does not hurt.

    Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/issues/3816#issuecomment-37051457 .

  10. bf0d7998-81ec-48d1-b236-076ed3c77581 commented at 8:18 pm on March 7, 2014: none

    Probably worthwhile to keep in mind that if the API is abruptly removed then people will just refuse to upgrade and expose themselves to any future CVEs. For a while at least it would be sensible to commit to backporting fixes to these versions if people need to back their software away from using them.

    I agree that it needs to go, people seem to enjoy making web-wallet services using accounts then wondering why it blew up in their faces. Definitely not something the core client should be handling at any rate.

  11. luke-jr commented at 10:17 pm on March 7, 2014: member
    @bf0d7998-81ec-48d1-b236-076ed3c77581 There are already maintained backports for at least 0.7.x and 0.8.x, so no need to worry over that IMO.
  12. int03h commented at 5:39 am on March 8, 2014: none

    Much lurking lately since nothing to add, but I personally would love to decouple the base network from everything else. –disable-wallet was an important step.Building out bitcoind so that it offers better scalability is probably the next most important thing I believe we need.

    This means that any accounting or additional functionality will have to be modular and separate anyway since its going to have to deal with potentially a new architecture that makes this possible.

    IF you guys have the time to make that happen so be it. Most of the guys that are doing any of this stuff commercially SHOULD be building out their own transaction “management” mechanisms since its their money and they should have appropriate architecture, code and processes in place to mitigate losses for themselves and their customers. IF they don’t have the skills to do it .. too bad, no money for Timmy.

    Fundamentally: The bullshit we saw recently with our dear friend mark can not be repeated again - giving “people” all the OPEN code, the fruit of YOUR loins, so they can take it out there and make Bitcoin look bad is really not cool. IMHO YMMV ..etc..

    EDIT : someone left their soapbox behind .. I will step off it now. There you go .. you can have it back .. ;)

  13. bf0d7998-81ec-48d1-b236-076ed3c77581 commented at 11:47 am on March 8, 2014: none

    @int03h

    The fundamental issue is that understanding the census and potential problems is something of a mystery to most programmers who are not contributors or the core team. Some of the biggest sites - coinbase and mtgox - have both tried the best to re-implement transactions and network behavior, but both seem to have had extraordinary trouble managing to keep up with smaller nuances. Coinbase seems to have some strange issues with their software keeping up with the blockchain and sending proper transactions, mtgox has had issues sending transactions (invalid DER encoding) and managing to automatically resend unconfirmed transactions without double spending the inputs.

    If some incredibly well funded ventures have trouble scaling bitcoin transactions, what chance does the self-funded startup or small company have? bitcoind is inadequate for almost any situation larger than a couple of issues, which leaves users reaching for blockchain.info, who have been dispensing completely incorrect (missing transactions, bad spent/unspent information, invalid balancea) information for at least a week now.

    If we want to avoid centralization the available solutions need to be improved, removing the awful accounts feature is hopefully a catalyst.

  14. laanwj commented at 1:07 pm on March 8, 2014: member

    @bf0d7998-81ec-48d1-b236-076ed3c77581, @bananas2 I agree that it would be nice for scalable solutions to bitcoin accounting be available freely, however, as it is now no one is willing to create and/or maintain such system. Open source doesn’t work by “this should exist” but by “scratch your own itch”. The open source community is not a free resource to fix your company’s issues.

    The reality is that the few developers of Bitcoin Core are struggling to maintain what exists now. This means that the scope needs to be narrowed, not widened.

    If the current broken solution is dropped from bitcoind that leaves the way open for independent, new systems that can be built on top of bitcoind. No need to implement transaction handling yourself, you can still use bitcoind for that.

  15. int03h commented at 1:28 pm on March 8, 2014: none
    @bf0d7998-81ec-48d1-b236-076ed3c77581 Small point of clarification so that I don’t leave the impression that I have the kind of application that requires this: When I said scalability .. I didn’t just mean TPs. There are many elements that could fall into the scalability realm including High Availability and better p2p sync that I most certainly would put ahead of that kind of scalability ;).
  16. bf0d7998-81ec-48d1-b236-076ed3c77581 commented at 6:00 pm on March 8, 2014: none

    @laanwj

    The reality is that the few developers of Bitcoin Core are struggling to maintain what exists now.

    I certainly agree, I’m all for removing these features in the hope that somebody else picks up the slack.

    Open source doesn’t work by “this should exist” but by “scratch your own itch”. The open source community is not a free resource to fix your company’s issues.

    Again, I agree. It’s unfortunately something that not a lot of people want to get involved with. To contribute such a codebase anonymously would insight trust issues, to do it with a real name would make the person a target should a programming mistake result in the loss of Bitcoin for a third party. I don’t think it’s a risk anybody reasonably wants to put themselves at risk of, given how the community has treated actors like this in the past and today.

  17. laanwj commented at 11:21 am on March 9, 2014: member
    If we’re going with multiple ‘dialects’ for JSON RPC selectable by the client, it may be useful to include the formatting/parsing of monetary amounts (#3759) in this as well. It’s one of the things that would be better to let the client choose rather than making it a global setting.
  18. luke-jr commented at 5:50 pm on March 9, 2014: member
    Or just switch to a Number of satoshis in all cases with the new RPC version…
  19. int03h commented at 1:29 am on March 10, 2014: none
    @luke-jr Persistence is what counts. Will is survive the scrutiny of those that come after us ? If the RPC is fully fleshed out and solid then you can wipe your hands and walk away - if it isn’t then don’t even start. IMO.
  20. laanwj commented at 7:01 am on March 10, 2014: member
    @luke-jr Please keep that discussion in the issue I linked
  21. benjiqq commented at 2:24 pm on November 5, 2014: none

    @jgarzik @laanwj What’s the status of this? I have been working on this topic. It would be good if the accounts feature would be indeed flagged as deprecated (see laanjw’s proposal to change to labels [1]). I know of plenty merchants, exchanges, etc. who (mis-) use the account system. It will be very helpful to have a much better documented RPC, so that people who implement account features can build together in the open, instead of closed source. Quite a few people use bitcoind only through the RPC without knowing internals. I’m implementing an account system which is layered over bitcoind, not using the internal account system. As I understand that’s what most larger operations do.

    [1] #3664 (comment)

  22. jgarzik commented at 2:33 pm on November 5, 2014: contributor

    @benjyz The status is reasonable summarized here. There appears to be consensus that it should be deprecated and removed.

    However, no patches have been produced, and this would need staging & lots of communication with existing stakeholders, where breakage is quite likely. There are known users, some of them big.

  23. sipa commented at 2:35 pm on November 5, 2014: member
    I’m fine with marking them deprecated in 0.10, but not remove until later.
  24. jgarzik commented at 2:37 pm on November 5, 2014: contributor
    @sipa Yes, it cannot be removed without breaking several existing users. This one requires more deprecation planning, and perhaps coding an example alternative for contrib/
  25. PierreRochard commented at 2:39 pm on November 5, 2014: contributor
    I agree with @sipa, we need time to have open source Bitcoin accounting platforms develop and mature. That will ease the transition for those currently dependent on this feature.
  26. luke-jr commented at 2:44 pm on November 5, 2014: member
    Note: merchants and exchanges should be using some kind of account system, but shouldn’t be using Bitcoin Core’s wallet implementation at all right now…
  27. sipa commented at 2:46 pm on November 5, 2014: member
    @luke-jr whether they should or not, I’m pretty sure that several do, and we don’t want them to stop upgrading their software because we drop a feature.
  28. int03h commented at 4:31 pm on November 5, 2014: none

    broken feature ?? Oxymoron much?? Releasing broken stuff and not maintaining it because someone is using it for their production environment is assanine.

    As another year draws to a close, I am going to buy candle for the cake. I will bet, this time next, that I will buying another to join it and the others

    Seriously guys, On Nov 5, 2014 9:46 AM, “Pieter Wuille” notifications@github.com wrote:

    @luke-jr whether they should or not, I’m pretty sure that several do, and we don’t want them to stop upgrading their software because we drop a feature.

    — Reply to this email directly or view it on GitHub.

    e

  29. jgarzik commented at 4:34 pm on November 5, 2014: contributor
    If you will not bother to read beyond the OP or understand the issues, troll somewhere else.
  30. benjiqq commented at 4:55 pm on November 5, 2014: none

    Is there a working definition of a simple “account system” and how that would interact with labels?

    Example scenario: a small webshop (W) with users (U) accepts Bitcoin. Incoming transactions that W handles are mapped to U. How W handles user-data is unknown, but it is known that W generates addresses A for each U and maintains that mapping, to track inputs and outputs. So W wants to basically update the balances of A <> U not within bitcoind but his own database by polling bitcoind.

  31. PierreRochard commented at 4:59 pm on November 5, 2014: contributor
    @benjyz That’s in the works for pacioli https://github.com/NakamotoInstitute/pacioli Let me know if you’re interested in helping with the bitcoind <-> JSON-RPC <-> sqlalchemy models middleware
  32. benjiqq commented at 5:11 pm on November 5, 2014: none
    @pierrerochard Yes, I’ve been working on some middleware as well. That’s one reason I’m asking because from this thread I take away that any middleware should be definitely not be using accounts. If it is flagged as deprecated it will be easier to convince others to stop using it. @luke-jr What wallet implementations exist that also can be used for merchants and exchanges? If there is a clear interface people can build solutions on top. It seems you’re arguing nobody should use bitcoind.
  33. benjiqq commented at 3:04 pm on November 25, 2014: none
    @gavinandresen You wrote in this thread: “I think it encourages lazy development of systems that hold Other People’s Money” I think it is in the scope of bitcoind to provide a proper interface to create such systems. How could it be not or rather what would be the alternative? A fork of bitcoind to support such applications? I believe the scope of bitcoind should be stated in the readme and docs, and the API and docs improved. What would be the best way to build say a merchant/exchange/etc. solution in an opensource way? I think this matter is very important and does not get enough attention. I don’t have the resources or knowledge to re-write bitcoin from scratch, and it’s not a reasonable expectation. Clearly holding other people’s money and holding my own money are related problem-sets.
  34. laanwj commented at 11:19 am on November 26, 2014: member

    Note: merchants and exchanges should be using some kind of account system, but shouldn’t be using Bitcoin Core’s wallet implementation at all right now…

    Exactly.

    A fork of bitcoind to support such applications?

    Ideally, no, it should be a completely separate application. Making it a fork of bitcoind will just make it harder to maintain over time.

    The scope of Bitcoin Core is narrowing toward maintenance of the node infrastructure and consensus. Wallet innovations happen somewhere else, and so should accounting, as well as smart integration of deterministic key generation and such. See for example https://github.com/ciphrex/CoinVault that @CodeShark has been working on.

    I’m all for flagging the account system as deprecated, by the way. This could be added to the RPC help. I suggest that the people that are complaining that things go too slow dust off their keyboards and start to contribute.

  35. benjiqq commented at 11:58 am on November 27, 2014: none
    Thanks for the comment. I’m still struggling to understand a) how holding other people’s money should be so different from holding one’s own, and why accounting and wallets have to be separate projects. b) what the scope of bitcoind is, and the outside API it exposes with regards to that scope. The point of an API is to expose functionality which is not concerned with internals. To write a web-application I don’t need to know TCP/IP or ethernet (or the physics of fibre optic cables).
  36. felipecsl commented at 8:18 am on December 30, 2014: none
    I have a bitcoin related startup that has been running on top of the bitcoind accounts feature for a few months now and I just stumbled upon on this Issue. It got me really worried. When I first implemented it, I didn’t see anywhere in the API docs/reference mentioning that this functionality should not be used or was planned for deprecation. I wouldn’t mind implementing it myself, but the fact that bitcoind already offered this functionality seemed like a no brainer. It sounded like a robust accounting solution, but apparently not. Is there any other open source library you guys would recommend for this or should I roll my own? Preferably ruby. Thanks!
  37. benjiqq commented at 9:08 am on December 30, 2014: none
    @felipecsl I much agree - this should be clearly documented. Overall its just a big hole in the ecosystem. Neither toshi.io nor bitcore.io have accounts. Coinvault seems to be the only project.
  38. int03h commented at 1:00 pm on December 30, 2014: none

    Shit luck your crystal ball was malfunctioning that day. Sorry to be a d!ck .. but this group doesn’t give a shit about this problem.. so I honestly doubt any sage advice will be forthcoming besides perhaps " well why don’t you write something " : which I completely agree is Non-sense since, a) They have had PLENTLY of time to write an alternative b) It IS clearly a priority c) Have their own self interests at the heart of this project.

    Gavin.. here let me light your torch for you, give me a BTC address at the foundation and I will send you a donation for a pitchfork.

    On Tue, Dec 30, 2014 at 3:19 AM, Felipe Lima notifications@github.com wrote:

    I have a bitcoin related startup that has been running on top of the bitcoind accounts feature for a few months now and I just stumbled upon on this Issue. It got me really worried. When I first implemented it, I didn’t see anywhere in the API docs/reference mentioning that this functionality should not be used or was planned for deprecation. I wouldn’t mind implementing it myself, but the fact that bitcoind already offered this functionality seemed like a no brainer. It sounded like a robust accounting solution, but apparently not. Is there any other open source library you guys would recommend for this or should I roll my own? Preferably ruby. Thanks!

    — Reply to this email directly or view it on GitHub #3816 (comment).

  39. luke-jr commented at 1:05 pm on December 30, 2014: member
    @int03h If it’s a priority to you, you can provide the code (or hire someone to). Why do you think we have any obligation to you? Self-interests are what drive open source.
  40. int03h commented at 1:07 pm on December 30, 2014: none

    Because you guys KNOWINGLY continue to provide broken code, and preclude anyone that is remotely contrary to your so-called consensus. Notice all the ALT coins out there.. why do you think they want nothing to do with you lot ?

    PS: notice .. I pre-empted your " Write your own comment.. dude. "

    PPS: Also notice(not that you care, I am sure) my withdrawal from this community. This project will get nowhere until you guys get your heads out your butts and stop using " write your own as the go-to clause " for EVERYTHING that is wrong with this project.

    PPPS: Lots of people made LOTS of money on this project. Including yourself. This frankly is beyond absurd that the foundation or ANYONE that made money on this can’t just hire a Pakistani to write something.

  41. rnicoll commented at 1:08 pm on December 30, 2014: contributor
    I’d agree it needs to be clearer that a new accounting system is desirable, and the existing one considered insufficient, at least.
  42. luke-jr commented at 1:10 pm on December 30, 2014: member
    @int03h Please. The vast majority of altcoins are scams and their creators “want nothing to do with” Bitcoin because they can’t scam people with it.
  43. int03h commented at 1:14 pm on December 30, 2014: none

    @luke-jr … accepted answer #4 from you. To be expected.. I should have pre-empted that one too. The vaste majority ? So you are now prepared to accept at least a minority as legitimate? Wow .. at least that has changed somewhat.

    Eagerly awaiting someone to shout TROLL TROLL .. or .. get my stuff deleted again. It’s just your guys way of keeping the situation under control. Meh .. I am not sure why I bother?

    I do sincerely regret buying you that pizza though.

  44. benjiqq commented at 1:56 pm on December 30, 2014: none
    @luke-jr didn’t several core bitcoin devs raise 21 million dollars in venture capital to solve inter-op problems? Bitcoin core plays the opensource card when it suits them, and the scam accusation is getting more and more out of date as time goes on. This isn’t about resources to produce code, this is about fixing broken things. Unfortunately what “bitcoin wizards” chose instead to do is invent something called side-chains, and start a for-profit enterprise around it. I think it will create a lot of problems with conflict of interest. Would have been much better to establish a non-profit and tunnel some resources to improve bitcoin.
  45. int03h commented at 2:05 pm on December 30, 2014: none

    @int03h If it’s a priority to you, you can provide the code (or hire someone to). Why do you think we have any obligation to you? Self-interests are what drive open source.

    Sorry if this is out of order.. I only read this properly now and I felt it needed a direct response. @luke-jr To answer your direct questions to me, let me answer them with some other questions:

    If I provided the code would this project merge it ? No. Why ? Because it’s not in anyones interest that holds the keys to the kingdom to do this.

    When did I say you have an obligation to me? I thought this was a project based on consensus ? I believe my one vote counts just as much as yours does bro. Does it not?

    So you concede my point that this project is based on self interest then, as opposed to mutual benefit, since it is also “open source” ?

    and .. as the gentleman above me so kindly poiinted out .. the foundation has the funds to hire a Pakastani to do it. Or at the very least write the words " The Accounting System is Broken. Do Not Use It." Into the documentation.

  46. luke-jr commented at 2:31 pm on December 30, 2014: member

    @benjyz The non-profit (Bitcoin Foundation) was actually established first. There is no need to have a single organisation responsible for Bitcoin development - nor is that necessarily a good idea. @int03h Most likely if you provided code, it would not be merged, because the general conclusion we’ve come to is that accounting (and really, the wallet entirely) should be separate from Bitcoin Core. If you want to implement a new accounting system, I suggest doing it in an independent codebase built on top of Bitcoin Core rather than built-in to it.

    “They have had PLENTLY of time to write an alternative” implies we have an obligation to you. This project (Bitcoin Core) produces software for coming to consensus, but the project itself is run by merit. “Voting” for the Bitcoin consensus system takes place when people choose to adopt, not adopt, fork, etc the software.

  47. laanwj commented at 2:32 pm on December 30, 2014: member

    An open source project is supposed to be based on mutual interest, but that implies that all the parties are contributing. Bitcoin Core has always been an extremely lopsided project, in that almost none of the companies using it contribute anything back. It is not ‘us versus you’. Here on github it should just be ‘us contributors’.

    Also the account system is not broken, it does what it does. That’s exactly who no one dares to change it anymore. Legacy code and all that. I heard some people are going to work on a new wallet on a separate branch, so if the design is done right this time, it will include the appropriate hooks for building an account system on top.

    Lots of aspects are confused in one project right now, this should unravel or it is going to cause problems for certain. You cannot have a few overworked devs maintain the entire ecosystem. It is important for us to be able to focus on the core infrastructure as there are many challenges ahead there. First and foremost the network should keep running and scaling.

    People should be able to say, fork the wallet code and account code without forking the consensus code as well. Right now that is kind of unwieldy with everything in one project. For the steps toward splitting things up, some migration is going to be necessary, and sometimes that’s going to come with the pain of APIs being deprecated.

    That said, yes the deprecation needs to be better documented. We could add a warning to the 0.10 release notes.

  48. luke-jr commented at 2:35 pm on December 30, 2014: member
    See also #5575 (just submitted). Maybe belongs in 0.10 as well?
  49. int03h commented at 2:36 pm on December 30, 2014: none
    @laanwj The only shining light of lucidity as usual. Your contributions to this project are much appreciated, and if anything is lopsided it is your overwhelmingly prolific positive contributions. (my opinion -for whatever that counts )
  50. PierreRochard commented at 2:38 pm on December 30, 2014: contributor

    “the general conclusion we’ve come to is that accounting (and really, the wallet entirely) should be separate from Bitcoin Core. "

    As a Bitcoin accountant, I fully agree with this conclusion. Separation of concerns.

    “I heard some people are going to work on a new wallet on a separate branch, so if the design is done right this time, it will include the appropriate hooks for building an account system on top.”

    Looking forward to this, any links to where it’s being discussed?

    Thanks

  51. int03h commented at 2:48 pm on December 30, 2014: none

    “They have had PLENTLY of time to write an alternative” implies we have an obligation to you. This project (Bitcoin Core) produces software for coming to consensus, but the project itself is run by merit. “Voting” for the Bitcoin consensus system takes place when people choose to adopt, not adopt, fork, etc the software. @luke-jr I imply nothing. I state fact.

    I do not need “your” accounting system, therefore there is no anticipation of any required action which removes the implication of obligation.

    The obligation (implied or otherwise) is to meet the standards that have been set forth, and in fact heavily promulgated, as the charter and purpose of Bitcoin being a robust project.

    If I have misunderstood this, then all of this is moot, and I apologize for the misunderstanding.

  52. dgenr8 commented at 5:15 pm on December 30, 2014: contributor
    0.10 introduces a new rpc test that uses the accounting move command we want to deprecate, and is a pretty good example of the confusion that comes from using it. See #5550.
  53. jgarzik commented at 5:23 pm on December 30, 2014: contributor

    In the very short term, there are notable sites using the accounting system & wallet in production. There is a need to continue to provide reliable operation to those users.

    Longer term, the accounting system has many limitations and sometimes works in ways not expected by people new to bitcoin.

    Balancing those constraints, the next step is encouraging users to migrate away from the accounting system.

    The intention of this Brainstorming-labelled issue was to open the discussion on the implications of turning off the accounting system, and hopefully starting to document why that should/will come about.

  54. int03h commented at 4:15 pm on December 31, 2014: none

    <question/diatribe directed to @jgarzikf>

    Jeff, with all due respect, this is/has been the position that has been held for as long as I have been involved, which by now, is not an insubstantial amount of time. ( thanks mainly to our friends at BFL ;) )

    How can this be a brainstorming session if everyone that matters (the devs) are defending the status quo? and frankly, in my opinion directly attacking any position that attempts to move it in any meaningful direction. Despite the length and time I took to write this, this thread is not my whole being, but it does represent something I dearly love and care about, perhaps too much. I am sincerely extremely saddened by the ABSOLUTE immovability of this general situation. (The wallet falls into the same category). This brainstorming session just sounds like an extremely small loud echo chamber to me. i.e.. the seats are reserved, doors locked and guarded and the invitations into the discussion are actively censored and filtered,or simply dismissed by discrediting the voices of descent. Reminds me of the Free Masons. Lol. </question/diatribe directed to @jgarzikf>

    If Satoshi was still around, he could fill the vacuum of “the voice of reason” .. very much like what Linus does. We do not have this luxury, unfortunately. The keys to the kingdom, and ultimately the responsibility for that ~$1B were handed over to “you guys” .. the devs… the guys that allow or do not allow the consensus to be accepted and rolled into the cake, using what seems to be with a very simple and open ticket/merge process.

    Regardless of who is writing what, the perception from at least my point of view, is that this project is being stifled by the this confusion and most importantly: makes the people that have their $1B (whatever) invested very vulnerable to any deliberate/unintentional manipulation of the project. Notice I said perception, i.e. this is not an accusation .. it is simply my opinion on what I see as the result of all the decisions being made, which come out as the binary that is Bitcoin. The changelog is testament to your hard work, in all it’s awesomeness. (with a few warts here and there) ;)

    However the status quo just can not continue. The accounting system is one example of the fragmentation of what SHOULD and WAS INTENDED to be a project for the people by the people, IF I understand Satoshi’s philosophy correctly.

    We get fucked over everyday by things we can not control. The banks, the government, your boss, your wife, your parents, the weather, viruses, bears, lions, hyenas etc etc etc .. Why should we allow the one thing we DO have the control over to be, frankly, this, screwed up? Seriously guys … please, for the love of god .. understand, this is NOT a community project, it is not a hobby, it is not behaving like an open source consensus driven entity, and most certainly should not be allowed to be a ego/self interest based entity(as noted by some above). If you want to get all crystal ballish - it CAN and SHOULD be the future of all mankind, if taken to the the ultimate iteration of being the thing that controls all things. SkyNet is alive … initiate T1000 lock on Satoshi …. scene opens with with Arnie naked in parking lot ;)

    Until we can agree on these fundamental principles, this discussion (and ultimately the entire project ) will continue to be a mobius strrip.

    The perception is that I am a troll that contributes nothing to Bitcoin. That may/or may not be true. I accept both positions. Like me or hate me, I don’t think I am wrong. I feel that I have done more than my fair share for this project.. some of it you will never know about. Some of it may be viewed as counter productive, I don’t agree and frankly don’t give 2 shits of what anyone thinks about me. Whatever.. Who I am and what I do is not really the point here. Play the ball and not the player. I only say this, because people have the tendency to discredit other peoples opinions based on, as someone above put it, their “merit” or their “expectations” or “identifying obligations” or “being a troll” or “not understanding the OP’s question " or “understanding the implications to other parties” or any number of excuses for not doing what NEEDS to be done. As I pointed out, this is not and should not be a merit based project. Consensus can not be merit based. See feudalism, slavery, right to vote, etc etc etc.. as examples of this behaviour. Merit does not automatically mean liberty/freedom/democracy/altruism therefore it can not be the yardstick by which things are measured.

    Simply : I do not see any mechanism for consensus, and in fact I see the complete opposite. The code that is released is the “baby” that is the product of a very small elite groups decisions. Merging or not merging code is the way that this control is accomplished, and that is the reason for this unbelievably long comment. ( Holy shit I can talk a lot of shit sometimes when I am worked up - take solace in the fact that my wife and child have to deal with me everyday - pity them! ) ;)

    The simple fact is that people do not understand the nuance of the code involved and thus have little capacity to overcome the MASSIVE learning curve required to participate/contribute in any meaningful way,I tried, I failed, I am to old for this, if I was 20 I would rewrite all of this in ASM. I have learnt and forgotten enough programming languages to fill a small dump truck, I have no interest in learning another, especially if it is only for one, very complex project, regardless of my passion for it. My job is in enterprise architecture.. something I have done plenty of at all different levels, so I speak from a perspective that comprehends this all at a view that is above the nitty gritty of the individual code merges, although I do watch all of them with great interest. Kano and Lukes little war is another that amused me endlessly, less so now that I can’t afford to spend 50K on any kind of meaningful gear to mine on especially with the price being/doing what it is.

    Anway .. the lack of participation should not be used as an excuse for what is being allowed to perpetuate. i.e. All attempts/opportunities for simplification, THAT WOULD ENCOURAGE NEW BLOOD TO JOIN, seem to be blocked automatically and then defended vehemently, when someone asks: WTF?! Why can’t we just make it easier for people to implement/develop/contribute to the code? Why can’t there “just” be an API or exposed RPC?etc etc the kinds of questions get torpedoed so fast they must be based on some auto-reply non-heuristic email rules.

    Finally,my dear friends, this is intended as a plea not a admonishment. Can we please, please, please stop playing politics and take ownership of what this project ultimately means for the future, regardless of the influence of what the fiscal positions that people hold or their reliance on obsolete code which should be obliterated not perpetuated ad-infinitum (or so it seems to me). These positions are very obviously skewing the most important strategic decisions (or more often than not the lack of) from being made. Please, take a step back, and do what’s right for the project, not what is right from your own personal financial perspective. The major stakeholders with tons of cash invested, can afford more programmers in Bangalor. Don’t worry about them. They will be fine. Worry about us. The ones that use it. The ones that vote with their Satoshi’s every time a block is generated. Worry about the ones that don’t and more importantly WON’T anymore because of some (more than one) very unpleasant events in the past, and I am not talking about SR or BMR
    </my bitcoin philosophy>

    I promise I will no longer pollute this thread with my thoughts. I think I have said it all.. Dunno .. we will see. Depends on who is going to give me a cookie.

    Thank you for all your efforts everyone. Please have a happy and prosperous 2015.

    Stay frosty.

  55. jtimon commented at 2:49 pm on January 3, 2015: contributor

    Although I agree that a new rpc interface for a separated wallet is the way to go long term, I’m not convinced that a smaller redesign (maybe just moving to int satoshis and getting rid of accounts) it’s a waste of time. There’s at least 3 things that will require significant refactoring work that I believe go before separating the wallet: moving transaction consensus validation (to be used by libconsensus), moving the p2p protocol messages and as much policy-related code as possible out of main. From those 3 things, it seems to me that something like #4646 (moving p2p messages out of main) is specially important for separating the wallet. Maybe the first step is separating it in different binaries. Say, instead of having –disable-wallet, that could be the default for bitcoind, and then have a bitcoind-wallet and bitcoin-client-wallet. Maybe always build bitcoin-qt with wallet. Then at some point separate the repos (maybe bitcoin core becomes a subrepository of bitcoin-wallet ?). I don’t know, maybe this belongs to another issue… My point is, without having a roadmap for the wallet separation, postponing any changes to the rpc interface seems like an unnecessary burden. Simplifying or deleting some rpc calls can actually be good for the separation even if bigger changes are going to happen after the separation.

    I would be in favor of declaring accounts deprecated for 0.10 and removing them for 0.11, for example, even if the wallet only gets fully separated by 0.12 or 0.13.

  56. benjiqq commented at 6:29 pm on October 28, 2015: none
    AFAIK accounting was removed and this issue is resolved.
  57. luke-jr commented at 10:18 pm on October 28, 2015: member
    It has been marked deprecated, but not yet removed.
  58. pstratem commented at 1:53 am on December 29, 2015: contributor

    @luke-jr it’s now been (nearly) a full year since the rpc calls were marked as DEPRECATED

    I propose that the rpc calls be disabled in the release after 0.12.0 unless a configuration option is set

    Then removed entirely in the next release (major or minor).

  59. jonasschnelli commented at 7:27 am on December 29, 2015: contributor

    IMO a better option would be to add a second wallet implementation (could be very similar to the existing one / copy of the existing sources in /wallet). The new implementation could be a combination of a new wallet backend format (logdb), the bip32 patch and a multiwallet support.

    I guess the maintenance effort would be acceptable.

  60. dooglus commented at 11:09 am on December 29, 2015: contributor

    @jgarzik Re “The recent malleability issues exposed some cases not covered by the accounting system” in OP, do you have any details of these cases?

    Neither https://en.bitcoin.it/wiki/Help:Accounts_explained nor https://en.bitcoin.it/wiki/Transaction_Malleability mention the problems, and I’ve also failed to find mention of the problems by searching on Google.

  61. mikegogulski commented at 8:59 pm on March 2, 2016: none

    Replying to @pstratem on #3816 (comment)

    I have several services which depend on the account feature. Yes, it’s buggy, but I’m aware of the bugs and don’t rely on it for things that would trigger the bugs.

    If we’re going back to labels, that’s fine, but there should be a major release with labels as aliases for accounts before accounts disappear entirely.

    Replying to @laanwj on #3816 (comment)

    • Deprecate the move RPC command and any account ledger usage
    • Deprecate the use of the account argument in sendmany and sendfrom as well as getbalance
    • Deprecate the following:
      • getreceivedbyaccount
      • listreceivedbyaccount

    I need most of these capabilities. Can’t they be retained and just operate on labels instead?

  62. benjiqq commented at 7:48 am on March 3, 2016: none

    @mikegogulski Bitcoin is not a good accounting system in the following sense.

    Account should mean mapping human ID to Bitcoin ID in some way. Usually that involves some trust or custodian relationship, between account holder and custodian. The custodian holds money for the account holder. In Bitcoin usually there is no such relationship. Trusted third parties are avoided altogether. The account system as it existed is merely a labelling system. Just attaching some string to a key is trivial - that’s not the problem of accounting. So what used to be “accounts” has nothing to do with accounts in the sense of somebody holding money for another person. That’s what a bank account is, and one can debate whether Bitcoin web-wallets are like banks or not.

    Bitcoin has some very limited facilities to manage trust - a combination of multi-sig and escrow e.g. But for many applications it is very complicated, so that in the last 3 years almost no progress has been made for advanced applications. It is related to the underlying economic model.

    There is a deeper reason nobody has implemented a proper layer to do accounting on top of Bitcoin - nobody in the Bitcoin (-core) project believes its necessary or interesting. I’d expect this to be the case in the future.

  63. mikegogulski commented at 11:48 am on March 3, 2016: none

    @benjyz Thanks for your reply.

    You’re absolutely right. Bitcoin Core’s wallet isn’t a good accounting system, nor should it attempt to be one. I fully agree. Anyone who needs a good accounting system as you describe must implement their own solution. There’s no sense in thinking Core’s developers should develop an interest in formal accounting :)

    However, the functionality provided by accounts today, while broken from a perspective of “is it a good accounting system or not”, has been in Core for a very long time. I’ve depended on it since 2011, when it was still labels instead of accounts, and, the way I’m using it, it’s never let me down.

    Check this out:

    0$ ls -l cron.php
1-rw-r--r-- 1 mike mike 2154 Aug  5  2013 cron.php
2$ grep 'c->' cron.php
3    $arr = $c->listreceivedbyaddress(10, false);
4      $c->sendtoaddress($destaddr, $residue);
5      $c->setaccount($rcvd["address"], "");
6      //$c->setlabel($rcvd["address"], "");

    That’s code from a service I’ve been running for five years, and that I haven’t had to change in the past 2.5 years. And as you can see, it originally used labels, until they were replaced by “accounts”.

    The specific methods I need are:

    • getnewaddress(label)
    • setlabel(address)
    • listreceivedbyaddress, with label information
    • listlabels
    • move(…)

    If I can’t have those, my I’ll be forced into either staying with an old version of Core (never good, because CVEs) or expending a lot of effort implementing a database application that talks to the wallet in order to retain the functionality I’ve gotten from Core since time immemorial (ok, not that long, but still! :) ).

    Is it too much to ask to retain remove these (renamed) wallet methods?

  64. benjiqq commented at 12:17 pm on March 3, 2016: none

    @mikegogulski if C is holding money for A, say 42 BTC, in terms of Bitcoin, that is equivalent with C owning 42 BTC. The fact that C labels an address “I hold BTC for A” doesn’t change this fact. Accounts was introduced after the 2009 release and was a mere afterthought to Bitcoin’s operation. The word accounts and accounting is completely misleading. Accounts is a concept that comes from banking, and Bitcoin doesn’t allow for banking. Bitcoin removed all trust entirely, and its very hard or impossible to build trust-relationships on top. If you hold money for others, in terms of Bitcoin’s model you’re doing it wrong. In particular matching human ID to money has another problem - traditional law and nation states see themselves as the watchdog of financial transactions. In terms of traditional law its not even clear that holding Bitcoin as money is “legal”. Because if it were legal the question is why I can’t pay my taxes in Bitcoin or send it to a bank.

    There are better ways to do this with multi-sig, escrow, HD wallets, green-addresses, time-lock contracts, ColoredCoins, etc. I’ve been working on related problems for years, but I don’t expect “core” cater to users. I guess everyone can choose whether they want to work on, such as Zero-knowledge-Sidechain magic or whatever the case may be. It is noteworthy that millions of people are using Bitcoin in the “wrong” way via web-wallets and exchanges (which have to implement AML/KYC). I doubt that “accounting” as an API is a fruitful approach. It would be better to expose multi-sig and escrow in some way that makes custodian relationships safer. If you really need these kinds of features, you’re more likely better off with an alternative which aims to implement them.

    Further info: https://en.wikipedia.org/wiki/Bank https://en.wikipedia.org/wiki/Accounting

  65. laanwj commented at 1:13 pm on March 3, 2016: member

    @luke-jr it’s now been (nearly) a full year since the rpc calls were marked as DEPRECATED I propose that the rpc calls be disabled in the release after 0.12.0 unless a configuration option is set Then removed entirely in the next release (major or minor).

    At some point this will have to be done, but I don’t think there is a good migration path yet for users of the account system, so this feature pretty much exists in limbo for now.

    There is a deeper reason nobody has implemented a proper layer to do accounting on top of Bitcoin - nobody in the Bitcoin (-core) project believes its necessary or interesting

    I doubt you will find anyone that disagrees that accounting is necessary.

    But yes AFAIK no one is working on an open source external replacement. There are tons of proprietary implementations, which are specific to how a certain company does accounting.

  66. laanwj added the label Wallet on Mar 3, 2016
  67. mikegogulski commented at 4:24 am on March 4, 2016: none
    @benjyz I know all that. Your comment doesn’t address anything I said. Not helpful.
  68. dooglus commented at 10:35 pm on March 5, 2016: contributor

    @mikegogulski I find myself in the same place as you. I rely on:

    • getaddressesbyaccount and getaccountaddress to provide deposit addresses for users
    • listaccounts and move to detect new deposits (using move to move processed deposits to a non-user account, so they don’t show up again next time I run listaccounts)
    • getbalance to check whether the user has any deposits with less than 6 confirmations

    These methods appear to work very well for me. I’m aware that the accounting system is confusing and badly named, but it provides functionality which is hard to find elsewhere.

    I wouldn’t care if the word ‘account’ was replaced by ’label’ in all the RPC calls. I would mind if the RPC calls were removed.

  69. kladivo commented at 11:11 pm on March 6, 2016: none

    @dooglus: Nice to see you here. Thanks for the input.

    I’m doing basically the same thing with listaccounts and move, I reckon. I would be very happy to replace my use of those commands with some capability that would cause the wallet to emit a formatted HTTPS GET request every time the wallet balance changes – though I suspect that making the wallet both an RPC producer as well as consumer is too much to ask for.

  70. dooglus commented at 2:09 am on March 7, 2016: contributor

    @kladivo I like that listaccounts lets me specify a number of confirmations:

    0List account balances for 6 or more confirmations
1> bitcoin-cli listaccounts 6

    I don’t want to know every time the balance changes. I don’t want to know about a deposit at all until it has 6 confirmations. Until then it’s possible for the number of confirmations to go up and down as reorgs happen. I like how I don’t have to care about that if I use listaccounts - it hides all that complexity from me. I thought it handled maleability too, but @jgarzik’s cryptic comment in the OP of this thread suggests it might not. I asked for further details but got no response so I’m not sure if there’s really an outstanding issue or not.

  71. laanwj referenced this in commit 52aeffb7e4 on Mar 21, 2016
  72. laanwj referenced this in commit 4f522a6e49 on Mar 21, 2016
  73. laanwj referenced this in commit d036fa4411 on Mar 21, 2016
  74. BamaStangGuy commented at 9:56 am on May 19, 2016: none
    We also make heavy use of the accounts system and are not looking forward to our options that are out there right now. Going to be expensive and time consuming to move to a MySQL Bitcoin bridge to handle this.
  75. jtimon commented at 11:52 am on May 20, 2016: contributor
    Maybe documenting a more sane alternative for the current users would be useful before removing the feature? If they don’t like that, they can always maintain their own fork that restores the old accounting system, but we really should stop maintaining this feature in master at some point.
  76. BamaStangGuy commented at 11:50 pm on May 20, 2016: none
    We are going to start working on our own PHP/MySQL method of replacing the account feature but that isn’t going to happen overnight.
  77. luke-jr commented at 3:40 am on May 21, 2016: member
    Nobody expected you to do anything overnight. This has been publicly on the table for over 2 years now - that’s plenty of time. Furthermore, nobody can force you to upgrade your wallet once accounting is in fact removed, so you’re not really being rushed to do it “overnight” in the current state either.
  78. BamaStangGuy commented at 3:48 am on May 21, 2016: none

    Sorry, but the documentation we used to build our site mentioned absolutely no where that this was being considered for removal much less just deprecated. The only reason I found out about this is because I was researching the negative balance issue.

    Where would you go to find information and documentation about bitcoind and bitcoin-cli and see that this was being deprecated?

  79. luke-jr commented at 3:52 am on May 21, 2016: member

    “Deprecated” implies “being considered for removal”… (also, the negative balance thing is by design a feature of accounting, not an issue - so if it comes as a surprise I wonder on the reliability of whatever docs you used)

    The accounting RPC methods have been marked in bitcoind’s internal documentation (bitcoin-cli help ) for a number of releases now, and were mentioned as such in the release notes for at least the first release deprecating them.

  80. fbnz156 commented at 4:46 am on March 5, 2017: none

    Sorry to gravedig this issue. I’ve noticed that all of the accounting features have been marked as deprecated and marked for removal; Personally I’m fine with many of them disappearing such as SendFrom, GetBalance etc as I can implement these myself when they’re eventually removed.

    The thing which concerns me is that, short of storing every single generated address in my own database and mapping it against an account ID, I won’t be able to determine when a payment has been sent to one of the generated addresses. I’ve read that the label feature (I assume the same one that’s present in the Receive tab of BitcoinQt) could be the replacement; is there any update on this? If so what RPC functions would be updated to support the label feature?

  81. pstratem commented at 5:16 am on March 5, 2017: contributor

    storing every single generated address in my own database and mapping it against an account ID

    You should be doing exactly that. (invoice id more correctly, but close enough probably).

  82. fbnz156 commented at 5:46 am on March 5, 2017: none

    You should be doing exactly that. (invoice id more correctly, but close enough probably).

    Doing BIP32 key generation on my application itself now so that I can keep the application database backup size minimal, then just adding the generated receive addresses as watch addresses in Bitcoin Core.

    Just wondering, how many public keys can the bitcoin core client watch without falling to pieces? To my understanding the biggest scalability “hit” is when a new block is received.

  83. laanwj commented at 10:06 am on March 5, 2017: member

    is there any update on this? If so what RPC functions would be updated to support the label feature?

    Yes, see here: https://github.com/bitcoin/bitcoin/pull/7729

  84. jnewbery referenced this in commit ba8692b7d5 on Jun 12, 2017
  85. jnewbery referenced this in commit 156ead3048 on Jun 12, 2017
  86. jnewbery referenced this in commit 5b74e7e8eb on Jun 12, 2017
  87. laanwj referenced this in commit bd8708fab4 on Jun 14, 2017
  88. laanwj referenced this in commit 8571fee617 on Jun 29, 2017
  89. jnewbery referenced this in commit 86d8e115f9 on Sep 13, 2017
  90. gusarov commented at 9:19 pm on October 14, 2017: none
    For new software I’m not comfortable to use anything deprecated, but there is still nothing related to labels in 0.14.2 Am I right that the only proper way for today is just ‘getnewaddress’ without parameter and saving this to my db for the user that is associated with this address?
  91. ryanofsky referenced this in commit 90250d98e0 on Oct 21, 2017
  92. ryanofsky referenced this in commit 1dbfe49c48 on Oct 21, 2017
  93. ryanofsky referenced this in commit 7924a22a76 on Oct 21, 2017
  94. ryanofsky referenced this in commit e349abbe5e on Oct 21, 2017
  95. ryanofsky referenced this in commit b854badace on Oct 23, 2017
  96. ryanofsky referenced this in commit 5ee1c2e705 on Dec 1, 2017
  97. ryanofsky referenced this in commit 55f7b663c8 on Dec 1, 2017
  98. ryanofsky referenced this in commit a94075a424 on Jan 6, 2018
  99. ryanofsky referenced this in commit c7499fdd9f on Jan 11, 2018
  100. ryanofsky referenced this in commit a4291c5695 on Jan 17, 2018
  101. ryanofsky referenced this in commit 11c5e2d5a3 on Jan 18, 2018
  102. ryanofsky referenced this in commit c5a7f9ddeb on Jan 25, 2018
  103. ryanofsky referenced this in commit bcff61bedc on Feb 12, 2018
  104. ryanofsky referenced this in commit 55c5289acb on Mar 7, 2018
  105. ryanofsky referenced this in commit 2198ddaebd on Mar 15, 2018
  106. ryanofsky referenced this in commit dd425a0dad on Mar 19, 2018
  107. ryanofsky referenced this in commit 1141a32e91 on Mar 23, 2018
  108. ryanofsky referenced this in commit 6a0d27412d on Mar 23, 2018
  109. jnewbery referenced this in commit a8d607dda8 on Apr 5, 2018
  110. jnewbery referenced this in commit c733a983bc on Apr 5, 2018
  111. jnewbery referenced this in commit cec0de8723 on Apr 6, 2018
  112. jnewbery referenced this in commit 1f7f1dfd1c on Apr 7, 2018
  113. jnewbery referenced this in commit 0277f2dd0f on Apr 9, 2018
  114. jnewbery referenced this in commit 8bf0a96018 on Apr 9, 2018
  115. jnewbery referenced this in commit cd62be8583 on Apr 10, 2018
  116. jnewbery referenced this in commit 62cad4c90c on Apr 10, 2018
  117. jnewbery referenced this in commit 3d42c91fac on Apr 10, 2018
  118. jnewbery referenced this in commit 7222d0b8ea on Apr 10, 2018
  119. jnewbery referenced this in commit 189e0ef33e on Apr 10, 2018
  120. laanwj referenced this in commit 9b3370d1c6 on Apr 11, 2018
  121. jnewbery commented at 7:11 pm on April 11, 2018: member
    Suggest we close this since it’s very old and unwieldly. This issue contains useful historic context, but concrete actions to remove the ‘account’ API can be tracked in #12952.
  122. MarcoFalke closed this on Apr 11, 2018
  123. int03h commented at 7:36 pm on April 11, 2018: none
    Yeah. I think much water has flowed under this bridge. I see from #12952 it’s still not deprecated, but at least the intent to deprecate is formally stated. New implementations will be at your own perl. Good enough for me.
  124. stamhe referenced this in commit c794a93d2f on Jun 27, 2018
  125. HashUnlimited referenced this in commit 34d278812b on Sep 5, 2018
  126. lionello referenced this in commit 6ddd4c502f on Nov 7, 2018
  127. joemphilips referenced this in commit b7f1086134 on Nov 9, 2018
  128. MarcoFalke locked this on Sep 8, 2021


jgarzik gavinandresen ghost laanwj bananas2 gmaxwell bf0d7998-81ec-48d1-b236-076ed3c77581 luke-jr int03h benjiqq sipa PierreRochard felipecsl rnicoll dgenr8 jtimon pstratem jonasschnelli dooglus mikegogulski kladivo BamaStangGuy fbnz156 gusarov jnewbery

Labels
Brainstorming Wallet

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-18 18:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me