Re: [bitcoin-dev] [BIP proposal] Private Payments
Hi Bryan, >just publishing on a tor hidden service that other wallets check The problem is that this data is critical to access the funds. By putting it on-chain you're guaranteeing that it's always available when you restore your funds from backup. Cheers, Ruben On Mon, Jun 27, 2022 at 10:21 PM Bryan Bishop via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 2. Notification transactions still exist but no longer leave a privacy >> footprint on the blockchain. Instead, a notification transaction is simply >> a single OP_RETURN containing a value that only Alice and Bob can >> calculate. If Alice's notification transaction uses UTXOs not associated >> with her identity, there is never a footprint showing that either her or >> Bob are using private payments. If Alice uses tainted coins, only she is >> exposed as a user of Private Payments but Bob still isn't. >> > > That's a neat trick. What about not using OP_RETURN at all, and just > publishing on a tor hidden service that other wallets check? Alice > wouldn't have to expose on-chain that she is a sender of a private payment. > > - Bryan > https://twitter.com/kanzure > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP proposal] Private Payments
Hi Alfred, Thanks for taking the time to write a proposal. >The inability of payment codes to explicitly state which address types they derive places a burden on more resource constrained wallets I agree it's not as efficient as it could be, but how big is this problem in practice? Expecting payments on more addresses doesn't seem like a huge overhead. Or are you talking about the hassle of having to support spending from all these address types? >a notification transaction is simply a single OP_RETURN containing a value that only Alice and Bob can calculate This seems to be the meat of the proposal. You're hiding the intended recipient, but in doing so you introduce a scanning requirement. Of course you only need to scan notification transactions, so it'll be much less heavy than Silent Payments*, but it does make it rather difficult to support light clients. If some degree of scanning is acceptable, then Robin Linus' scheme may be an interesting alternative: https://gist.github.com/RobinLinus/4e7467abaf0a0f8a521d5b512dca4833 The basic idea is that everyone publishes a single pubkey on-chain, and everyone derives a shared secret with everyone else's pubkey. It also requires "scanning", but the number of transactions will be lower as it's one tx per new pubkey as opposed to one tx per sender/recipient pair. This also means it uses far less block space. The main downside is that you have to watch as many incoming addresses as there are registered pubkeys, but this could be indexed relatively efficiently. Also not light client friendly, though. And then of course there's the recent BIP47 discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020549.html This proposes to outsource the publishing of the notification transaction in order to break the link (as well as reduce block space usage). There's no scanning, so this preserves light client support, but the downside here is that you now need to anonymously pay a third party (e.g. over LN). >demand that a notification transaction meets some minimum miner fee Note that this mechanism is not safe against miners, as they can pay themselves arbitrarily high fees with no downside. Hope this helps. Cheers, Ruben *Silent Payments: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8 On Mon, Jun 27, 2022 at 9:14 PM Alfred Hodler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > There have been attempts to create static payment codes that function as a > way for transacting parties to create "private" addresses, where private > stands for "known only to transacting parties". BIP47 was one such standard. > > The standard suffered from a number of problems: > > 1. The standard promised extensibility through versioning but it never > used that capability to follow innovations in the Bitcoin protocol. It was > designed around the idea that legacy p2pkh addresses would always be the > primary and only way to transact. As new standard script types started to > emerge (Segwit v0, Taproot), the creators dealt with the problem by stating > that implementing wallets should scan for all existing standard scripts. > The inability of payment codes to explicitly state which address types they > derive places a burden on more resource constrained wallets. > > 2. The standard relied on a notification mechanism in order to connect a > sender with a recipient, which included either offchain technology > (Bitmessage), or so called "notification addresses" which a) left a > footprint b) created toxic change. That type of footprint is particularly > harmful because it makes it obvious that a particular recipient is going to > receive private transactions. If the notifying party performs this process > with coins linked to its identity (i.e. tainted or non-anonymized inputs), > it forever becomes visible that Alice connected with Bob despite the fact > that her payment code was blinded. While future transactions and their > amounts aren't visible, this metadata makes it possible to build a social > graph. > > 3. The standard was implemented only by an entity that disavowed the BIP > process and didn't wish to use it to keep the standard up to date. Further > updates did take place but only outside the BIP process, creating a lack of > clarity as to what the real specification is. Ultimately the standard was > abandoned. > > I propose to build on the idea of payment codes under a new BIP with the > following principal differences: > > 1. The new standard will allocate a 2-byte bitflag array that will signal > address/script types that the receiver is deriving. Since the vast majority > of scripts are p2pkh (47.3%) and p2wpkh (26.2%), bits 0 and 1 will be used > for those respectively. Bit 2 will be p2tr. The remaining 13 bits are > reserved for future standard script types. > > 2. Notification transactions still exist but no longer leave a privacy > footprint on the blockchain. Instead, a notification
Re: [bitcoin-dev] [BIP proposal] Private Payments
Hi, On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 2. Notification transactions still exist but no longer leave a privacy > footprint on the blockchain. Instead, a notification transaction is simply > a single OP_RETURN containing a value that only Alice and Bob can > calculate. If Alice's notification transaction uses UTXOs not associated > with her identity, there is never a footprint showing that either her or > Bob are using private payments. If Alice uses tainted coins, only she is > exposed as a user of Private Payments but Bob still isn't. > That's a neat trick. What about not using OP_RETURN at all, and just publishing on a tor hidden service that other wallets check? Alice wouldn't have to expose on-chain that she is a sender of a private payment. - Bryan https://twitter.com/kanzure ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] [BIP proposal] Private Payments
Hi, There have been attempts to create static payment codes that function as a way for transacting parties to create "private" addresses, where private stands for "known only to transacting parties". BIP47 was one such standard. The standard suffered from a number of problems: 1. The standard promised extensibility through versioning but it never used that capability to follow innovations in the Bitcoin protocol. It was designed around the idea that legacy p2pkh addresses would always be the primary and only way to transact. As new standard script types started to emerge (Segwit v0, Taproot), the creators dealt with the problem by stating that implementing wallets should scan for all existing standard scripts. The inability of payment codes to explicitly state which address types they derive places a burden on more resource constrained wallets. 2. The standard relied on a notification mechanism in order to connect a sender with a recipient, which included either offchain technology (Bitmessage), or so called "notification addresses" which a) left a footprint b) created toxic change. That type of footprint is particularly harmful because it makes it obvious that a particular recipient is going to receive private transactions. If the notifying party performs this process with coins linked to its identity (i.e. tainted or non-anonymized inputs), it forever becomes visible that Alice connected with Bob despite the fact that her payment code was blinded. While future transactions and their amounts aren't visible, this metadata makes it possible to build a social graph. 3. The standard was implemented only by an entity that disavowed the BIP process and didn't wish to use it to keep the standard up to date. Further updates did take place but only outside the BIP process, creating a lack of clarity as to what the real specification is. Ultimately the standard was abandoned. I propose to build on the idea of payment codes under a new BIP with the following principal differences: 1. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Since the vast majority of scripts are p2pkh (47.3%) and p2wpkh (26.2%), bits 0 and 1 will be used for those respectively. Bit 2 will be p2tr. The remaining 13 bits are reserved for future standard script types. 2. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Instead, a notification transaction is simply a single OP_RETURN containing a value that only Alice and Bob can calculate. If Alice's notification transaction uses UTXOs not associated with her identity, there is never a footprint showing that either her or Bob are using private payments. If Alice uses tainted coins, only she is exposed as a user of Private Payments but Bob still isn't. 3. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process (BIP47 is a good example of that). 4. Relying on static compressed pubkeys as opposed to extended keys means shorter payment codes. ==Proposed Payment Code Structure== bytes 0-1: - enabled (watched) address types (16 possible address types) bytes 2-35: - compressed public key P ==Encoding== A payment code is encoded in base58check and the version byte produces "S" for the first character. A code might look like "SwLUHs3UfMUXq956aXLTUPPfow7a8gDfSUUAtafwqHcobf6mKcMbJk". ==Pubkey Derivation== Recipient's payment code pubkey `P` is derived from a master key using the following path: `m/purpose'/coin_type'/account'`. `purpose` will be defined once a BIP number is assigned. Its corresponding private key is `p`. Notifier/sender's pubkey `N` is derived using the following derivation path: `m/purpose'/coin_type'/account'/*`, where each recipient gets a new index. This way send-side privacy is always preserved. Its corresponding private key is `n`. ==Notifications== Alice wants to notify Bob that he will receive future payments from her. Alice selects any UTXO in her wallet (preferably not associated with her) and `n_Alice`. Alice selects the public key contained in Bob's payment code `P_Bob`. Alice performs the following process (`*` and `+` are EC operations): notification = SHA256(n_Alice * P_Bob) Alice then constructs a 72-byte OP_RETURN output whose value is set to `BIP + notification + N_Alice` (`+` is concat) and sends it in a transaction containing no other outputs ( to be replaced once a BIP number is assigned). Alice MUST now keep track of `n_Alice` or its derivation path as it will be used in future transactions exclusively with Bob (not for spending but to calculate secret addresses). Bob's wallet receives whole blocks but doesn't need to waste resources on decoding them if the environment is resource constrained. Bob simply needs find the string BIP in the
Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
On June 27, 2022 8:03:38 AM EDT, Greg Sanders wrote: >One key difference seems to be that properly punishing someone based on >mempool behavior seems much more difficult. As we all know there is no "the >mempool". No, that's not relevant here: the DoS condition is the existence of a (mined) double spend for a given txout used in a coin join. That condition is entirely under the control of the wallet, and can be totally avoided by the wallet regardless of mempool behavior. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security
One key difference seems to be that properly punishing someone based on mempool behavior seems much more difficult. As we all know there is no "the mempool". On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sun, Jun 26, 2022 at 04:40:24PM +, alicexbt via bitcoin-dev wrote: > > Hi Antoine, > > > > Thanks for sharing the DoS attack example with alternatives. > > > > > - Caroll broadcasts a double-spend of her own input C, the > double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal > opt-in RBF > > > - Alice broadcasts the multi-party transaction, it is rejected by the > network mempools because Alice double-spend is already present > > > > I think this affects almost all types of coinjoin transaction including > coordinator based implementations. I tried a few things and have already > reported details for an example DoS attack to one of the team but there is > no response yet. > > > > It was fun playing with RBF, DoS and Coinjoin. Affected projects should > share their opinion about full-rbf as it seems it might improve things. > > > > Example: > > > > In Wasabi an attacker can broadcast a transaction spending input used in > coinjoin after sending signature in the round. This would result in a > coinjoin tx which never gets relayed: > https://nitter.net/144bytes/status/1540727534093905920 > > Note that Wasabi already has a DoS attack vector in that a participant can > stop > participating after the first phase of the round, with the result that the > coinjoin fails. Wasabi mitigates that by punishing participating in future > rounds. Double-spends only create additional types of DoS attack that need > to > be detected and punished as well - they don't create a fundamentally new > vulerability. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
