Re: [bitcoin-dev] BIP sighash_noinput

[Jonas Nick via bitcoin-dev]

Oh, I missed that that's still the case with NOINPUT - thanks for pointing it
out. In that case there's no reason to sign the other inputs' sequence and
that's even better because the current NOINPUT proposal already enables
taprootifiability of eltoo unilateral closings.

On 9/26/18 7:45 PM, Johnson Lau wrote:
> In BIP143, the nSequence of the same input is always signed, with any 
> hashtype. Why do you need to sign the sequence of other inputs?
> 
>> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev 
>>  wrote:
>>
>>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>>
>> There is a good reason for not doing that. If NOINPUT would sign the
>> hashSequence then it would be possible to get rid of OP_CSV in eltoo update
>> scripts. As a result update scripts could be taprootified because the more
>> common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
>> would then make unilateral settlement look like a single pubkey spend and 
>> avoid
>> having to reveal the unexecuted (update) branch.
>>
>> Eltoo update transaction outputs consist of two branches, update and
>> settlement, where the update branch can be spend by a more recent update
>> transaction if an obsolete update transaction ends up spending the funding
>> output. The settlement branch is a 2-of-2 multisig with a relative timelock
>> using OP_CSV. Removing OP_CSV is possible because both parties signature is
>> required to spend the update transaction. They will only sign if the input 
>> has
>> the right sequence numbers which is sufficient to enforce the timeout 
>> (BIP68) -
>> assuming they are covered by the signature.
>>
>> There's a catch: hashSequence includes the sequence numbers of all 
>> transaction
>> inputs. That's not a problem for eltoo because settlement transactions only
>> have one input. The update mechanism with update transactions relies on being
>> able to bump the fee by unilaterally adding inputs and and change outputs to
>> the transaction. That's also not a problem because update spends do not use
>> relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
>> combined SINGLE the hashSequence should be zeroed. This is in fact what a
>> minimal change to the current NOINPUT implementation would naturally do (see
>> below). However, that's error-prone when using NOINPUT in other contexts so 
>> in
>> general it would be better if NOINPUT would only sign the sequence number of
>> the corresponding input.
>>
>> Another downside of this approach is that you can never rebind to an output
>> with an OP_CSV that requires a larger sequence number, unless you also sign
>> with SIGHASH_SINGLE. It's difficult to imagine application where this would 
>> be
>> an issue.
>>
>> This is the modification to the NOINPUT implementation
>> (https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
>> unilateral closes taprootifiable:
>> +++ b/src/script/interpreter.cpp
>> @@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const 
>> CTransaction& txTo, unsig
>> hashPrevouts = cacheready ? cache->hashPrevouts : 
>> GetPrevoutHash(txTo);
>> }
>>
>> -if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
>> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
>> +if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
>> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
>> hashSequence = cacheready ? cache->hashSequence : 
>> GetSequenceHash(txTo);
>> }
>>
>> On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
>>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>>>
>>
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Johnson Lau via bitcoin-dev]

In BIP143, the nSequence of the same input is always signed, with any hashtype. 
Why do you need to sign the sequence of other inputs?

> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev 
>  wrote:
> 
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
> 
> There is a good reason for not doing that. If NOINPUT would sign the
> hashSequence then it would be possible to get rid of OP_CSV in eltoo update
> scripts. As a result update scripts could be taprootified because the more
> common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
> would then make unilateral settlement look like a single pubkey spend and 
> avoid
> having to reveal the unexecuted (update) branch.
> 
> Eltoo update transaction outputs consist of two branches, update and
> settlement, where the update branch can be spend by a more recent update
> transaction if an obsolete update transaction ends up spending the funding
> output. The settlement branch is a 2-of-2 multisig with a relative timelock
> using OP_CSV. Removing OP_CSV is possible because both parties signature is
> required to spend the update transaction. They will only sign if the input has
> the right sequence numbers which is sufficient to enforce the timeout (BIP68) 
> -
> assuming they are covered by the signature.
> 
> There's a catch: hashSequence includes the sequence numbers of all transaction
> inputs. That's not a problem for eltoo because settlement transactions only
> have one input. The update mechanism with update transactions relies on being
> able to bump the fee by unilaterally adding inputs and and change outputs to
> the transaction. That's also not a problem because update spends do not use
> relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
> combined SINGLE the hashSequence should be zeroed. This is in fact what a
> minimal change to the current NOINPUT implementation would naturally do (see
> below). However, that's error-prone when using NOINPUT in other contexts so in
> general it would be better if NOINPUT would only sign the sequence number of
> the corresponding input.
> 
> Another downside of this approach is that you can never rebind to an output
> with an OP_CSV that requires a larger sequence number, unless you also sign
> with SIGHASH_SINGLE. It's difficult to imagine application where this would be
> an issue.
> 
> This is the modification to the NOINPUT implementation
> (https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
> unilateral closes taprootifiable:
> +++ b/src/script/interpreter.cpp
> @@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const 
> CTransaction& txTo, unsig
> hashPrevouts = cacheready ? cache->hashPrevouts : 
> GetPrevoutHash(txTo);
> }
> 
> -if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
> +if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
> hashSequence = cacheready ? cache->hashSequence : 
> GetSequenceHash(txTo);
> }
> 
> On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>> 
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes

[Andrew Kozlik via bitcoin-dev]

Thank you for your input Ignacio. Looking at your proposal, I see that
its main feature is that it makes one of the shares privileged in the
sense that it must always take part in the reconstruction of the master
secret, while the remaining shares follow the K-of-M scheme. This is an
interesting idea.

To answer your questions:

> Your proposed work provides a way to split the pre-secret into SSS
> shares, a format of encoding the shares, and finally several methods
> to derive the master secret from the pre-secret. Would you envision
> standarizing these different topics under the same proposal?
We intend standardize the encoding format, splitting of the pre-master
secret into shares and the derivation of the master secret from the
pre-master secret in a single document. However, note that only one of
the four proposed master secret derivation functions will be selected
for the final version.

> Also, have you thought of a way to deal with the existing legacy
> privatekeys already encoded into BIP-0039, or stored in other formats,
> and how to migrate them securely into a schema of encoded SSS shares?
Three of the four proposed master secret derivation functions are
symmetric, which means that they allow users to migrate any existing
master secret (including a BIP-0039 mnemonic) to the new scheme.

Thanks,
Andrew Kozlik


On 24.9.2018 21:49, Ignacio Berrozpe wrote:
> Hi Andrew
>
> Please allow me to comment on your work, as I happened to publish an
> article 5 months ago proposing SSS to split bitcoins private keys into
> shares that could be encoded directly using BIP-0039 mnemonic words.
> While cryptographically much simpler than your proposal, the proposal
> had the characteristic that it could be applied directly to existing
> private keys backups, by splitting the keys into SSS shares that could
> benefit from the existing BIP-0039 mnemonic to encode directly the
> shares. I thought it would be a simple path for hardware wallets
> providers such as Trezor into providing a better/more secure
> alternative the existing BIP-0039 privatekey backups of 24 words.
>
> The article can be found here, and I've enclosed a simplified version
>
> https://privatekeys.org/2018/04/24/k-of-m-private-key-generation-and-backup-in-bitcoin-wallets/
>
> Mind two questions? Your proposed work provides a way to split the
> pre-secret into SSS shares, a format of encoding the shares, and
> finally several methods to derive the master secret from the
> pre-secret. Would you envision standarizing these different topics
> under the same proposal? Also, have you thought of a way to deal with
> the existing legacy privatekeys already encoded into BIP-0039, or
> stored in other formats, and how to migrate them securely into a
> schema of encoded SSS shares?
>
> Best regards
> Ignacio Berrozpe
>
>
>
>
>
>
>
> On Fri, Sep 21, 2018 at 8:18 PM Andrew Kozlik via bitcoin-dev
>  > wrote:
>
> Hello everyone,
>
> We are currently writing a new specification for splitting BIP-32
> master
> seeds into multiple mnemonics using Shamir's secret sharing scheme. We
> would be interested in getting your feedback with regard to the
> high-level design of the new spec:
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> Please focus your attention on the section entitled "Master secret
> derivation functions", which proposes several different solutions.
> Note
> that there is a Design Rationale section at the very end of the
> document, which should answer some of the questions you may have. The
> document is a work in progress and we are aware that some technical
> details have not been fully specified. These will be completed
> once the
> high level design has been settled.
>
> Thanks,
>
> Andrew Kozlik
> TREZOR Team
>
>
> ___
> 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] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes

[Andrew Kozlik via bitcoin-dev]

Thanks for your input Christopher. Since we already have the discussion
about your comments running under the issues in the SLIPs repo on Github
(https://github.com/satoshilabs/slips/issues), let's continue it there.

Andrew Kozlik


On 21.9.2018 21:29, Christopher Allen wrote:
> On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev
>  > wrote:
>
> We are currently writing a new specification for splitting BIP-32
> master
> seeds into multiple mnemonics using Shamir's secret sharing scheme. We
> would be interested in getting your feedback with regard to the
> high-level design of the new spec:
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> Please focus your attention on the section entitled "Master secret
> derivation functions", which proposes several different solutions.
> Note
> that there is a Design Rationale section at the very end of the
> document, which should answer some of the questions you may have. The
> document is a work in progress and we are aware that some technical
> details have not been fully specified. These will be completed
> once the
> high level design has been settled.
>
>
> I and a number of companies & communities I am involved with are very
> interested in this. 
>
> A challenge is that Shamir Secret Sharing has subtleties. To quote
> Greg Maxwell:
>
> > I think Shamir Secret Sharing (and a number of other things, RNGs
> for example), suffer from a property where they are just complex
> enough that people are excited to implement them often for little good
> reason, and then they are complex enough (or have few enough reasons
> to invest significant time) they implement them poorly”.
>
> Some questions for you:
>
> * What other teams or communities besides Trezor are committed to
> standardizing a Shamir Secret Sharing Scheme? I can say that the
> #RebootingWebOfTrust community (meeting again for the 7th time next
> week in Toronto https://rwot7.eventbrite.com) are very interested.
>
> * Where do you want to hold discussions on this? Do people object to
> having this discussion on this mailing list? Or should it be issues in
> SLIPS repo or on some other mailing list? 
>
> * Presuming a successful split of secrets, I don’t know all the
> adversarial problems that are associated with recovery of a SSS. As
> this would be an interactive event, I presume an attacker can DOS a
> request to reassemble keys (so maybe some the of integrity of each
> share vs all is required). And of course there are the biggest
> problems:  impersonation of a reassembly request and a MitM of a
> reassembly request. Are there other attacks? Are you trying to
> mitigate any of these?
>
> Two comments:
>
> * The Lightning Network community has added to their BIP32 mnemonics
> the ability to have a birthday in the seed, to make it easier  to scan
> the blockchain for keys, as well as a byte with some way to know how
> to derive keys paths for it. I don’t seee a BOLT for this (it was
> mentioned
> in 
> https://bitcoin.stackexchange.com/questions/74805/what-is-birthday-in-the-context-of-bip39-lightning-seed-generation)
>  I would suggest that you also get some of their latest thoughts and
> incorporate them.
>
> * I worked with Chris Vickery while at Blockstrham on various possible
> ways to improve mnemonic word lists. I’m not suggesting that you
> necessarily go as far as we did to try to create a mnemonic that is
> iambic pentameter poetry (inspired by
> https://www.isi.edu/natural-language/mt/memorize-random-60.pdf),
> however, we did find sources for words that are concrete (for example
> table is more concrete than truth
> http://crr.ugent.be/papers/Brysbaert_Warriner_Kuperman_BRM_Concreteness_ratings.pdf
> ) or have strong emotional valence attachment (truth is more emotional
> than table), both of which make can words more memorable. I also found
> lists of words that are hard to pronounce unless you are English
> native, and eliminated them from my own list. 
>
> Among the results of this was a new BIP-39 2048 word compatible word
> list filtered for memorability (concreteness & emotional valence) and
> suitability for iambic pentameter, which is located:
>
>    
> https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/iambic-wordlist.json
>  
>
> …which was created from the repo at
>
>     https://github.com/ChristopherA/password_poem
>
> You can a number of other word lists that I’ve collected here
> https://github.com/ChristopherA/iambic-mnemonic/blob/master/word-lists/
>
> If you want to replicate what we did with your own criteria, you may
> want to incorporate information from the CMU
> dictitionary http://www.speech.cs.cmu.edu/cgi-bin/cmudict, the top
> 5000
> words https://github.com/ChristopherA/password_poem/blob/master/top5000.json,
>  concrete word lists
> http://crr.ugent.be/papers/Concreteness_ratings_Brysbaert_et_al_BRM.txt
> and emo

Re: [bitcoin-dev] BIP sighash_noinput

[Jonas Nick via bitcoin-dev]

> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?

There is a good reason for not doing that. If NOINPUT would sign the
hashSequence then it would be possible to get rid of OP_CSV in eltoo update
scripts. As a result update scripts could be taprootified because the more
common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
would then make unilateral settlement look like a single pubkey spend and avoid
having to reveal the unexecuted (update) branch.

Eltoo update transaction outputs consist of two branches, update and
settlement, where the update branch can be spend by a more recent update
transaction if an obsolete update transaction ends up spending the funding
output. The settlement branch is a 2-of-2 multisig with a relative timelock
using OP_CSV. Removing OP_CSV is possible because both parties signature is
required to spend the update transaction. They will only sign if the input has
the right sequence numbers which is sufficient to enforce the timeout (BIP68) -
assuming they are covered by the signature.

There's a catch: hashSequence includes the sequence numbers of all transaction
inputs. That's not a problem for eltoo because settlement transactions only
have one input. The update mechanism with update transactions relies on being
able to bump the fee by unilaterally adding inputs and and change outputs to
the transaction. That's also not a problem because update spends do not use
relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
combined SINGLE the hashSequence should be zeroed. This is in fact what a
minimal change to the current NOINPUT implementation would naturally do (see
below). However, that's error-prone when using NOINPUT in other contexts so in
general it would be better if NOINPUT would only sign the sequence number of
the corresponding input.

Another downside of this approach is that you can never rebind to an output
with an OP_CSV that requires a larger sequence number, unless you also sign
with SIGHASH_SINGLE. It's difficult to imagine application where this would be
an issue.

This is the modification to the NOINPUT implementation
(https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
unilateral closes taprootifiable:
+++ b/src/script/interpreter.cpp
@@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const 
CTransaction& txTo, unsig
 hashPrevouts = cacheready ? cache->hashPrevouts : 
GetPrevoutHash(txTo);
 }

-if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
+if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
 hashSequence = cacheready ? cache->hashSequence : 
GetSequenceHash(txTo);
 }

On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
> 
> On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
>> previous
>> output. This was previously mentioned on the list by Joseph Poon [1], but
>> was
>> never formally proposed, so I wrote a proposal [2].
>>
>> We have long known that `SIGHASH_NOINPUT` would be a great fit for
>> Lightning.
>> They enable simple watch-towers, i.e., outsource the need to watch the
>> blockchain for channel closures, and react appropriately if our
>> counterparty
>> misbehaves. In addition to this we just released the eltoo [3,4] paper
>> which
>> describes a simplified update mechanism that can be used in Lightning, and
>> other
>> off-chain contracts, with any number of participants.
>>
>> By not committing to the previous output being spent by the transaction,
>> we can
>> rebind an input to point to any outpoint with a matching output script and
>> value. The binding therefore is no longer explicit through a reference, but
>> through script compatibility, and the transaction ID reference in the
>> input is a
>> hint to validators. The sighash flag is meant to enable some off-chain
>> use-cases
>> and should not be used unless the tradeoffs are well-known. In particular
>> we
>> suggest using contract specific key-pairs, in order to avoid having any
>> unwanted
>> rebinding opportunities.
>>
>> The proposal is very minimalistic, and simple. However, there are a few
>> things
>> where we'd like to hear the input of the wider community with regards to
>> the
>> implementation details though. We had some discussions internally on
>> whether to
>> use a separate opcode or a sighash flag, some feeling that the sighash f