Implement Confidential Transactions/Bulletproofs #12129

issue nopara73 openend this issue on January 9, 2018
  1. nopara73 commented at 2:54 am on January 9, 2018: none

    Following up on the issue: Improve transaction privacy / fungibility in Bitcoin Core and the Bitcoin system, this issue may serve as feature request, meta tracking and consensus builder thread on Confidential Transactions/Bulletproofs.

    Privacy is a fundamental human right and fungibility is an essential property of good money. Our lack of ability of masking transaction output amounts is the root of all evil in every Bitcoin privacy scheme, where Confidential Transactions/Bulletproofs tackles this issue.

    While the development and research on Confidential Transactions may or may not be in early stages, it is not too early to explore how much support and opposition the development community has on this soft fork.

  2. fanquake added the label Privacy on Jan 9, 2018
  3. sipa commented at 9:09 am on January 9, 2018: member
    I don’t believe this is the right place to discuss this.
  4. nopara73 commented at 3:15 pm on January 9, 2018: none
    @sipa I believe it is. Historically all soft forks started by a PR to this repository. If a PR gets merged or not is determined by the consensus of the contributors here. Thus, seeking feedback on other platforms, like the mailing list, is less effective to measure the general sentiment of the contributors of this sub towards CT, this is the best place.
  5. sipa commented at 3:32 pm on January 9, 2018: member

    Historically all soft forks started by a PR to this repository.

    That hasn’t been the case for years.

    If PR gets merged or not is determined by the consensus of the contributors here.

    It mostly depends on confidence the ecosystem will adopt a change.

    Thus, seeking feedback on other platforms, like the mailing list, is less effective to measure the general sentiment of the contributors of this sub towards CT, this is the best place.

    That may be the case for implementation details, but there isn’t even a vague proposal for how this would work. Asking software contributors (of a single project) for feedback on a vague idea seems like the wrong place to start.

  6. sipa closed this on Jan 9, 2018

  7. nopara73 commented at 4:02 pm on January 9, 2018: none

    That hasn’t been the case for years.

    There was only a few occasions when a proposal ended up having adoption without Bitcoin Core PR. The disastrous forks, like BCH, and UASF, which we have never seen its direct outcome.

    It mostly depends on confidence the ecosystem will adopt a change.

    Opening an issue here is part of exploring the confidence you are talking about.

    That may be the case for implementation details, but there isn’t even a vague proposal for how this would work.

    That may be the case, however the issues secion of this repository is full of feature requests and meta threads, I don’t see why this case is different, in fact the very first link in my first comment is such kind (labelled with brainstorming), and that even links to similar ones.

  8. sipa commented at 4:06 pm on January 9, 2018: member

    There was only a few occasions when a proposal ended up having adoption without Bitcoin Core PR.

    That’s not the point. Of course at some point there will be a PR; if the network adopts CT, I’m sure Core will implement it.

    You’re however claiming that a PR to Core is how soft fork proposals start. I think that’s both not historically true, nor advisable.

    I’ll reopen this, waiting for input from other contributors. But generally I think we’ve always closed issues of the form “implement some consensus change” before there is a clearly vetted proposal.

  9. sipa reopened this on Jan 9, 2018

  10. Shic1983 commented at 0:45 am on January 13, 2018: none
    Personally i find github a much better medium to read these kinds of proposals and discussions than mailing list, which has a shit format to read on the web and irc, wherever the logs for that are. I want to see CT on bitcoin, bitcoin right now is like the twitter of finance, literally no privacy at all. Terrible. I think this kind of upgrade is really important.
  11. manginahunter commented at 0:46 am on January 13, 2018: none
    In short you wait there is demand for it before PR it here ? So if BTC is invaded by statist nobody will ask for such features… Are you aware of the recent Bitfury research ? Well they publish it publicly good on them. But that’s quite scary no ? That kind of change will be probably UASF’ed for obvious reasons that some entities find quite interesting to track you satoshi by satoshi.
  12. nopara73 commented at 2:04 am on January 13, 2018: none

    @manginahunter I know I am dangerously going into off topic territory here, but let me share some thoughts on the Bitfury research:

    From a technical point of view the Bitfury research was especially uninteresting. It didn’t add anything new to the privacy conversation, that wasn’t already known. I agree, that it was misleading, because 1. it was conducted by a well-known company and 2. they used a language that implies they came up with new, previously unknown things. I’ve even heard someone having the takeaway from it, that “Bitfury invented clustering”.
    For a better quality research on the same topic, see the paper: When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies.

    With that said , what was especially worrisome about it, is that Bitfury actually plans to utilize the methods. However they don’t have an edge on present day Blockchain analysis companies, because they may don’t write research on their methods, they know all the basic things the Bitfury paper talks about, and they have already been collecting various metadata (like Bloom filters) for years now.

    In the end, it all comes down to sales. Having home grown research papers gives Bitfury credibility and opportunities, so they claim their expertise on a specific domain.

  13. manginahunter commented at 4:59 am on January 15, 2018: none
    Just read about your analysis on your link above. That’s reassuring but still think the more privacy tools the better.
  14. jnewbery commented at 5:15 pm on January 22, 2018: member
    I agree that github issues are inappropriate for ‘meta tracking and consensus builder threads’. The bitcoin-dev mailing list is a much more appropriate venue. Recommend we close this until there’s a concrete proposal.
  15. nopara73 commented at 2:49 am on January 25, 2018: none
    @jnewbery Consider it as feature request.
  16. TheBlueMatt commented at 3:56 pm on January 28, 2018: member

    Yes, can we just close this? I think should generally avoid opening issues with medium-/long-term feature requests, as we generally lose track of them and they just end up open for years. Also, consensus-level discussion doesn’t belong on this repo. If you want to use GitHub to access bitcoin-dev, you could build a wrapper that converts emails to GitHub posts and back.

    On January 25, 2018 2:50:02 AM UTC, nopara73 notifications@github.com wrote:

    @jnewbery Consider it as feature request.

    – You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/12129#issuecomment-360344548

  17. MarcoFalke commented at 4:17 pm on January 28, 2018: member
    The discussion seems to derail into a meta discussion about tracker issues. Going to close for now
  18. MarcoFalke closed this on Jan 28, 2018

  19. MarcoFalke locked this on Sep 8, 2021

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-21 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me