Re: [bitcoin-dev] Overhauled BIP151
Without commenting on the other merits of either proposal, the addition of the service flag resolves bip151’s previously-discussed lack of backward compatibility. e > On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev > wrote: > > Hi > > During work on the implementation of BIP151 [1] I figured out that the current > published proposal could be further optimized. > > I wrote an overhauled BIP151 specification with some – partially radical – > changes. > > Now it’s unclear to me if this should be published under a new BIP nr. or if > it > is acceptable to change the existing 151 proposal. > If a new BIP number would be required, I think withdrawing BIP151 should be > done (which somehow indicates we should alter 151). > > The only BIP151 implementation I’m aware of is the one from Armory [2]. > BCoins implementation has been removed [3]. > > The new proposal draft is available here: > https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52 > > Major changes > = > - the encryption handshake no longer requires the v1 protocol, it’s a pure > 32bytes-per-side „pseudorandom" key exchange that happens before anything > else. > - the multi message envelope has been removed. > - a new NODE_ENCRYPTED service bit > - the key derivation and what communication direction uses what key is now > more > specific > - the length of a packet uses now a 3-byte integer with 23 available bits > - introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which > result in > some v2 messages require less bandwidth then v1 > - rekeying doesn’t require a message and can be signaled in the most > significant bit in the packet-size field > > > Points that are in discussion and may be added to the BIP (or to a new one): > > Hybrid NewHope key exchange > === > The current ECDH key exchange is vulnerable to Shor’s algorithm and is thus > not > considered quantum-safe. > Following TORs approach [4] by adding a NewHope [5] key-exchange the handshake > protocol would very likely make the encryption PQ safe with little costs. > There is also a straight forward implementation [6] from the NewHope team that > has been submitted to NIST PQC project. > > Inefficiency of ChaCha20Poly1305@openssh > > The proposed AEAD could eventually be further optimized. > ChaCha20Poly1305@openssh uses at least three rounds of ChaCha20 which > eventually can be reduced to two (messages below <=64 bytes [inv, ping, > pong,...] only require one round of ChaCha20, but two for the Poly1305 key and > the message length encryption where the Poly1305 key chacha round „throws > away“ > 32 bytes). > > > I would suggest that we don’t rehash discussions about the general > concept of encrypting the traffic. This has already been discussed [7][8]. > > I hope we can limit this thread to discuss further ideas for optimisation as > well as > technical details of the published proposal or its implementation. > > > [1] https://github.com/bitcoin/bitcoin/pull/14032 > [2] https://github.com/goatpig/BitcoinArmory/pull/510 > [3] > https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd439300708e662 > [4] > https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope > [5] https://eprint.iacr.org/2015/1092 > [6] https://github.com/newhopecrypto/newhope > > [7] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013565.html > [8] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html > > > Thanks > ___ > 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] SIGHASH2 for version 1 witness programme
Johnson Lau writes: > Great, I’ll revise it. > > Follow-up questions: > > 1. Is there any useful case which one would like to use NOINPUT with > scriptCode and/or scriptPubKey committed? (Note that with > taproot/MAST, scriptCode and scriptPubKey are not > interchangeable. scriptPubKey commits to all branches, and scriptCode > is just one script branch). If yes, we could make this configurable. There is the poor man's malleability fix that you get if you make only the previous outpoint rewritable, but that use-case is better covered by segwit already, and since both of our proposals would be for segwit outputs only, I don't see a point in doing that. > 2. Which of the following approaches is better? > A) sign scriptPubKey in every cases except NOINPUT > B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every > cases, including NOINPUT > C) all of the above > D) none of the above What do we effectively gain by committing to the scriptPubkey type? Is the concern here that we might run into ambiguity about whether this is a MAST, P2SH, or similar output, allowing an attacker to sideload unwanted effects? > Option B is very easy to implement as SignatureHash() could > distinguish the type by the size of scriptSig in TxTo. Option A is > more complicated as GenericTransactionSignatureChecker needs to know > the scriptPubKey. > > If the only reason for doing this is to allow hardware wallet to > distinguish the segwit type, option B is probably enough. This is also > compatible with eltoo. Agreed on compatibility :-) > Option A is useful when a hardware wallet reuses the same public key > in different scripts, but it couldn’t be applied to NOINPUT > > 3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use > NOINPUT|SINGLE to allow fee pumping, since it is an > one-input-one-output tx. This is not possible with the existing LN as > the tx is one-input-two-output. If we had DUALOUTPUT which signs the > matched and last output, fee-pumping would be possible in the existing > LN. That's a very strange concept, but it strongly relies on the structure of the commitment, having two outputs. As soon as we have HTLCs included in the commitment we no longer have 2 outputs (2 for the endpoints, and 1 as a base for the two-phase HTLC resolution), so this would be a rather brittle fix or would require major restructuring of LN imho. Cheers, Christian ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Overhauled BIP151
Hi During work on the implementation of BIP151 [1] I figured out that the current published proposal could be further optimized. I wrote an overhauled BIP151 specification with some – partially radical – changes. Now it’s unclear to me if this should be published under a new BIP nr. or if it is acceptable to change the existing 151 proposal. If a new BIP number would be required, I think withdrawing BIP151 should be done (which somehow indicates we should alter 151). The only BIP151 implementation I’m aware of is the one from Armory [2]. BCoins implementation has been removed [3]. The new proposal draft is available here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52 Major changes = - the encryption handshake no longer requires the v1 protocol, it’s a pure 32bytes-per-side „pseudorandom" key exchange that happens before anything else. - the multi message envelope has been removed. - a new NODE_ENCRYPTED service bit - the key derivation and what communication direction uses what key is now more specific - the length of a packet uses now a 3-byte integer with 23 available bits - introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result in some v2 messages require less bandwidth then v1 - rekeying doesn’t require a message and can be signaled in the most significant bit in the packet-size field Points that are in discussion and may be added to the BIP (or to a new one): Hybrid NewHope key exchange === The current ECDH key exchange is vulnerable to Shor’s algorithm and is thus not considered quantum-safe. Following TORs approach [4] by adding a NewHope [5] key-exchange the handshake protocol would very likely make the encryption PQ safe with little costs. There is also a straight forward implementation [6] from the NewHope team that has been submitted to NIST PQC project. Inefficiency of ChaCha20Poly1305@openssh The proposed AEAD could eventually be further optimized. ChaCha20Poly1305@openssh uses at least three rounds of ChaCha20 which eventually can be reduced to two (messages below <=64 bytes [inv, ping, pong,...] only require one round of ChaCha20, but two for the Poly1305 key and the message length encryption where the Poly1305 key chacha round „throws away“ 32 bytes). I would suggest that we don’t rehash discussions about the general concept of encrypting the traffic. This has already been discussed [7][8]. I hope we can limit this thread to discuss further ideas for optimisation as well as technical details of the published proposal or its implementation. [1] https://github.com/bitcoin/bitcoin/pull/14032 [2] https://github.com/goatpig/BitcoinArmory/pull/510 [3] https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd439300708e662 [4] https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope [5] https://eprint.iacr.org/2015/1092 [6] https://github.com/newhopecrypto/newhope [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013565.html [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html Thanks signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reinterpretations of contracts in different pay-to-contract schemes
Good morning all, I am wondering if there is the possibility of an issue arising when different pay-to-contract schemes are used on Bitcoin. Specifically, I wonder, if it may be possible to reinterpret the byte serialization of a contract under one scheme as the byte serialization of a different contract under another scheme. The user may expect to have committed to a contract under the first scheme, but is rudely made aware that she has also committed to a different contract under a scheme she is unaware of. For instance, if some independent protocol uses pay-to-contract, it may be possible for the contract to be reinterpreted as a Bitcoin SCRIPT under Taproot, leading to a contract that can be reinterpreted as a Bitcoin SCRIPT and allowing a Bitcoin-level UTXO to be stolen without knowledge of the private key. I thought of this a little while ago and mentioned it here:https://github.com/rgb-org/spec/issues/61 Now, it may be possible to use the hash of the contract, but if Taproot uses a hash of the script also and the same hash function is used, then the bytes of the contract could be reinterpreted as a Bitcoin SCRIPT program, possibly leading to a trivial-to-solve SCRIPT with enough hacking. If this is indeed a concern, then I propose, that pay-to-contract schemes should pay to the below tweak: Q = P + SHA256d(P || Scheme || C) * G Where `Scheme` is 256 bits (32 bytes) scheme identifier. For Taproot, it could be the genesis block ID. Then other pay-to-contract schemes must ensure that they use a `Scheme` ID that is different with high probability from other `Scheme` IDs, in order to ensure that reinterpretation of contracts is impossible. Regards, ZmnSCPxj___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
On Wed, Aug 29, 2018 at 08:09:36AM -0400, Erik Aronesty wrote: > Note: > > This spec cannot be used directly with a shamir scheme to produce > single-round threshold multisigs, because shares of point R would need to > be broadcast to share participants in order to produce valid single > signatures. > > (R, s) schemes can still be used "online", if share participants publish > the R(share) but, not sure if it matter much, this choice eliminates > offline multiparty signing in exchange for batch validation. > Please stop with this FUD. No tradeoff was made. There are no non-interactive Schnorr signatures. Andrew -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testnet3 Reest
I think I mentioned it before, but seems semi-relevant to this thread so I'd like to throw my vote behind pretty tiny blocks on testnet (like max 50-100k weight) to try help simulate a fee-market like situation. (Although lately there's been a lot of testnet spam and full blocks, which has really made testing easier. But I don't know how long this situation will last) -Ryan ‐‐‐ Original Message ‐‐‐ On August 30, 2018 7:06 PM, Gregory Maxwell via bitcoin-dev wrote: > On Thu, Aug 30, 2018 at 11:21 PM Johnson Lau via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > A public testnet is still useful so in articles people could make > > references to these transactions. > > Maybe we could have 2 testnets at the same time, with one having a smaller > > block size? > > I would much rather have a signed blocks testnet, with a predictable > structured reorg pattern* (and a config flag so you can make your node > ignore all blocks that are going to get reorged out in a reorg of nth > or larger). There are many applications where the mined testnet just > doesn't give you anything useful... it's too stable when you want it > to be a bit unstable and too wildly unstable when you want a bit of > stability-- e.g. there are very few test cases where a 20,000 block > reorg does anything useful for you; yet they happen on testnet. > > We looked at doing this previously in Bitcoin core and jtimon had some > patches, but the existing approach increased the size of the > blockindex objects in memory while not in signed testnet mode. This > could probably have been fixed by turning one of the fields like the > merkel root into a union of it's normal value and a pointer a > look-aside block index that is used only in signed block testnet mode. > > Obviously such a mode wouldn't be a replacement for an ordinary > testnet, but it would be a useful middle ground between regtest (that > never sees anything remotely surprising and can't easily be used for > collaborative testing) and full on testnet where your attempts to test > against ordinary noise require you cope your entirely universe being > removed from existence and replaced by something almost but not quite > entirely different at the whim of some cthulhuian blind idiot god. > > 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] Selfish Mining Prevention
As I understand, selfish mining is an attack where miners collude to mine at a lower hashrate then with all miners working independently. What are the current strategies used to prevent this and what are the future plans? One idea I have is to let the block reward get "modulated" according to peak hashrate. Say p is the peak hashrate for 365 periods (1 year) consisting of 144 blocks, h is the hashrate of the last 144 block (1 day) period, and r is the base subsidy (12.5 BTC currently). You can then make the max block reward 0.5 r (1 + h/p). So if hashrate is at peak you get the full reward. Otherwise you get less, down to a min of 0.5 r. If miners were to collude to mine at a lower than peak hashrate, then they may be able to do it profitably for 144 blocks, but after that, the reward would get modulated and it wouldn't be so much in their interest to continue mining at the lower hashrate. What flaws are there with this? I know it could be controversial due to easier mining present for early miners, so maybe it would have to be done in combination with a new more dynamic difficulty adjustment algorithm. But I don't see how hashrate can continue rising indefinitely, so a solution should be made for selfish mining. Also when subsidies stop and a fee market is needed, I guess a portion of the fees can be withheld for later if hashrate is not at peak. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
