Improve fungibility in Bitcoin system via decentralized exchange development in reference client #10494

Recently a survey / poll was published on bitcointalk on the topic of whether code for a decentralized exchange should be developed for bitcoin core.

The survey / poll (multiple choice) was conducted over the course of a total of seven days and the results were as follows:

• The survey / poll question was: "Satoshi included prelim code for decentralized exchange in #bitcoin, but it was removed after Satoshi's departure. Should it be put back in?"
• There were 82 respondents
• 61% selected "Yes, add to bitcoin core"
• 22% responded "No, let alts try that 1st"
• 17% responded "Neither, I use bitsquare"

The interest in having a decentralized exchange of some sort appear in core / reference client(s) prompted me to open this issue for discussion.

1) History / background

Preliminary code authored by Satoshi relating to this topic was at one time present in bitcoin core, but was removed on February 14, 2010 by "non-github user." The code was not functional as a decentralized exchange or market, but appeared to have been provided with that idea in mind. Satoshi retired from active / public bitcoin development, after the release of version 0.3.19 which was in December 2010.

2) A suggested definition

It may be, that with the various approaches to what a "decentralized exchange" is, some qualifications or a definition should be provided before discussing this further.

A truly "decentralized exchange" in my view is one that has the following characteristics:

a) Must be p2p -- must rely on software you install and communicates with other computers that also have that software (not requiring servers or services), and must not require you to obtain some special token(s) in order to use it or to exchange one thing for another. Good examples of the decentralized exchange are bitsquare / bisq and mercury. Good example of the decentralized market is openbazaar.

b) may require you to identify yourself in some way on the network at such times when you are participating in the exchange system (example being through use of a PGP key or through a bitcoin based identifier) to limit identity spamming and to allow users to build reputation

c) must not be based upon I2P in order to work, must not be based upon some Tor hidden service, and must not require WebRTC, but may provide Tor or I2P support

d) must not require ShapeShift (or some other third party) in order to provide functionality

e) must provide an option for users to exchange fiat for cryptocurrency (not solely some crypto for bitcoin) and to do so without exposing themselves to (bank or non-bank institutions, organizations, services).

3) Limitations (cons) of having decentralized exchange in Core or other reference clients (in other cryptos), and some other perspectives (pros)

One simple con of this idea would be "feature bloat" is not desireable for Core. In some alts, features have been explored and added to the extent they have been able to do so or depending upon the priority of the development schedule of certain alts. However, in Core, "feature bloat" has generally been avoided.

One pro of this idea would be the potential for greater fungibility as a result. This is further discussed in item (4) below. Another potential pro of this idea would be if an exchange in Core were to be developed utilizing features of Lightning, which is not yet implemented in Core, then there would be available (in part) rapid payments, no third-party trust, reduced blockchain load, and onion-style routing. Notably, in this particular scenario, due to the features of Lightning / lnd, "payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks." (as quoted from bitcoinwiki on Lightning)

In other words, with eventual Segwit activation and potentially down the road with Lightning implementation, there would likely be an evolution toward something like a decentralized exchange at any rate as a result of the features of Lightning. The question then becomes, how would this be integrated into Bitcoin Core.

4) Reference to other bitcoin issue relating to fungibility

In this issue a reference is being made to #6568 due to the fungibility item being discussed in that issue [which was published for meta tracking issues on transaction privacy / fungibility]. In that issue description, it was mentioned in part that "Tightly linked to privacy is fungibility, an essential characteristic of a money like good. When coins are overly distinguishable and people find themselves feeling obligated to consult (likely centralized) blacklists before accepting coins the utility of Bitcoin as a money is reduced." Because a truly decentralized exchange does contribute to the protection of fungibility, that issue is being referred to in part here.

5) Conclusion

There may be an opportunity to improve fungibility in Bitcoin system via decentralized exchange development in reference client down the road, particularly with the evolution and trajectory of developments such as Segwit and Lightning. There are definitely pros and cons to this concept and it is worth a discussion.

All discussion and points of view are welcome on this issue. Thanks in advance for comments you might contribute on this item.

This should be moved to the bitcoin-core-dev mailing list or maybe to the bitcoin-dev mailing list (if the ecosystem and not only Core is involved).

Are you going to build and implement this yourself and requesting comments for that purpose? Only if that is the case we should leave this open.

This, however, is not the place for leaving long write-ups of vague things that would be nice, in the hope someone else implements them. I suggest publishing those ideas on the bitcoin-dev or bitcoin-core-dev mailing list, or even publishing them in a place of your own like a blog.

Responding to the above points, @jonasschnelli Personally I would prefer that it remain open here for a while, to allow more people to comment.

A long while ago I made an active decision not to further participate in bitcoin-dev mailing list. I do not participate in (publish to or comment upon) items in bitcoin-dev or bitcoin-core-dev.

I'm not opposed to the idea of this issue being moved to bitcoin-core-dev mailing list, but at that point I would no longer be a participant in the discussion. While it is active on github, I would be able to make comments here and at some point contribute.

If you do move it to bitcoin-core-dev etc., please provide a link to this issue or simply copy the text of the issue description so as to include the originally provided material including proposed definition and reasonings I have originally submitted.

Regarding the question of if the ecosystem and not only Core is involved, my sense is that this is really an issue for Core development. But, as I suggest in the Conclusion of the issue, fungibility in Bitcoin in fact may be improved by just such an effort, "particularly with the evolution and trajectory of developments such as Segwit and Lightning." So there would potentially be indirect effects that would be positive for fungibility. @laanwj I would like to contribute some code for this purpose (would like to be a contributor on something related to this issue), but my own assessment of it is that it would most likely be viable for Core "down the road" as I have suggested, when not only Segwit but as well Lightning have been incorporated, primarily for the reasons of the features of Lightning / lnd, including of course "payments (being) routed across more than one blockchain (including altcoins)" and "onion-style routing."

A brief note about your comment on the length of the write-up. Had I simply provided a short write-up and not specified really any reasons why I was suggesting this, I would have been subjected to criticism that there was no reason being provided for why this should even be considered at all. The longer write-up made sense in this context. I would also point out that there are various other issues with lengthy write-ups, for which there is good reason for doing so. One example is the issue titled "Improve transaction privacy / fungibility in Bitcoin Core and the Bitcoin system [meta tracking issues]," #6568 authored by @gmaxwell which I have linked to as part of this issue description for reasons of discussion relating to fungibility. Note that there have been no pull requests in that issue but there has been productive discussion, some of which could eventually lead to a pull request.

It is my intent to continue to encourage productive and respectful discussion on this issue so long as it is open.

Does this need to remain open? @ABISprotocol