Re: [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation
Hi Pieter, Let me put change (1) into my own words. We are already computing affine coordinates since we store public keys as the affine x-coordinate. It is faster to compute is_even(y) than is_quadratic_residue(y) so we get a speed up here during keypair generation. In the verification algorithm, we do the following for the public key x_only => affine + negate if not is_even(y) => jacobian. The minor slowdown in verification comes from the extra evenness check and possible negation which we didn't have to be done in the previous version. This seems like a reasonable change if it makes things easier for existing code bases and infrastructure. With change (2), I feel like including this auxiliary random data is overkill for the spec. For me, the main point of the spec is the verification algorithm which actually affects consensus. Providing a note that non-deterministic signatures are preferable in many cases and here's exactly how you should do that (hash then xor with private key) is valuable. In the end, people will want several variations of the signing algorithm anyway (e.g. pass in public key with secret key) so I think specifying the most minimal way to produce a signature securely is the most useful thing for this document. I feel similarly about hashing the public key to get the nonce. A note in the alternative signing section that "if you pass the public key into `sign` along with the secret key then you should do hash(bytes(d) || bytes(P) || m)" would suffice for me. Despite only being included in the alternative signing section, I it would be nice to have a few of test vectors for these alternative methods anyway. Perhaps they even deserve their own BIP? Cheers, LL On Mon, Feb 24, 2020 at 3:26 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello list, > > Despite saying earlier that I expected no further semantical changes > to BIP 340-342, I've just opened > https://github.com/bitcoin/bips/pull/893 to make a number of small > changes that I believe are still worth making. > > 1. Even public keys > > Only one change affects the validation rules: the Y coordinate of > 32-byte public keys is changed from implicitly square to implicitly > even. This makes signing slightly faster (in the microsecond range), > though also verification negligibly slower (in the nanosecond range). > It also simplifies integration with existing key generation > infrastructure. For example BIP32 produces public keys with known > even/oddness, but squaredness would need to be computed separately. > Similar arguments hold for PSBT and probably many other things. > > Note that the Y coordinate of the internal R point in the signature > remains implicitly square: for R the squaredness gives an actual > performance gain at validation time, but this is not true for public > keys. Conversely, for public keys integration with existing > infrastructure matters, but R points are purely internal. > > This affects BIP 340 and 341. > > 2. Nonce generation > > All other semantical changes are around more secure nonce generation > in BIP 340, dealing with various failure cases: > > * Since the public key signed for is included in the signature > challenge hash, implementers will likely be eager to use precomputed > values for these (otherwise an additional EC multiplication is > necessary at signing time). If that public key data happens to be > gathered from untrusted sources, it can lead to trivial leakage of the > private key - something that Greg Maxwell started a discussion about > on the moderncrypto curves list: > https://moderncrypto.org/mail-archive/curves/2020/001012.html. We > believe it should therefore be best practice to include the public key > also in the nonce generation, which largely mitigates this problem. > > * To protect against fault injection attacks it is recommended to > include actual signing-time randomness into the nonce generation > process. This was mentioned already, but the update elaborates much > more about this, and integrates this randomness into the standard > signing process. > > * To protect against differential power analysis, a different way of > mixing in this randomness is used (masking the private key completely > with randomness before continuing, rather than hashing them together, > which is known in the literature to be vulnerable to DPA in some > scenarios). > > 3. New tagged hash tags > > To make sure that any code written for the earlier BIP text fails > consistently, the tags used in the tagged hashes in BIP 340 are > changed as well. > > What do people think? > > -- > Pieter > ___ > 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
[bitcoin-dev] Fwd: BIP 340 updates: even pubkeys, more secure nonce generation
On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 2. Nonce generation > > All other semantical changes are around more secure nonce generation > in BIP 340, dealing with various failure cases: > > * To protect against fault injection attacks it is recommended to > include actual signing-time randomness into the nonce generation > process. This was mentioned already, but the update elaborates much > more about this, and integrates this randomness into the standard > signing process. > I do worry that standardizing on a non-deterministic nonce generation scheme makes the problem of private key exfiltration a much bigger concern in the application of hardware signing devices. While sorely imperfect, with a deterministic nonce scheme, we at least have the option of spot checking hardware devices to see if they are producing signatures in accordance with their specified nonce scheme. But short of providing some kind of certificate, we won't be able to do such checks against hardware devices that use the proposed synthetic nonce. (Question: can a hardware device safely output the random value 'a' it used its "certificate"? AFAIU 'a' is not considered secret data; it just needs to be not under attacker control. Should hardware wallets be encouraged to return this value?) The best way to mitigate this is to use the Nonce exfiltration protection mentioned; however there are no references on how to do this. Ideally we'd standardize this Nonce exfiltration protection scheme within this synthetic nonce scheme. However, I don't think it is worth holding this BIP up on that; it seems reasonable to introduce a new section to this BIP addressing that problem in the future. Maybe instead we can get references to more information about this Nonce exfiltration protection that is mentioned? Really I just want to do whatever we reasonably can do to avoid a world where we end up providing hardware signing devices with a hard to detect underhanded communications channel. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] A proposal for WTXID-based transaction relay
Hi all, I've been working on a proposal to add support for relaying transactions based on their wtxid, rather than just their txid. The current draft is at https://github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawiki, and for some background I'll paste the motivation section here: Historically, the INV messages sent on the Bitcoin peer-to-peer network to > announce transactions refer to transactions by their txid, which is a hash > of the transaction that does not include the witness (see BIP 141). This > has been the case even since Segregated Witness (BIP 141/143/144) has been > adopted by the network. > > Not committing to the witness in transaction announcements creates > inefficiencies: because a transaction's witness can be malleated without > altering the txid, a node in receipt of a witness transaction that the node > does not accept will generally still download that same transaction when > announced by other peers. This is because the alternative -- of not > downloading a given txid after rejecting a transaction with that txid -- > would allow a third party to interfere with transaction relay by malleating > a transaction's witness and announcing the resulting invalid transaction to > nodes, preventing relay of the valid version of the transaction as well. > > We can eliminate this concern by using the wtxid in place of the txid when > announcing and fetching transactions. > One point specifically that I'm seeking feedback on is feature negotiation: for efficiency, I think it makes sense for peers to negotiate at the beginning of a connection whether they are going to use wtxid- or txid-based, prior to announcing any transactions. To achieve this, I propose in the BIP to send a message between receiving a VERSION message and prior to sending VERACK (to nodes advertising version at least 70016) to announce support for this new feature; if both sides send it then they each know to enable it on the link. My thinking is that in general, it'd be great to use messages sent between VERSION and VERACK to negotiate features prior to fully initializing a peer connection (it's sort of a natural way to extend what we might want to send in a VERSION message, without breaking existing VERSION-message parsers). However, I don't know whether inserting a message before VERACK would break any assumptions of other software on the network, or if this is a problematic paradigm for some reason, so I'd welcome feedback here. Thanks, Suhas ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
Morning Zeeman, > I proposed before to consider splicing as a form of merged closing plus funding, rather than a modification of channel state; in particular we might note that, for compatibility with our existing system, a spliced channel would have to change its short channel ID > and channel ID, so it is arguably a different channel already. Yes but you may want alias to keep your channel routing-score across splicing, though how to do this is more LN-dev specific. > Emulating LN splices mildly makes ConJoinXT less desirable, however, as the mix takes longer and is more costly. Intuitively, a lot of Coinjoin traffic may be redirected in the future through LN when protocol matures, privacy properties may be better (though need careful analysis). Coinjoins would be only for high-amounts for which security/liquidity isn't offered by LN, and in this case time for increasing privacy is IMO an acceptable tradeoff. > Does not Electrum do RBF by default? Dunno, for more context on RBF and its controversies see https://bitcoincore.org/en/faq/optin_rbf/ (or Optech resources) > 1.5RTT with MuSig Yes right I meaned you don't need to assume latter interactivity if it's a multi-party tx construction you sign multiple RBF versions at same time. Still need to think about privacy-preserving fee bumping wrt to mempool observer > This can be mitigated if all participants contribute equal or nearly-equally to the fees, though that complicates single-funding, and may violate Initiator Pays Principle (the initiator of an action should pay all fees related to the action, as otherwise it may be possible to create a null operation that the acceptor of the action ends up paying fees for, which can be used as a financial attack to drain acceptors). Yes, but also you want the acceptor to pay for its inputs announced to avoid pouring the spending burden on the initiator only, or doing any free-ride aggregation . > There may be other protocols interested in this as well --- for instance "submarine swaps" and "lightning loops", which are the same thing. Yes good point, specially batched submarine swaps are good candidates, also DLCs (will enquiry on tx pattern of more bitcoin protocol) Le lun. 24 févr. 2020 à 18:36, ZmnSCPxj a écrit : > Good morning Antoine, > > > > > On mutual closes, we should probably set `nLockTime` to the current > blockheight + 1 as well. > > > This has greater benefit later in a Taproot world. > > > > I assume mutual closes would fall under the aforementioned tx > construction proposal, so a closing may be a batch to fund other channels or > > splice existent ones. > > Ah, that is indeed of great interest. > I proposed before to consider splicing as a form of merged closing plus > funding, rather than a modification of channel state; in particular we > might note that, for compatibility with our existing system, a spliced > channel would have to change its short channel ID and channel ID, so it is > arguably a different channel already. > > > > > > A kind of non-equal-value CoinJoin could emulate a Lightning open + > close, but most Lightning channels will have a large number of blocks > (thousands or tens of thousands) between the open and the close; it seems > unlikely that a short-term channel will exist > that matches the > non-equal-value CoinJoin. > > > > That's a really acute point, utxo age and spending frequency may be > obvious protocol leaks. > > Yes; I am curious how JoinMarket reconciles how makers mix their coins vs. > how takers do; presumably the tumbler.py emulates the behavior of a maker > somehow. > > > Splicing may help there because a LN node would do multiple chain writes > during channel lifecycle for liquidity reasons but it's > > near-impossible to predict its frequency without deployment. > > Long ago, I proposed an alternative to splicing, which would today be > recognizable as a "submarine swap" or "lightning loop". > https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html > Perhaps the frequencies of those operations may hint as to how much > splicing would occur in practice in the future. > > > Even with this, I do fear an analysis gap between Coinjoin spending > delta and LN ones. A way to circumvent this would be for CoinjoinXT to > timelock its PTG > > transactions to mimick actively-spliced LN channels. That's where > adoption of a common format by other onchain transactions than LN ones > would help a lot. > > Well, one way to implement splice-in would be to have an output that is > first dedicated to the splice-in, and *then* a separate transaction which > actually does the splice-in. > This has a drawback of requiring an extra transaction, which wins us the > facility to continue operation of the channel even while the splice-in > transactions are being confirmed while retaining only one state. > (the latest proposal, I believe, does *not* use this construction, and > instead requires both sides to maintain two sets of states, with on
[bitcoin-dev] node-Tor - phases 4 and 5
Please see the current status here: https://github.com/Ayms/node-Tor#phases-and-funding Quick reminder: this is a javascript implementation of the Tor protocol inside nodes and browsers Phase 4 (evented pipes) has been developped (self funded) but is not fully tested/released, however the doc is here: https://github.com/Ayms/node-Tor/blob/master/docs/README.md, it allows to simply anonymize any protocol piping it to the Tor protocol We were about to implement phase 5 (elliptic crypto, Tor v3 features and WebRTC) but are running out of funding, while we have self funded the vast majority of this project since 2012 we can't continue (thanks to NLnet for supporting phases 1 to 3) and are looking for funding to complete this work (cf above link) The timing is supposed to be now because restarting such a project in months or years is not trivial and despite of the huge efforts for the refactoring/update/cleaning of the initial code and split into modules it's probably still difficult to use/integrate/modify (see https://github.com/Ayms/node-Tor/issues/14), it will become quite easy if the project goes to its targeted phase The code is subtle and minimal, it represents only 1MB browserified not minified, so 500kB minified, which is quite small for what it does with zero external dependencies, redevelopping everything from scratch would be long and difficult Some examples of what node-Tor does (as nodes or inside browsers using WebSockets/WebRTC/XHR): http.pipe(parser).pipe(gzip).pipe(tls).pipe(node-Tor) ipfs.pipe(node-Tor) webtorrent.pipe(node-Tor) bitcoin | node-Tor | bitcoin (via stdin/stdout or using IPC) Of course the Tor protocol itself might not be enough and each project might have to design the full anonymization system (peer discovery, introduction, etc) but they can rely on node-Tor to implement the Tor protocol (not to be misunderstood again with the Tor network) It does implement direct p2p via the Tor protocol or via RendezVous (RDV) points using also Tor protocol hops to connect to them, the peers advertise what they have or do using a hash to the RDV points they are connected to, please see https://github.com/Ayms/node-Tor#phase-4-and-phase-5 Example: by convention a bitcoin node could advertise a hash of "Satoshi Nakamoto" to tell it is a bitcoin node, then bitcoin nodes will connect to each others via RDV points or several Tor protocol hops requesting this hash, they can also connect directly via several hops for well known bitcoin nodes that don't need to hide themselves but want to hide to whom they are connected to, which can be wallets too, for example to hide who originated a transaction Since peers are implementing both direct p2p and RDV functions (both via Tor protocol hops), and can extend to other peers as peers or RDV points again, it becomes difficult to understand who is doing what and how many hops finally are used between the peers (suggested setting for p2p is 2 hops instead of 3 for a Tor protocol circuit, knowing that the number of hops can extend via RDV points) This is the current design and can of course be adapted It would look logical that this techno is integrated natively one day inside browsers, again it must not be misunderstood with what the Tor Browser is doing (with many specific features inside the browser itself) and is not a replacement for it, this is different but could be used also by the Tor network with browsers acting as real Tor nodes (a bit à la Snowflake but not only relaying messages via WebRTC, implementing the Tor protocol inside browsers), or uproxy-like for those that remember it -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
