<unnamed>

Public Key

npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdw

Profile Code

nprofile1qqs83adg9g9kf7eurz7n8f5u2wc67cft8tydmq0p9a6t5chn0y76cpgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv3647jh

Publishing to

relay.snort.social

Last Notes

2023-06-07 20:28:38 CEST

- reply

📅 Original date posted:2021-02-14
📝 Original message:After off-list discussion with Hugo, I'm convinced that
adding a requirement for signers to derive participant ids is
unnecessary complication that only buys slight convenience for
coordinator, and this is not a net positive tradeoff.
And since the coordinator can choose to generate unique TOKEN per
participant without participants even knowing about this, there's
probably no reason to mention this possibility in the spec, either.
В Sun, 14 Feb 2021 11:37:52 +0100
Dmitry Petukhov <dp at simplexum.com> wrote:
> I think that it is better to issue individual TOKEN for each
> participant. Otherwise it will be possible for one participant to
> attack another (intercept and replace their xpub sent to the
> coordinator).
>
> It will also be convenient to have a public 'participant id', derived
> from the token. It can be derived from the same token, but with
> different (but fixed) `Pwd`. With unique token per participant, such
> derivation will uniquely identify each participant, so the coordinator
> won't need to try all the tokens to decrypt the data.
>
> It will also be easier to deal with more elaborate setups where the
> position of the xpub in the descriptor does matter - for example, with
> miniscript-extended descriptors. With a descriptor template such as
>
> `wsh(or(multi(2, <Alice>, <Bob>, <Carol>), older(1000, <Dylan>))`
>
> The coordinator will be able to store the map between the participant
> labels (Alice, Bob, Carol, Dylan) and their participant ids (and the
> TOKENs). When the data from Alice comes with participant id attached,
> the coordinator will immediately know which TOKEN to use, and which
> place in the descriptor the xpub should be put in.
>
> Of course this is all possible without 'participant id' derived from
> token, as long as there's unique TOKEN per participant - the
> coordinator can always try all the tokens to decrypt the data from
> participant. But implementors will likely invent their own ways to
> introduce 'participant id' anyway, as this is more convenient, and it
> might make sense to have this standardized, for interoperability.
>
> В Fri, 12 Feb 2021 09:54:57 -0800
> Hugo Nguyen <hugo at nunchuk.io> wrote:
>
> > On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp at simplexum.com>
> > wrote:
> >
> > > If HUMAN_READABLE_TITLE is the additional secret, the user would
> > > need to enter it on the device in addition to the nonce, wouldn't
> > > it defeat the advantage in UX that was gained by using
> > > (relatively) short nonce ?
> > >
> > > Is 64 bit nonce not enough ?
> > >
> > >
> > Good question. If we don't need the extra entropy, we can fix
> > the HUMAN_READABLE_TITLE string.
> >
> > Something like "No SPOF". (No Single Point Of Failure).
> >
> >
> >
> > > It seems that to crack this with fixed Pwd and 64 bit nonce, the
> > > attacker will need to be about 10^15 more powerful than 80Mhz MCU:
> > > (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is
> > > realistic scale. Average desktop cpu seems to be about 10^3 more
> > > powerful than the mentioned MCU for this task.
> > >
> > > Maybe for the UX it would be better to choose the number of rounds
> > > to use in PBKDF2, instead of using variable Pwd. Number of rounds
> > > will be easier to enter on the device (or just choose it from a
> > > set of pre-defined values). The more money is at stake, the higher
> > > number of rounds could the coordinator choose (taking into account
> > > the characteristics of the participant devices)
> > >
> >
> > > Or simply allow bigger entropy (more than 6 mnemonic words), if
> > > the coordinator feels that 64 bit of entropy is not enough.
> >
> >
> > That could work. Allowing variable iteration count is probably
> > better UX-wise.
> >
> > Best,
> > Hugo
> >
> >
> > >
> > > В Fri, 12 Feb 2021 08:55:55 -0800
> > > Hugo Nguyen <hugo at nunchuk.io> wrote:
> > >
> > > > Thanks everyone who has provided inputs so far!
> > > >
> > > > This is the new proposal for the encryption aspect of the
> > > > scheme, based on all the feedback.
> > > >
> > > > The key derivation function would be PBKDF2, with PRF = SHA512.
> > > > This should be readily available on today's hardware already, as
> > > > they are used for BIP39.
> > > >
> > > > DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> > > > PRF = SHA512
> > > > Pwd = HUMAN_READABLE_TITLE
> > > > Salt = NONCE
> > > > c = 2048
> > > > dkLen = 256
> > > >
> > > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8,
> > > > maximum length = 20.
> > > > NONCE is a 64-bit number.
> > > >
> > > > Reason for going with SHA512 is due to legacy support on some
> > > > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> > > > derive the encryption key on a 80Mhz MCU. We feel like this is a
> > > > good enough tradeoff for this use case. The assumption here is
> > > > that the secure session is only needed temporarily for a few
> > > > hours, maybe up to one day.
> > > >
> > > > The Coordinator and Signers agree and exchange these 2 secrets
> > > > prior to the setup. The NONCE can be converted to either:
> > > > (a) a 6-word phrase using BIP39 wordlist
> > > > (b) a 20-digit decimal number
> > > > (c) a QR code
> > > >
> > > > Depending on the vendor. This flexibility in the data format
> > > > allows each vendor to customize the UX based on their respective
> > > > device capabilities.
> > > >
> > > > Best,
> > > > Hugo
> > > >
> > > > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev
> > > > < bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > >
> > > > > В Thu, 11 Feb 2021 05:45:33 -0800
> > > > > Hugo Nguyen via bitcoin-dev
> > > > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > > >
> > > > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > > > > > >
> > > > > > > This scheme might be vulnerable to rainbow table attack.
> > > > > > >
> > > > > >
> > > > > > Thank you for pointing this out! Incidentally, Dmitry
> > > > > > Petukhov also told me the same privately.
> > > > >
> > > > > My thought was that if TOKEN has the characteristics of a
> > > > > password (short ASCII string), then it would be better to use
> > > > > key derivation function designed for passwords, like PBKDF2.
> > > > >
> > > > > The counter-argument to this is that this adds another code
> > > > > dependency for vendors, if the device firmware does not
> > > > > already have the required key derivation function.
> > > > >
> > > > > Maybe this could be solved by going into opposite direction -
> > > > > make the "token" even longer, use the mnemoic.
> > > > >
> > > > > The issue is that entering long data of the shared key into
> > > > > the device manually is difficult UX-wise.
> > > > >
> > > > > Hww vendors that allow to enter custom keys into their device
> > > > > already have to face this issue, and those who allow to enter
> > > > > custom keys via mnemonic probably tackled this somehow.
> > > > >
> > > > > Maybe the shared key for multisig setup can be entered in the
> > > > > same way ? (with maybe additional visual check via some
> > > > > fingerprint).
> > > > >
> > > > > Although we would then have another issue of potential
> > > > > confusion between two procedures (entering the main key and
> > > > > entering the shared key for multisig setup), and the measures
> > > > > has to be taken to prevent such confusion.
> > > > >
> > > > > The approaches can be combined - specify a key derivation
> > > > > function suitable for passwords; via secure channel, share a
> > > > > password and/or the derived key. If hww supports derivation
> > > > > function, it can derive the key from password. If hww supports
> > > > > only keys, the key can be entered raw or via mnemonic.
> > > > > _______________________________________________
> > > > > bitcoin-dev mailing list
> > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > >
> > >
> > >
>

2023-06-07 20:28:37 CEST

- reply

📅 Original date posted:2021-02-12
📝 Original message:В Fri, 12 Feb 2021 18:42:31 +0100
Dmitry Petukhov <dp at simplexum.com> wrote:
> Maybe for the UX it would be better to choose the number of rounds to
> use in PBKDF2, instead of using variable Pwd. Number of rounds will be
> easier to enter on the device (or just choose it from a set of
> pre-defined values). The more money is at stake, the higher number of
> rounds could the coordinator choose (taking into account the
> characteristics of the participant devices)
Or simply allow bigger entropy (more than 6 mnemonic words), if
the coordinator feels that 64 bit of entropy is not enough.

2023-06-07 20:28:37 CEST

- reply

📅 Original date posted:2021-02-14
📝 Original message:I think that it is better to issue individual TOKEN for each
participant. Otherwise it will be possible for one participant to
attack another (intercept and replace their xpub sent to the
coordinator).
It will also be convenient to have a public 'participant id', derived
from the token. It can be derived from the same token, but with
different (but fixed) `Pwd`. With unique token per participant, such
derivation will uniquely identify each participant, so the coordinator
won't need to try all the tokens to decrypt the data.
It will also be easier to deal with more elaborate setups where the
position of the xpub in the descriptor does matter - for example, with
miniscript-extended descriptors. With a descriptor template such as
`wsh(or(multi(2, <Alice>, <Bob>, <Carol>), older(1000, <Dylan>))`
The coordinator will be able to store the map between the participant
labels (Alice, Bob, Carol, Dylan) and their participant ids (and the
TOKENs). When the data from Alice comes with participant id attached,
the coordinator will immediately know which TOKEN to use, and which
place in the descriptor the xpub should be put in.
Of course this is all possible without 'participant id' derived from
token, as long as there's unique TOKEN per participant - the coordinator
can always try all the tokens to decrypt the data from participant. But
implementors will likely invent their own ways to introduce
'participant id' anyway, as this is more convenient, and it might make
sense to have this standardized, for interoperability.
В Fri, 12 Feb 2021 09:54:57 -0800
Hugo Nguyen <hugo at nunchuk.io> wrote:
> On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp at simplexum.com>
> wrote:
>
> > If HUMAN_READABLE_TITLE is the additional secret, the user would
> > need to enter it on the device in addition to the nonce, wouldn't
> > it defeat the advantage in UX that was gained by using (relatively)
> > short nonce ?
> >
> > Is 64 bit nonce not enough ?
> >
> >
> Good question. If we don't need the extra entropy, we can fix
> the HUMAN_READABLE_TITLE string.
>
> Something like "No SPOF". (No Single Point Of Failure).
>
>
>
> > It seems that to crack this with fixed Pwd and 64 bit nonce, the
> > attacker will need to be about 10^15 more powerful than 80Mhz MCU:
> > (2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is
> > realistic scale. Average desktop cpu seems to be about 10^3 more
> > powerful than the mentioned MCU for this task.
> >
> > Maybe for the UX it would be better to choose the number of rounds
> > to use in PBKDF2, instead of using variable Pwd. Number of rounds
> > will be easier to enter on the device (or just choose it from a set
> > of pre-defined values). The more money is at stake, the higher
> > number of rounds could the coordinator choose (taking into account
> > the characteristics of the participant devices)
> >
>
> > Or simply allow bigger entropy (more than 6 mnemonic words), if
> > the coordinator feels that 64 bit of entropy is not enough.
>
>
> That could work. Allowing variable iteration count is probably better
> UX-wise.
>
> Best,
> Hugo
>
>
> >
> > В Fri, 12 Feb 2021 08:55:55 -0800
> > Hugo Nguyen <hugo at nunchuk.io> wrote:
> >
> > > Thanks everyone who has provided inputs so far!
> > >
> > > This is the new proposal for the encryption aspect of the scheme,
> > > based on all the feedback.
> > >
> > > The key derivation function would be PBKDF2, with PRF = SHA512.
> > > This should be readily available on today's hardware already, as
> > > they are used for BIP39.
> > >
> > > DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> > > PRF = SHA512
> > > Pwd = HUMAN_READABLE_TITLE
> > > Salt = NONCE
> > > c = 2048
> > > dkLen = 256
> > >
> > > HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8,
> > > maximum length = 20.
> > > NONCE is a 64-bit number.
> > >
> > > Reason for going with SHA512 is due to legacy support on some
> > > hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> > > derive the encryption key on a 80Mhz MCU. We feel like this is a
> > > good enough tradeoff for this use case. The assumption here is
> > > that the secure session is only needed temporarily for a few
> > > hours, maybe up to one day.
> > >
> > > The Coordinator and Signers agree and exchange these 2 secrets
> > > prior to the setup. The NONCE can be converted to either:
> > > (a) a 6-word phrase using BIP39 wordlist
> > > (b) a 20-digit decimal number
> > > (c) a QR code
> > >
> > > Depending on the vendor. This flexibility in the data format
> > > allows each vendor to customize the UX based on their respective
> > > device capabilities.
> > >
> > > Best,
> > > Hugo
> > >
> > > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> > > bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > > В Thu, 11 Feb 2021 05:45:33 -0800
> > > > Hugo Nguyen via bitcoin-dev
> > > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > >
> > > > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > > > > >
> > > > > > This scheme might be vulnerable to rainbow table attack.
> > > > > >
> > > > >
> > > > > Thank you for pointing this out! Incidentally, Dmitry Petukhov
> > > > > also told me the same privately.
> > > >
> > > > My thought was that if TOKEN has the characteristics of a
> > > > password (short ASCII string), then it would be better to use
> > > > key derivation function designed for passwords, like PBKDF2.
> > > >
> > > > The counter-argument to this is that this adds another code
> > > > dependency for vendors, if the device firmware does not already
> > > > have the required key derivation function.
> > > >
> > > > Maybe this could be solved by going into opposite direction -
> > > > make the "token" even longer, use the mnemoic.
> > > >
> > > > The issue is that entering long data of the shared key into the
> > > > device manually is difficult UX-wise.
> > > >
> > > > Hww vendors that allow to enter custom keys into their device
> > > > already have to face this issue, and those who allow to enter
> > > > custom keys via mnemonic probably tackled this somehow.
> > > >
> > > > Maybe the shared key for multisig setup can be entered in the
> > > > same way ? (with maybe additional visual check via some
> > > > fingerprint).
> > > >
> > > > Although we would then have another issue of potential confusion
> > > > between two procedures (entering the main key and entering the
> > > > shared key for multisig setup), and the measures has to be
> > > > taken to prevent such confusion.
> > > >
> > > > The approaches can be combined - specify a key derivation
> > > > function suitable for passwords; via secure channel, share a
> > > > password and/or the derived key. If hww supports derivation
> > > > function, it can derive the key from password. If hww supports
> > > > only keys, the key can be entered raw or via mnemonic.
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > >
> >
> >

2023-06-07 20:28:36 CEST

- reply

📅 Original date posted:2021-02-12
📝 Original message:If HUMAN_READABLE_TITLE is the additional secret, the user would need
to enter it on the device in addition to the nonce, wouldn't it defeat
the advantage in UX that was gained by using (relatively) short nonce ?
Is 64 bit nonce not enough ?
It seems that to crack this with fixed Pwd and 64 bit nonce, the
attacker will need to be about 10^15 more powerful than 80Mhz MCU:
(2^64)/(0.3*10^15)/3600 = 17 hours. I don't know if 10^15 is realistic
scale. Average desktop cpu seems to be about 10^3 more powerful than
the mentioned MCU for this task.
Maybe for the UX it would be better to choose the number of rounds to
use in PBKDF2, instead of using variable Pwd. Number of rounds will be
easier to enter on the device (or just choose it from a set of
pre-defined values). The more money is at stake, the higher number of
rounds could the coordinator choose (taking into account the
characteristics of the participant devices)
В Fri, 12 Feb 2021 08:55:55 -0800
Hugo Nguyen <hugo at nunchuk.io> wrote:
> Thanks everyone who has provided inputs so far!
>
> This is the new proposal for the encryption aspect of the scheme,
> based on all the feedback.
>
> The key derivation function would be PBKDF2, with PRF = SHA512. This
> should be readily available on today's hardware already, as they are
> used for BIP39.
>
> DK = PBKDF2(PRF, Password, Salt, c, dkLen)
> PRF = SHA512
> Pwd = HUMAN_READABLE_TITLE
> Salt = NONCE
> c = 2048
> dkLen = 256
>
> HUMAN_READABLE_TITLE is in ASCII format, minimum length = 8, maximum
> length = 20.
> NONCE is a 64-bit number.
>
> Reason for going with SHA512 is due to legacy support on some
> hardware. c=2048 also mimics BIP39. It takes about ~3 seconds to
> derive the encryption key on a 80Mhz MCU. We feel like this is a good
> enough tradeoff for this use case. The assumption here is that the
> secure session is only needed temporarily for a few hours, maybe up
> to one day.
>
> The Coordinator and Signers agree and exchange these 2 secrets prior
> to the setup. The NONCE can be converted to either:
> (a) a 6-word phrase using BIP39 wordlist
> (b) a 20-digit decimal number
> (c) a QR code
>
> Depending on the vendor. This flexibility in the data format allows
> each vendor to customize the UX based on their respective device
> capabilities.
>
> Best,
> Hugo
>
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > В Thu, 11 Feb 2021 05:45:33 -0800
> > Hugo Nguyen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> > wrote:
> >
> > > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > > >
> > > > This scheme might be vulnerable to rainbow table attack.
> > > >
> > >
> > > Thank you for pointing this out! Incidentally, Dmitry Petukhov
> > > also told me the same privately.
> >
> > My thought was that if TOKEN has the characteristics of a password
> > (short ASCII string), then it would be better to use key derivation
> > function designed for passwords, like PBKDF2.
> >
> > The counter-argument to this is that this adds another code
> > dependency for vendors, if the device firmware does not already
> > have the required key derivation function.
> >
> > Maybe this could be solved by going into opposite direction - make
> > the "token" even longer, use the mnemoic.
> >
> > The issue is that entering long data of the shared key into the
> > device manually is difficult UX-wise.
> >
> > Hww vendors that allow to enter custom keys into their device
> > already have to face this issue, and those who allow to enter
> > custom keys via mnemonic probably tackled this somehow.
> >
> > Maybe the shared key for multisig setup can be entered in the same
> > way ? (with maybe additional visual check via some fingerprint).
> >
> > Although we would then have another issue of potential confusion
> > between two procedures (entering the main key and entering the
> > shared key for multisig setup), and the measures has to be taken to
> > prevent such confusion.
> >
> > The approaches can be combined - specify a key derivation function
> > suitable for passwords; via secure channel, share a password and/or
> > the derived key. If hww supports derivation function, it can derive
> > the key from password. If hww supports only keys, the key can be
> > entered raw or via mnemonic.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

2023-06-07 20:28:34 CEST

- reply

📅 Original date posted:2021-02-11
📝 Original message:В Thu, 11 Feb 2021 05:45:33 -0800
Hugo Nguyen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
wrote:
> > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> >
> > This scheme might be vulnerable to rainbow table attack.
> >
>
> Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> told me the same privately.
My thought was that if TOKEN has the characteristics of a password
(short ASCII string), then it would be better to use key derivation
function designed for passwords, like PBKDF2.
The counter-argument to this is that this adds another code dependency
for vendors, if the device firmware does not already have the required
key derivation function.
Maybe this could be solved by going into opposite direction - make the
"token" even longer, use the mnemoic.
The issue is that entering long data of the shared key into the device
manually is difficult UX-wise.
Hww vendors that allow to enter custom keys into their device already
have to face this issue, and those who allow to enter custom keys via
mnemonic probably tackled this somehow.
Maybe the shared key for multisig setup can be entered in the same way
? (with maybe additional visual check via some fingerprint).
Although we would then have another issue of potential confusion
between two procedures (entering the main key and entering the shared
key for multisig setup), and the measures has to be taken to prevent
such confusion.
The approaches can be combined - specify a key derivation function
suitable for passwords; via secure channel, share a password and/or the
derived key. If hww supports derivation function, it can derive the key
from password. If hww supports only keys, the key can be entered raw or
via mnemonic.

2023-06-07 20:28:27 CEST

- reply

📅 Original date posted:2021-02-05
📝 Original message:В Fri, 05 Feb 2021 17:51:27 +0000
Dr Maxim Orlovsky via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Testnet path is unhardened from this point & till the end of the
> derivation path: no need to prevent private key leak there,
> simplifies test software (hardened paths require private key access
> for derivation).
I believe this will reduce robustness and will add complexity to the
test software instead. If the derivation path is hardened in 'production
code' and is unhardened in 'test code', then: code paths that depend on
hardened derivation may not be tested; there will be unnecessary
code that will need to deal with 'un-hardening' the paths for test code.
It is much more robust to just change the 'purpose' part of the path,
and leave the rest unchanged.
It is OK to require privkey access to hardened paths in test
software, because the same behaviour is expected in 'production'.

2023-06-07 20:25:08 CEST

- reply

📅 Original date posted:2020-06-01
📝 Original message:I've finished specifying the full Succint Atomic Swap contract in TLA+.
I believe the specification [1] now covers all relevant behaviors of
the participants. It even has an option to enable 'non-rational'
behavior, so that it can be shown that the transactions that are there
to punish bad behavior can actually be used. If you examine the spec
and find that I failed to specify some relevant behavior, please tell.
The specification can be used to exhaustively check safety properties
of the model (such as no participant can take both coins, unless in
explicitly specified circumstances), and temporal properties (such as
contract always end up in an explicitly specified 'finished' state).
The specification can also be used to *show* (but not automatically
check at the moment) the hyperproperties of the model, such as what
transactions can ever be confirmed in at least one the execution path,
max/min/avg values for various stats, etc. The information on these
hyperproperties can be printed out during model checking, and can be
examined manually or with help of additional scripts (if one willing to
write some).
The model has some limitations, like only having one miner, and not
modelling fees and mempool priorities. More than one miner needed to
introduce reorgs in the model, but I believe that reorgs are relevant
only if we cannot say that "one block in the model means 6 bitcoin
blocks" (or whatever reorg safety limit is acceptable). I also believe
that the fees and mempool priorities are a lower-level concern, because
the task to confirm the transaction in time is the same for different
stages of the contract and for different transactions, and therefore
this can be modelled separately.
The goal of creating this specification was to evaluate the suitability
of TLA+ for modelling of the smart contracts in UTXO-based
blockchain systems. I believe that the presented spec shows that it is
indeed feasible to do such modelling and TLA+ is a suitable tool for
specifying and for checking such specifications (Although having ability
to automatically check hyperproperties using TLA+ expressions would be
nice).
I hope that this spec can be used as a basis for specs for other
contracts, and that using TLA+ can make designing safe contracts for
UTXO-based systems easier. I also hope that this will help to increase
interest in using formal methods in this area.
I tried to make the parts of the spec that deal with things like mining
and mempool to not depend on the concrete contract logic, in
expectation that this logic can be reused afterwards for the specs of
other contracts. I did not make specific effort to factor out this
generic logic into separate module though, because I think that more
various contract specifications need to be designed and analyzed to
understand what is really generic and what should lay with concrete
contract logic. When more knowledge is created regarding this, there
could be a module that contract specifications can use to avoid
explicitly specifying the generic blockchain-related logic.
Thanks to Ruben Somsen for designing this contract and
providing helpful description and diagram that made it possible to
create this formal specification.
[1] https://github.com/dgpv/SASwap_TLAplus_spec

2023-06-07 20:24:44 CEST

- reply

📅 Original date posted:2020-05-13
📝 Original message:The Succint Atomic Swap contract presented by Ruben Somsen recently has
drawn much interest.
I personally am interested in the smart contracts realizeable in the
UTXO model, and also interested in applying formal methods to the
design and implementation of such contracts.
I think that having formal specifications for the contracts and to be
able to machine-check the properties of these specifications is very
valuable, as it can uncover the corner cases that might be difficult to
uncover otherwise.
The SAS contract is complex enough that it may benefit from formal
specification and machine checking.
I created a specification in TLA+ [1] specification language based on
the explanation and the diagram given by Ruben.
The checking of the model encoded in the specification can successfully
detect the violation of 'no mutual secret knowledge' invariant when one
of the participant can bypass mempool and give the transaction directly
to the miner (this problem was pointed out by ZmnSCPxj in the original
SAS thread [2])
There's one transition that was unclear how to model, though: I did not
understand what the destination of Alice&Bob cooperative spend of
refund_tx#1 will be, so this transition is not modelled.
I believe there can be more invariants and temporal properties of the
model that can be checked. At the moment the temporal properties
checking does not work, as I didn't master TLA+ enough yet. The safety
invariants checking should work fine, though, but more work needed to
devise and add the invariants.
In the future, it would be great to have an established framework for
modelling of the behavior in Bitcoin-like blockchain networks.
In particular, having a model of mempool-related behavior would help to
reason about difficult RBF/CPFP issues. The specification I present
models the mempool, but in a simple way, without regards to the fees.
The specification can be found in this github repository:
https://github.com/dgpv/SASwap_TLAplus_spec
There could be mistakes or omissions in the specified model, I hope
that public review can help find these.
It would be great to receive comments, suggestions and corrections,
especially from people experienced in formal methods and TLA+, as this
is only my second finished TLA+ spec and only my third project using
formal methods (I created bitcoin transaction deserialization code in
Ada/SPARK before that [3]). Please use the github issues or off-list
mail to discuss if the matter is not interesting to the general
bitcoin-dev list audience.
[1] https://lamport.azurewebsites.net/tla/tla.html
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html
[3] https://github.com/dgpv/spark-bitcoin-transaction-example

2023-06-07 20:22:21 CEST

- reply

📅 Original date posted:2020-01-11
📝 Original message:I am not sure that this particular task should be done with data
embedded in PSBT itself, and not with some sort of container that
includes PSBT and the authentication information.
The benefit seems to be in reusing PSBT structure for compatibilty, and
this might be a valid way, although I do not agree with some of your
points. I elaborate below:
> 1) In the PSBT globals section, a signature over the "source" PSBT
> file. It would cover all the bytes of the original PSBT file, as
> it was received by the Signer.
The problem of authenticating the contents of PSBT is independent of
the signing action. PSBT might be altered on the path from Creator to
Signer. Therefore you cannot always say that Signer will be an
authority over 'correctness' of PSBT.
> - At the end of the signing process, the Finalizer should check all
> the Signers have worked from the same PSBT file (assuming that's
> the flow expected)
If there is MitM, checking something at Finalizer is likely too
late - the party that can intercept PSBTs can finalize before the
legitimate Finalizer and broadcast the transaction.
Participants can work from the same PSBT file if they all receive the
same PSBT, and not working in chain where next particpant receives
updated PSBT from the previous participant. Otherwise they will need to
either pass two files (original and updated), or work out which fields
(key-value blobs) to remove to get the 'source' PSBT (which might not be
trivial with presense of proprietary and unknown fields). Even if you
know which key-value pairs to remove, there is no requirement for
ordering of the fields, and some signer can serialize them in different
order after dserialize/sign/add-signatures/re-serialize operation.
Introducing additional ordering or other structure requirements over
simple key-value structure will add complexity to PSBT processing, and
adding complexity on such a basic level should have really serious
reasons, because that increases effort required for even basic
implementations and increases chance of bugs.
If there is some authority on the 'correctness' of 'original' PSBT
(all particpants receive same PSBT at the start), particpants should
check the signature by that authority. That authority might use
the key used only for authentication, and not in the tx signing.
If particpants send PSBT in chain after adding their signatures, then
each participant can add their signature to say 'the contents
of PSBT after my updates should match this hash'.
The signatures of previous participants in the chain most likely do not
matter because of difficulty of restoring the contents of PSBT as it
was before the previous particpant, if you do not pass _all_ the PSBTs
(which is excessive).
> 2) In the output section, specifically, the last key/value pair of
> the last output of the transaction, I want to add a similar signature,
> again signed by one of the keys used in the signing process. This
> signature will cover all the bytes of the resulting (signed) PSBT
> up to that point. Because it is the last output of the output
> section, that signature will be the last few bytes of the PSBT file.
> By "appending" the signature in this way, it's easier to validate
> and create the signature, without blanking the signature area during
> digest step.
This will introduce unnecessary higher-level structure to PSBT for the
reasons that I do not find strong enough for the amount of complexity
added.
Also, as I said above, you likely do not need more than one
signature - if this is 'fan-out' scheme, then participants need do
check the sig of authority that created PSBT; if this is piggy-back
chain, then only previous particpant's signature is easily verifiable.
> ## Next Steps
>
> I'd like to get two officially-assigned BIP-174 key numbers assigned
> for these two signatures, and then I will see that it gets added
> into Coldcard's firmware immediately. In time, other tools are
> welcome to take advantage of these checks. I will also write a BIP
> for this, and/or make an addition to BIP-174.
I think you do not need to wait for officially-assigned key numbers,
and can just implement the scheme you envision with proprietary keys,
document and promote it. Then if it shows its usefulness, it will
either become de-facto standard with your proprietary keys (and
everyone will want to support 'Coldard PSBT auth' or whatever the name),
or the scheme will have serious grounds to be converted to standard and
have non-proprietary keys assigned.
// Dmitry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Ð¦Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑŒ OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200112/1e8c2cc8/attachment-0001.sig>

2023-06-07 20:19:57 CEST

- reply

📅 Original date posted:2019-08-06
📝 Original message:Unfortunately, both described schemes fail the same way as
'require TXOs to be consolidated by the owner', by the fact that with
muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in
[1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban
musig for the bonds' is not the answer, I believe.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.html
В Wed, 7 Aug 2019 01:55:41 +0500
Dmitry Petukhov <dp at simplexum.com> wrote:
> В Mon, 5 Aug 2019 20:04:26 +0100
> Chris Belcher <belcher at riseup.net> wrote:
>
> > So what's needed is a way to make renting out TXOs impossible or
> > very difficult.
>
> You can make renting the TXOs risky for the attacker. Make it so that
> the entity that rented out the TXO can revoke the participation of
> said TXO in the market, by publishing some special signature. That
> act of revocation can also mean revocation of all other TXOs that
> were used in a bond alongside it. This way, any entity that wants to
> spoil an attacker's consolidation via rent, can rent out its TXO to
> the attacker, and then revoke it, spoiling the whole package the
> attacker have consolidated.
>
> There may be other way to impose penalties.
>
> For example, all locked TXO may be required to be spendable by *any*
> key that controls any TXO in the 'bond TXO package'. I think this
> should be possible with taproot - you will have to publish a taproot
> trees for your locked TXOs (say, N of them), and the tree for each TXO
> will have N leaves, each leaf will specify a condition "spendable by
> the key N". This way, if I give you my TXO to include it in a bond by
> locking it, you also need to make your other TXOs in a bond spendable
> by me.
>
> For both scenarios to work for the attacker, there's need to be an
> off-chain contractual relationship between the parties. Otherwise the
> entity that rents out the TXOs can spoil or just confiscate the bond
> of the entity that rented them, without reprecussions.

2023-06-07 20:19:56 CEST

- reply

📅 Original date posted:2019-08-06
📝 Original message:В Mon, 5 Aug 2019 20:04:26 +0100
Chris Belcher <belcher at riseup.net> wrote:
> So what's needed is a way to make renting out TXOs impossible or very
> difficult.
You can make renting the TXOs risky for the attacker. Make it so that
the entity that rented out the TXO can revoke the participation of said
TXO in the market, by publishing some special signature. That act of
revocation can also mean revocation of all other TXOs that were used in
a bond alongside it. This way, any entity that wants to spoil an
attacker's consolidation via rent, can rent out its TXO to the
attacker, and then revoke it, spoiling the whole package the attacker
have consolidated.
There may be other way to impose penalties.
For example, all locked TXO may be required to be spendable by *any*
key that controls any TXO in the 'bond TXO package'. I think this
should be possible with taproot - you will have to publish a taproot
trees for your locked TXOs (say, N of them), and the tree for each TXO
will have N leaves, each leaf will specify a condition "spendable by
the key N". This way, if I give you my TXO to include it in a bond by
locking it, you also need to make your other TXOs in a bond spendable
by me.
For both scenarios to work for the attacker, there's need to be an
off-chain contractual relationship between the parties. Otherwise the
entity that rents out the TXOs can spoil or just confiscate the bond of
the entity that rented them, without reprecussions.

2023-06-07 20:15:10 CEST

- reply

📅 Original date posted:2018-11-08
📝 Original message:> Copying addresses to the clipboard should be discouraged, rather than
> supported.
Do you know any reasonably convenient mechanism for end user to
transfer an address from, say, a web page to the wallet address
input field ?
The clipboard is just a low-hanging fruit for malware, anyway. It just
the most easy point to replace an address. If the computer is
compromized, malware can edit the web page in the memory of the browser
process, for example. If it shown as QR code, malware can decode,
detect that it is an address, and replace the image of QR code.
I think that the only way to protect from this is to add some form of
authentication for an address - 2fa (transfer checksum via second
channel), visual fingerprints for addresses, that will are hard to
detect (and hence, replace) for malware, signing the destination address
with the key of an address that is already known and checking the
signature, etc.
The problem will be to come up with an address authentication procedure
that will be convenient for users and widely supported, as a result.

2023-06-07 20:15:10 CEST

- reply

📅 Original date posted:2018-11-08
📝 Original message:> > Do you know any reasonably convenient mechanism for end user to
> > transfer an address from, say, a web page to the wallet address
> > input field ?
>
> - QR code scanning of a Bitcoin URI
> - On Android: A "bitcoin:" URI intent or a BIP70 payment message
> intent
> - On desktop OSes there are similar mechanisms to launch Apps from the
> browser (e.g. for mailto: links)
This works if the author of the web page thought about this, and
created appropriate liks/qr codes. In many cases, addresses are
just presented for users as text, to copy.
People also send addresses in message apps and emails. Maybe if
applications start to autodetect bitcoin addresses and convert them to
bitcoin: links, there will be less need to copy-paste. But I suspect
that this feature will not be quickly adopted by applications.
> For cases where the payee is a well-known entity the BIP70 payment
> protocol has authentication via certificates. That doesn't work for
> the "the person in front of you is the only trust anchor you have"
> usecase though.
There are also BIP75 and BIP47 that may help, but the number of wallets
that support these protocols is small (I think in part because of
relative complexity of these protocols).