Jonathan Underwood [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-07 to 2020-11-26
💬 Posted a total of 28 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Question
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1axv7m5dyyrnatcvmu7rse0860x9mnr95prje9x32rqvperr0rhhqp0ftr0

Profile Code

nprofile1qqswnx0d6xjzpe74uxd70pcvhna8nzae3j6q3evjng4psxqu33h3mms5j5v4q

Author Public Key

npub1axv7m5dyyrnatcvmu7rse0860x9mnr95prje9x32rqvperr0rhhqp0ftr0

Show more details

Last Notes

2023-06-09 12:48:32

- reply

📅 Original date posted:2018-01-13
📝 Original message:
Hey everybody.
Say that the last time we updated channel state, we assumed 40 satoshi/byte
was enough to get confirmed, then I leave the channel for a few weeks, come
back to find my partner fell off the face of the internet.
I perform unilateral close with my output on CSV timelock... but it turns
out there’s 500 MB of txes at around 100 satoshi/byte and lets say my
transaction will never get confirmed at 40 sat/byte.
What course of action can I take?
1. to_local output can't be redeemed until the commitment transaction
(which will "never confirm") is confirmed + the CSV timeout.
2. to_remote output probably won't be redeemed as the other person is
offline.
The only remedy I can think of is hope that the other person comes back
online and CPFPs your to_remote output for you... but at that point it
would be better for them to just amicably close with normal outputs... so
basically your only hope is wait for other person to come online.
Since CSV will cause script verification to fail, a CPFP transaction will
not be propagated.
If we can't CPFP, the CSV timer won't start (it starts once the CSV
containing output is confirmed).
Seems like a problem.
Anyone have any solutions?
Thanks,
Jon
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180114/0fc7a441/attachment.html>

2023-06-09 12:48:30

- reply

📅 Original date posted:2018-01-11
📝 Original message:
Hi all,
I have mentioned this to roasbeef re: lnd implementing it... but I am
wondering if this idea has propagated through the LN community and whether
other wallets are going to implement it?
Feature:
If the recipient of a payment waiting for a specific r_hash receives
an open_channel message with push_msat >= the value of the request where
the temporary_channel_id contains the r_hash... that payment will be set to
a WAITING_OPEN status.
Once the channel is open, the payment moves to a PAID status.
If while waiting for channel to open in the WAITING_OPEN state, a routed
payment is received with the r_hash, accept that payment and change the
payment status to PAID.
Reasoning:
1. Open_channel can take up to 10 minutes, but most smartphone apps kill
background network processes for apps after 5 minutes or so.
2. If routing fails to pay someone. A wallet UI should ask the user:
"You have enough on-chain funds to send. What would you like to do?
1. Open channel & send
2. Send on-chain
3. Give up"
3. If we choose 1 in the current implementations, we would need to open a
channel, then wait... then remember to re-open the app as soon as the
channel is open. Then we need to paste the payment request again.
4. By allowing the person to "pay" with an open_channel, it allows people
to signal intent to pay... allowing payment processors that generate
payment requests with short expiration times to react to that intent
accordingly.
I think this might be good to add into BOLT 2... what does everyone
think?....... not sure.
Thanks for your input.
Jon
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180111/759776ff/attachment.html>

2023-06-09 12:47:59

- reply

📅 Original date posted:2017-12-15
📝 Original message:
iirc they are using the description as a way to join the user data and the
payment hash on their end.
htlc me is one node but separates its balance into user accounts that exist
outside lightning. I think the identifier is used so when their backend
checks the payment request status, the user info is right there in their
local lnd RPC response rather than having to store their own database
separately.
2017年12月16日(土) 8:31 Rusty Russell <rusty at rustcorp.com.au>:
> Jonathan Underwood <junderwood at bitcoinbank.co.jp> writes:
> > Additional comment: we should make a requirement to hide text in the
> > description under certain conditions.
> >
> > ie. "A reader MUST hide information surrounded by curly brackets {}
> > including
> > the brackets themselves from the UI, and only make the information
> avaiable
> > internally."
> >
> > I think a lot of people will want to include extra data in their payment
> > requests' description.
> >
> > I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)
>
> OK, HTLC.ME (cool site!) uses a description of:
>
> {"generic_id":"ada00363-50b6-4281-82dd-d274393439f1"}
>
> Which I really don't understand. This field is literally only to
> display to the user, for them to validate it's what they wanted. The
> recipient never gets it back.
>
> If I knew who ran HTLC.ME, I'd ask them to fix it: they should have a
> description entry field in their "Request Payment" form. It could
> default to "Test payment ada00363-50b6-4281-82dd-d274393439f1", but
> they're in spec violation at the moment.
>
> > Perhaps adding an "extra data" tag?
>
> Easy to do, if I knew why they wanted it.
>
> Thanks!
> Rusty.
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171215/c9ce5f9b/attachment.html>

2023-06-09 12:47:59

- reply

📅 Original date posted:2017-12-17
📝 Original message:
Just to let everyone know. I currently have full coverage and a few test
cases all ready to go.
All I really need is some edge cases. Any ideas are welcome.
bitcoinjs/bolt11
Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171217/05c927a6/attachment.html>

2023-06-09 12:47:58

- reply

📅 Original date posted:2017-12-12
📝 Original message:
I made a payment request using UTF-8 description here:
lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp
using this code: (I just separated encode from sign)
ln.sign(ln.encode({
tags:[
{
tagName:'payment_hash',
data:'0001020304050607080900010203040506070809000102030405060708090102'
},
{
tagName:'description',
data:'ナンセンス 1杯'
}
]
}, false),
Buffer.from('e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734',
'hex')).paymentRequest
Full results:
{
"coinType": "testnet",
"payeeNodeKey":
"03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad",
"paymentRequest":
"lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp",
"recoveryFlag": 1,
"satoshis": null,
"signature":
"cd3ea92522d777c9184756d7d437275358795b8a9771e2d9e434e5b1bff14d49433e465d74cde0787f2c2bfbe52b1bbb6450cad6970ea804ef054da63b9a0426",
"tags": [
{
"tagName": "payment_hash",
"data":
"0001020304050607080900010203040506070809000102030405060708090102"
},
{
"tagName": "description",
"data": "ナンセンス 1杯"
}
],
"timestamp": 1513055417,
"timestampString": "2017-12-12T05:10:17.000Z"
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/3389f867/attachment-0001.html>

2023-06-09 12:47:58

- reply

📅 Original date posted:2017-12-12
📝 Original message:
Haha, Rusty sent me a google translate of “cup of nonsense” (joining my
nonsense comment with the cup of coffee meme, since “cup of nonsense” seems
like a reasonable way to call something nonsense)
I fixed it to a more “looks like it would be on a receipt” format instead
of the direct translation which sounds more like the cup is made out of
nonsense instead of being filled with it.
Heh
Also, I don’t disagree with your assessment of the purpose commit hash, but
If the user is shown a description on a website and it says “please paste
this description into your wallet to verify the description with the
payment request”... I am pretty sure most users won’t bother, or will copy
paste incorrectly and get a big red error message.
I like to think of my mom trying to use it... and my mom accidentally
ordered a vacuum cleaner on Amazon once. (?????)
So yeah, I think if the wallet could somehow fetch it that would be best.
But for now, a simple description is fine imo.
Thanks,
Jon
2017年12月12日(火) 22:46 Johan Torås Halseth <johanth at gmail.com>:
> Just a few quick comments, as any improvements to BOLT#11 are very much
> appreciated :)
>
> * I think we should set a reasonable max length for invoices, that MUST be
> met. This would simplify internal database logic (since you don’t have to
> plan for invoices infinitely big), and could make sure the error detection
> is fair for all supported lengths. Not sure if 1023 is enough, considering
> possibly multiple `r` tags and a juicy description.
> * Agree with UTF-8 support, and up to 640 bytes length ( this can be made
> explicit in the Bolt, as now it is limited by the 5 bit length field) :)
> * Why must the description hash URL be part of the invoice? I always imagined
> this would be used between clients that already had agreed on payment for
> some kind of data, and that this hash would just ensure you were paying the
> correct one.
>
> - Johan
> (please explain the Japanese lightning meme plz)
> On Tue, Dec 12, 2017 at 6:15, Jonathan Underwood <
> junderwood at bitcoinbank.co.jp> wrote:
>
> I made a payment request using UTF-8 description here:
>
> lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp
>
> using this code: (I just separated encode from sign)
>
> ln.sign(ln.encode({
> tags:[
> {
> tagName:'payment_hash',
> data:'0001020304050607080900010203040506070809000102030405060708090102'
> },
> {
> tagName:'description',
> data:'ナンセンス 1杯'
> }
> ]
> }, false),
> Buffer.from('e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734',
> 'hex')).paymentRequest
>
>
> Full results:
>
> {
> "coinType": "testnet",
> "payeeNodeKey":
> "03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad",
> "paymentRequest":
> "lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp",
> "recoveryFlag": 1,
> "satoshis": null,
> "signature":
> "cd3ea92522d777c9184756d7d437275358795b8a9771e2d9e434e5b1bff14d49433e465d74cde0787f2c2bfbe52b1bbb6450cad6970ea804ef054da63b9a0426",
> "tags": [
> {
> "tagName": "payment_hash",
> "data": "0001020304050607080900010203040506070809000102030405060708090102"
> },
> {
> "tagName": "description",
> "data": "ナンセンス 1杯"
> }
> ],
> "timestamp": 1513055417,
> "timestampString": "2017-12-12T05:10:17.000Z"
> }
>
>
> _______________________________________________ Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/64cea8d1/attachment-0001.html>

2023-06-09 12:47:57

- reply

📅 Original date posted:2017-12-12
📝 Original message:
Rusty,
> I'm not sure what you're referring to? I've written two decoders, and
> both pull off the header and fixed fields, then iterate
> while (data_len > 520 / 5).
What happens if the signature is missing or the signature is improperly
formatted?
It is much easier to detect a case like that at the beginning if we have:
1. read 7 words for timestamp
2. read 3 words for tags_total_length
3. read tags_total_length words for the tags data
4. read 104 words for signature and recoveryID
Then immediately you can tell "oh, the signature is an invalid length"
rather than
having to decide whether "is the signature malformed or is the last tag
malformed?
if I run out of words while parsing a tag, is it because I just happened
upon a rare
case where I am parsing the signature as tags and the word just happened to
be a valid tag?"
I just think it should be explicit to help prevent problems
> I disagree. Obviously we can't force people to be descriptive (that's a
> SHOULD), but not including a description of the purpose of the payment
> is a mistake.
>
> The invoice and the preimage provides a cryptographic proof of
> purchase. But that's undermined if the description is missing.
I disagree, but this is not a huge issue so I withdraw my comment.
> From the ML welcome: "Be excellent to each other please!"
>
> I understand this mistake upset you, but "Sorry, but this is nonsense"
> makes me want to find spurious justifications for it. I prefer "This
> seems unfairly limiting", "This is a mistake" or "Woah, time to go 8
> bits, granddad!".
>
> The problem is the spec describes the 'd' field like so:
>
> short description of purpose of payment (ASCII), e.g. '1 cup of
coffee'
>
> There's nothing in the *requirements* section, at all.
>
> So, I think we should:
>
> 1. s/ASCII/UTF-8/
> - It seems everyone handles this fine anyway.
> 2. Add another example, here, which is in UTF-8, say "or 'ナンセンスのカップ'" :)
> 3. Add a requirement that the writer MUST use valid UTF-8.
> 4. Modify one of the examples to use a UTF-8 description.
Sorry I didn't mean to be offensive. I think I have been in Japan for too
long,
my English senses are dulling.
I agree with 1-4. "ナンセンス 1杯" is now a lightning meme. I am honored. ;)
> There is; no field can be greater than 640 bytes (1023 5-bit values).
> Also, the transport might have practical limits, so you might need to
> consider that in total. (Maybe not though, if you're going for QR
> codes, as they go pretty large).
640 bytes is rather long... but this is not really a huge issue for me.
So I withdraw my comment.
> Yes there should, but we left it open for the moment because there's no
> good solution here, and someone needs to come up with one. This makes
> description hash fairly useless for now, IMHO.
>
> A URL is the obvious solution, but has the terrible property that it
> de-anonymizes the wallet :( (even before the person has decided whether
> they want to pay).
>
> FWIW, there are a range of possible solutions, depending on the scenario:
> 1. If you have some container format, eg. HTML, include the description
as a
> separate tag.
> 2. Roasbeef wants to implement HORNET over our network, and that could
> be used to retrieve the full description.
>
> Meanwhile, 640 bytes should be enough for anyone!
HORNET sounds nice. Under this description, it seems like the plain
description
will be the primary method of communication for the forseeable future.
> Actually I think bech32 loses all guarantees at 1023 words, but it's no
> worse than a 30-bit checksum. We mainly use it because it's simple and
> available, and of course any fixed-length code will have some limit.
>
> What actually happens if we decode badly is that we derive the wrong
> public key for the node (50% chance, other 50% we get a signature
> failure) and we can't route to it or pay to it. So no funds are
> actually lost.
Unless the incorrect pubkey just happened to be someone elses!!! (/s)
Yeah I guess if we don't care about error correction, a 30 bit checksum is
still pretty good.
> Yes, this was *awesome*; I double-checked the values by hacking my
> python encoder, and adjusted for the recent r-encoding change. It's
> merged, thanks!
>
> https://github.com/lightningnetwork/lightning-rfc/pull/312
Glad I could be of help. :)
> That would be fantastic! We've talked about changing the test vectors
> (for all the BOLTs) into a more machine-friendly JSON encoding, so if
> you're feeling ambitious you could start with BOLT 11 :)
I'll have to work on that later this week. Currently trying to iron out our
Lightning
deposit / withdrawal UI with our front end engineer.
> Thanks!
You're welcome!
Additional comment: we should make a requirement to hide text in the
description under certain conditions.
ie. "A reader MUST hide information surrounded by curly brackets {}
including
the brackets themselves from the UI, and only make the information avaiable
internally."
I think a lot of people will want to include extra data in their payment
requests' description.
I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)
Perhaps adding an "extra data" tag?
... hmmm...
Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/ea57d5a7/attachment.html>

2023-06-09 12:47:56

- reply

📅 Original date posted:2017-12-11
📝 Original message:
ZmnSCPxj,
Thanks for the reply.
1. I agree that all naive implementations that do not follow UTF-8 spec
should perhaps be mentioned, to help people avoid mojibake corruption.
However, this problem is a problem as old as the internet itself (there are
still Japanese websites in shift-JIS encoding) and I think the consensus is
that UTF-8 is the standard. Allowing it in the description is fine as long
as the readers can decode the naive UTF-8 data correctly.
2. Normalization is only an issue when you need to hash something or
compare hash data so it is not an issue for the description, where the goal
is to relay information to the user.
(so maybe it could become an issue for the 256 bit description of purpose
of payment (SHA256) but not for the simple description)
In regards to the purpose commit hash, seeing as there is no specified way
to relay the data for the purpose commit hash, you could just solve it by
specifying the data to be fetched from a URL and having the data encoded as
a binary-stream with the exact bytes that were hashed and the UTF-8 parser
on the receiving app will just display it to the user. (since the goal is
to display info to the user, it doesn't matter if the word is using one
byte combination or the other, as long as you can verify the commit hash
matches the hash of the data and you then can display the data to the user)
Protocols like BIP39 require normalization because when a user inputs data,
they could be using any millions of IMEs that might use different unicode
codepoints to represent the same data as other IMEs... and we need to
ensure that the same human readable phrase ALWAYS is the same hash or else
money is lost (or hard to get to)
For description: "OMG I LOST 100 BTC BECAUSE THE DESCRIPTION SAID が instead
of が !!!" will never happen.
I would love to hear your thoughts on other aspects as well.
Thanks,
Jon
2017-12-11 20:10 GMT+09:00 ZmnSCPxj <ZmnSCPxj at protonmail.com>:
> Good morning Jonathan,
>
> >3. Descriptions say they can encode ASCII only. Sorry, but this is
> nonsense. Full unicode support via UTF8 should be supported.
>
> I generally agree, but caution must be warned here. In particular, we
> should be precise, which variant of UTF8.
>
> Presumably, a naive implementation, that specially treats 0 bytes (as
> would happen if the implementation were naively written in C or C++, where
> by default, strings are terminated by a 0 byte), should work correctly
> without having to particularly care, if the encoding is UTF8 or plain 7-bit
> ASCII. This then leads to the use of so-called Modified UTF8 as used by
> Java in its native interface: embedded null characters are encoded as
> extralong 3-byte UTF8 sequences, which are normally invalid in UTF8, but
> which naive treatment by C and C++ leads to (mostly) correct behavior.
> Should we use Modifed UTF8 or simply disallow null characters? (Use of
> ASCII does not avoid this, but ASCII has no alternative to null characters
> and the standard C string terminating byte 0).
>
> In addition, pulling in UTF8 brings in the issue, of Unicode
> normalization. Multiple different byte-sequences in UTF8 may lead to the
> same sequence of human-readable glyphs. Specifying ASCII avoids this
> issue. Should we specify some Unicode normalization, and should GUI at
> least try to impose this Unicode normalization (even if backends/daemons
> simply ignore the description and hence any normalization issues)?
>
> Regards,
> ZmnSCPxj
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171211/9da04785/attachment.html>

2023-06-09 12:47:56

- reply

📅 Original date posted:2017-12-10
📝 Original message:
Hello all,
Recently I have implemented BOLT11 in node JS. You can find it on github at
bitcoinjs/bolt11 (check the wip branch, I am still working on tests and
looking at maybe splitting encode up into two functions, encode and sign,
if anyone wants to help)
Here are some comments:
1. There should be a tags_length integer before the first tag. This will
get rid of the awkward dance of parsing from the front and end at the same
time and make it easier to detect poorly encoded data quickly.
2. Why is a description or description commit hash a MUST include tag... it
should be SHOULD.
3. Descriptions say they can encode ASCII only. Sorry, but this is
nonsense. Full unicode support via UTF8 should be supported.
4. There should be a maximum length (in bytes) for description. (Otherwise
why have a commit hash tag at all?)
5. There should be a recommendation for ways for the parsing client to
fetch the commited purpose description data. (Maybe encode a URL after the
32 byte commit hash?)
6. Lightning payment requests can get pretty long, but perhaps there should
be a limit. Apparently bech32 with the given parameters can only handle one
error correction once it is longer than 1023 words.
Now for some things on the BOLT document itself:
1. I made a pull request for adding signature preimage hex data etc. to the
examples to help people writing decoders. Some of the language was unclear
to me and lead to some goof ups.
2. Would be nice to have a fuller set of test cases on the RFC. I will work
on some cases to increase coverage on the bitcoinjs repo. Would be happy
for any help.
--
-----------------
Jonathan Underwood
ビットバンク社技術顧問
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFTSV/kBB/9FyhUaxI/2bfJ0pBp+y6YAim4LyOXeFDdtZL2C04T2eWBB+n2H
XD3r9CIifdqefnc0VCKwPe2hpbGXKNVy33tnp3m76CPVwKvIooE/gCcILJUIKwbd
j1ydsuUiErOhuRaral+iDhEaWuZmSZc1SiBANcufQvTru6o3Ne1MhozenpFHdyUX
L4zIgifglEKRRsQiqxpF8vyIo/A7u5bDZQPq1HAc9vL13Oe05ZhgXDMp0sgTfHVo
nd6gNSJxWb7PqDLunY+kvINawqePEADkAJlvcZbXpc07RuX8+/FSRI0LPmZin6w0
DuvzRAYAE/f1/OcqabWTIXbcmG3F32OmPS4PABEBAAG0MUpvbmF0aGFuIFVuZGVy
d29vZCA8anVuZGVyd29vZEBiaXRjb2luYmFuay5jby5qcD6JATIEEAEIACYFAlTS
V/0GCwkIBwMCCRCpJzta0+R7RQQVCAIKAxYCAQIbAwIeAQAAQXgH/jZh+WLLxx4S
znw5o53nROMn+WChasZ1cOoFzfAXRpFC5UZTXyTS1fMsA1vMA21B88FX/+UCxvCB
3EHN6MrUIinc8SFh/oZX/041dwfFOFaN2LsWJ5xF9pZpRdz4e+Bzbfyhe7MC/7d7
KsfwyiEWgPbH8N869SWdQqu8WIH9hIDyyWU4rNx9Un440lZJhN79Z58vaw1q3FRq
8qy+hKkMU7vi6PYq/D4WPrztfguqHe3vmtmlWaC8WGvy+AG7KEzinkc7VeIXdFtu
LV70t3L9GyAVNPM+RVxi/nDhQ2FW9tYA0jJ0VYpRltkrMHTvlnP+VRqb/qbvss0g
haD3C7bizCmJAS8EEAEIACMFAlTSV/0JEKknO1rT5HtFAhsDBgsJCAcDAgQVCAIK
AxYCAQAAj7IH/0Wip1XPxYO/VvEd7Q8wvyHUNfcX5EvVtRHvLzmeTMOsVjX2FQ/k
7Mi8JWrPMBYIAhqrO9TymaNk+O1FeP9j1VbEBtAviSrmMxeP97VbzuU53i3Fi0+i
HhGE432YEfeqJ6tUcPZQBa2RiASZ3CXNoWSdymy+gGWG8bnNU5HVStrpz0tMH2ur
mPTVhQAiTcBweRJYbUuyJyByre6JrDph9LjU8zELcncFmNwFvYaRWI9sKnqgYRx8
w+O/lDOmBkeDxtlyYZu3aRt82Ii7FH9Oca2NOr7AQDHda738Vb2Y8ZV6bCznk+fQ
fu2cWpYb721+srVEljabIjIJeIKlTrEhfDq0NUpvbmF0aGFuIFVuZGVyd29vZCA8
anVuZGVyd29vZEBibG9ja2NoYWluZGFpZ2Fra28uanA+iQE3BBMBCgAhBQJZShSg
AhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEKknO1rT5HtFO0oH/ju1XB75
P31SS5PfmzdARRjjj08JnaKeiOv5bXJwaDdhDpeaRVovk1gwObr5mHiIjkzuWNBc
9bunUGWpyuRbZm8oV4lY0hnfKsS6oVSav/qtr6UCQyWsvt/gkTwdx3YcHEQv3iFv
8LhUlGVRZY60gR6+S0bq03+vFfdrnQlvof7TC0F46SBCIZRud4vdKyxqXKKZz4z2
B0Al7BiDaAfz3wk820JzUFZV75VSFHZaSQL0ivbhA+Okskte/iI10w3fM+d/0gvh
YAY1l+ymoaAvutPbfNMM2Nx/m3LV1RrLZ/pKWG96HokhP8vldodnLTAaW2vFa0Wu
X0L3ScuGirCq2Fi5AQ0EVNJX/QEH/2LRn75y2UIPVVd9Og6gT6Hfwh6CK2PcmjRz
mGtY0ZU1wu/07CpAk3SP+5jm/o9FSVU46tE7d/VPw1gxj2vLryzsE8ticnUYtOVG
zCgFmZgzcj+E8HNGLo5BiNaVqFVc1sf/bf3bGytVFWRsPoJmNgLTvwtJOZNXtOD/
3IAAdiFRifeKDvElMlNhNNYOFncr+O16pnyesmQpg95nVbvww4t8QUjy5c2pg+9W
1ZLzlEY2GC8bsvhrQsikycyV/pRqzDJo3D+DPLlEB4xASmHnJh6vw0OgVieAt1Cc
WyzPZQRcEBUQ9TVemvoQ+CBeVEAlivXXHyGu4OPV9miV66G2WTkAEQEAAYkBJQQY
AQgADwIbDAUCWUIeCQUJCDItDAAKCRCpJzta0+R7RX31B/oD7QxOhrWcKXLSyygb
h5cEAzKOWkg1D3KWpWPfTjUH2w2SfIJAzCxRvxMmiOmRpOxFzmyDYRocBq71GYkt
ivJMfhxL/P93yQqcptWTAX5eUWyU0OG1MZ6sb64U62r5fmQg6QBD+/q+Gm98ytiL
UdRl5+YnTz6MhjFUK23rPxR2798RWimJo4Iz++8OZOHCrGO/2w59FiGfNF1iCMuP
bDV+7kq0qr0YzHIvGp3pdhQfF71xdbTEA3GxDCGHeVsKvsDgPtQo17HwBEnrSKJM
bhAtlgfqhSuZBCY2SVnX0abnpCiV/ULsZyUWj7nTscuX824pfyhE9Dy39EQWN5Z3
U8A7uQENBFlCHcMBCADvzo44svewnR+sQcBGqFo7dsir2RePRpKKk0vZn02PDvuT
qU1fspi6cZs8I8u10pt9L+CygVnqeema7k8UBNy+4UWT1ccBK45VKdIUCQxilRtV
GEG+bdv1ORkhE+do5jyeFV7cFLUhyO/aF+GnMgbtzuPRdR9+XV7P0J63aX3Xh5VG
XgsKNDJ3f/S2y718kyfytbtSIWXs0tR/drhGkWslP/9tjoup1wqCplPowse9932J
xa8jicbF/iNtIaKjXgK0Ue9aGFoggEg47iEGhc9nZ6LGIpOQS7B8PZVr1lQjje0h
FV574SS1NsAKf9q+DeUYc1jlys2KTv2DmFhfn5s3ABEBAAGJAkQEGAEIAA8CGwIF
AllCHgkFCQPCZ0YBKcBdIAQZAQgABgUCWUIdwwAKCRCyVhhdOpcZCLz1CAC13GDK
sesD922i6O9iG1XJpX+i8pFbtsXUE1eh4kmg1o+mMh6n9afWNPoXrgzgX8m4LwNU
WM+t2LoJQEPjIIoy6a3C3ekxvfFU0vT3DDnPrbnnsAFvnW2qIu1UqQanqT6k9Tws
iMYR+eEC5zOkNFYTzk5/4+uhAasm8PZ+DOKxD8pJk50pAu71huduBTFDT0CjGxpD
qw28Okuu79fZ6zF44A4epSg2nbslMRFNyVEKN6seSvTHKL52gtFZezjKaL7bZeni
7Vr8hU7xPO8xVlsBXZPRiogk0rqdb2q2z+X7R5ZJDwo6fwWXLZCTRImoavf+nDls
dtbSu17+ORn+7EN1CRCpJzta0+R7Rf4jB/sHT/FX5h7XR4rET39HRTdXd9ANoc8G
rKZil1kIqqafih8d0Jn8JGi7L2G10TwF2za1QL/bZfSq5fC9A/C+tyXvOkR2ZgOf
qDLacu7SAw4KiHImYD7MjPvQd4FFX7RaqNoTDmkoE+ss0YqkhViudGfXoI/YCWJv
VUVo0R57cbLRWlt7PZYUcKUYgS4EalxGvv9lzPXOFE5jpeIgCB6LOjN7Ak05gCIo
+EFOxvfUgb1o3wOtF7nfzTv6kygPX3EdDhLQRUel2pvYPooMnbHRyZ74NLs1B4Lv
fNUwHfPpdwu41B168qPlqj67NagQawJFZHfq1O8lwXEGNnmNx4K7ZaAG
=c+/G
-----END PGP PUBLIC KEY BLOCK-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171210/b337d63b/attachment.html>

2023-06-09 12:47:03

- reply

📅 Original date posted:2017-04-07
📝 Original message:
Hello all,
I have written up a very primitive BOLT for consideration.
https://gist.github.com/junderw/f6d0c023d7cefc1107a9c58d6d58aa5e
If you would please let me know what you think of it, and especially ways
we could possibly mitigate (or at least give the channel owners a fighting
chance) the scenario where a single attacker compromises both sides of the
channel, I would appreciate it.
Thank you,
Jonathan
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: http://openpgpjs.org
xsBNBFTSV/kBB/9FyhUaxI/2bfJ0pBp+y6YAim4LyOXeFDdtZL2C04T2eWBB
+n2HXD3r9CIifdqefnc0VCKwPe2hpbGXKNVy33tnp3m76CPVwKvIooE/gCcI
LJUIKwbdj1ydsuUiErOhuRaral+iDhEaWuZmSZc1SiBANcufQvTru6o3Ne1M
hozenpFHdyUXL4zIgifglEKRRsQiqxpF8vyIo/A7u5bDZQPq1HAc9vL13Oe0
5ZhgXDMp0sgTfHVond6gNSJxWb7PqDLunY+kvINawqePEADkAJlvcZbXpc07
RuX8+/FSRI0LPmZin6w0DuvzRAYAE/f1/OcqabWTIXbcmG3F32OmPS4PABEB
AAHNMUpvbmF0aGFuIFVuZGVyd29vZCA8anVuZGVyd29vZEBiaXRjb2luYmFu
ay5jby5qcD7CwHIEEAEIACYFAlTSV/0GCwkIBwMCCRCpJzta0+R7RQQVCAIK
AxYCAQIbAwIeAQAAQXgH/jZh+WLLxx4Sznw5o53nROMn+WChasZ1cOoFzfAX
RpFC5UZTXyTS1fMsA1vMA21B88FX/+UCxvCB3EHN6MrUIinc8SFh/oZX/041
dwfFOFaN2LsWJ5xF9pZpRdz4e+Bzbfyhe7MC/7d7KsfwyiEWgPbH8N869SWd
Qqu8WIH9hIDyyWU4rNx9Un440lZJhN79Z58vaw1q3FRq8qy+hKkMU7vi6PYq
/D4WPrztfguqHe3vmtmlWaC8WGvy+AG7KEzinkc7VeIXdFtuLV70t3L9GyAV
NPM+RVxi/nDhQ2FW9tYA0jJ0VYpRltkrMHTvlnP+VRqb/qbvss0ghaD3C7bi
zCnOwE0EVNJX/QEH/2LRn75y2UIPVVd9Og6gT6Hfwh6CK2PcmjRzmGtY0ZU1
wu/07CpAk3SP+5jm/o9FSVU46tE7d/VPw1gxj2vLryzsE8ticnUYtOVGzCgF
mZgzcj+E8HNGLo5BiNaVqFVc1sf/bf3bGytVFWRsPoJmNgLTvwtJOZNXtOD/
3IAAdiFRifeKDvElMlNhNNYOFncr+O16pnyesmQpg95nVbvww4t8QUjy5c2p
g+9W1ZLzlEY2GC8bsvhrQsikycyV/pRqzDJo3D+DPLlEB4xASmHnJh6vw0Og
VieAt1CcWyzPZQRcEBUQ9TVemvoQ+CBeVEAlivXXHyGu4OPV9miV66G2WTkA
EQEAAcLAXwQYAQgAEwUCVNJYAgkQqSc7WtPke0UCGwwAAAsUB/sGC6hlR5t1
zTJkJlSJb2Rg4iX1BXHpf/8DKFCrZ5UjsLkeAIJQxpSLtCKPFArPHLGLUowq
HtpCFRg30pCRSKdzlTTM4ossrnHjQj3AFyedodPeoYbWSUNgHiM7pY9m5uNL
I1Xg1K5AuAtrsD66vAtha5vL/ZIEmMkGl4mwC1dj4ueSCvfGP+xG5iGKiq8f
P+PDscI99YtbeaLknXjTEYZMkqCYOsEstWx6YLu13Ee8rwrk2TkeavUiybD+
PnaP3kISoaMPew3LNvnfc6ZJ/UxcEwmGf3UchSYRp3g/lMWcyFF624sszOQY
ULPn8N650ejg39n11SmCwk7aHoyYxfjs
=RpF5
-----END PGP PUBLIC KEY BLOCK-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170407/13d67ac2/attachment.html>

2023-06-07 18:27:34

- reply

📅 Original date posted:2020-11-26
📝 Original message:It is very common to set aside one or more "version slots" for proprietary
usage so that people adding their own features don't use version 7 only to
have the official BIP add a REAL version 7 a couple months later.
It makes perfect sense to just say "anyone adding their own stuff, format
your versions like this and stay out of our way"
As a BIP174 library, you don't have to add logic to "support" those
versions, just treat them as unknown. The only people who will need to
worry about the logic of parsing and encoding those versions are apps that
utilize them.
2020年11月17日(火) 8:41 Ferdinando M. Ametrano via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> After having checked that the BIP174 test vectors do not cover the
> *proprietary* and *proof-of-reserves* types, I went ahead and submitted a
> PR to the bips repo for the removal of those fields from the PSBT
> specifications
>
> https://github.com/bitcoin/bips/pull/1038
>
> --
> *Ferdinando M. Ametrano*
> www.ametrano.net/about
>
>
> On Tue, Nov 17, 2020 at 12:01 AM Ferdinando M. Ametrano <
> ferdinando at ametrano.net> wrote:
>
>> Hi all,
>>
>> While implementing PSBT support in the *btclib* library (
>> https://github.com/btclib-org/btclib), I have failed to understand the
>> rationale for the *proprietary* and *proof-of-reserves* types.
>>
>> First off, at face value they have nothing to do with the operations
>> intrinsically required to finalize a valid transaction from PSBT
>> manipulation.
>>
>> Moreover, whatever information content they can provide for non-standard
>> PSBT manipulation, that content could stay in the *unknown* field
>> without any loss of generality. How to structure and deal with unknown data
>> would be the responsibility of proprietary software or users wanting to
>> provide proof-of-reserve. As long as BIP174 clearly prescribes that
>> unknown data must be kept during PSBT manipulation, that should be enough.
>>
>> Let me stress the above point: I have a project where we include
>> proprietary information in the PSBT. Any PSBT software supporting unknown
>> data gently keeps our proprietary information and our proprietary software
>> retrieves that data from serialized PSBT with no problem. There is no need
>> for a PSBT implementation to provide explicit support for *proprietary*
>> and *proof-of-reserves* types.
>>
>> My last conclusion is reinforced by the evidence of all PSBT
>> implementations I know of, including bitcoin core and HWI, not implementing
>> proprietary and proof-of-reserve types. There is a high probability that
>> part of BIP174 would be just ignored.
>>
>> Am I missing something?
>>
>> Thanks
>> --
>> *Ferdinando M. Ametrano*
>> www.ametrano.net/about
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201127/e60d2a92/attachment.html>

2023-06-07 18:21:12

- reply

📅 Original date posted:2019-10-15
📝 Original message:I would also like to agree that Signet should be a BIP.
Problem: Testnet is unreliable. *Testnet is used often for development of
Bitcoin*.
Proposal: To improve the dev environment for Bitcoin, let's create a new
kind of testnet that is more reliable.
I would also like to hear the logic behind "Testnet is Bitcoin" but "Signet
is not Bitcoin"... both are not 100% compatible with mainnet consensus
processes.
-Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191015/c00dcd1e/attachment-0001.html>

2023-06-07 18:19:52

- reply

📅 Original date posted:2019-08-03
📝 Original message:My two cents:
1. Reserved types are awesome.
2. Varint for type is awesome.
3. BIP174 should specify a specific type for all (global, input, and
output) which means "see the BIP numbered in the next byte" so we can have
some sort of BIP43-ish system for BIP174... POR COMMITMENT and my current
signature protocol proposal should go in there.
More like three cents, but you get the idea.
I'll keep an eye on the bips repo. If someone wants to ping me once things
settle down I'll implement it.
Thanks,
Jon
2019年8月2日(金) 20:34 Dmitry Petukhov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> В Thu, 01 Aug 2019 19:01:06 +0000
> Andrew Chow <achow101-lists at achow101.com> wrote:
>
> > I spoke to some people OOB and they said that they didn't really like
> > the idea of having a prefix string (partially because they've already
> > implemented some proprietary types by simply squatting on unused
> > types). Matching the prefix string adds additional complexity to the
> > parser code.
>
> I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I
> would like to note that for those who do not want to deal with
> additional complexity of handling a prefixed string, they can simply
> not use it at all. Since this is a private construction, and their
> private format specifies 'no prefix', they can just ignore everything
> that does not start with "{0xFC}|{0x00}", thus any further complexity
> regarding the prefix is also ignored. The only added complexity is one
> condition check: second_byte_of_the_key != 0
>
> My other argument for conflict-avoidance prefix as a first thing after
> 0xFC is that the set of future users of PSBT and private types is
> most likely much larger than the current set of those who already
> implemented proprietary types on their own, and thus the overall benefit
> for the whole industry will likely be bigger when 'i do not want
> conflict avoidance' decision have to be explicit, by setting the prefix
> to 0x00, and the set of possible conflicting types are limited only to
> those entities that made this explicit decision.
>
> Regarding the 'squatted' types, it seems to me that this only matters
> in the discussed context if they squatted on 0xFC type in particular.
> In other cases, they will need to implement changes anyway, to be
> compatible with the BIP. Maybe they could consider that one additional
> condition check is a small burden, and maybe they can tolerate that,
> for the benefit of reducing possibility of interoperability problems
> between other future PSBT/private types implementors.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190804/52748714/attachment.html>

2023-06-07 18:19:40

- reply

📅 Original date posted:2019-07-23
📝 Original message:Hello All,
I have made a pull request based on the discussion currently. Please move
discussion there.
https://github.com/bitcoin/bips/pull/801
Thanks,
Jonathan
2019年6月29日(土) 17:11 Jonathan Underwood <junderwood at bitcoinbank.co.jp>:
> Even if the difference is apparent outside the signed data (in the
> output). Signing the data explicitly is more secure.
>
> ie. if some sort of vulnerability / way to break this system for 1-of-1
> multisig is found, someone who signed a single sig xpub whitelist will not
> be exposed.
>
> 2019年6月29日(土) 13:43 Dmitry Petukhov <dp at simplexum.com>:
>
>> В Sat, 29 Jun 2019 09:19:41 +0900
>> Jonathan Underwood <junderwood at bitcoinbank.co.jp> пишет:
>>
>> > > Other note: you have 'unused' value of 1 for `m` in your scheme, why
>> > > not require m=1 for single-sig case, and use 0 as indicator that
>> > > there are a serlal number following it?
>> > >
>> >
>> > 0x00 is single sig, aka, OP_CHECKSIG
>> >
>> > 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
>>
>> This informatin is available in per-output redeem/witness script,
>> signer will be able to distinguish between multisig/single-sig by
>> looking at this script. I think it only need to know the total number
>> of keys participating in the signing, and check that this number
>> matches the particulars of redeem/witness script.
>>
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190723/3a6f2496/attachment-0001.html>

2023-06-07 18:19:17

- reply

📅 Original date posted:2019-07-09
📝 Original message:Hi Andrew,
Ok, I will go ahead and write the amendment and make a PR.
Thanks!
Jon
2019年7月10日(水) 5:26 Andrew Chow <achow101-lists at achow101.com>:
> This was the original intent of the sighash field. Either the sighash is
> acceptable to the signer and the signer signs with it, or they do not sign
> at all.
>
> On 7/9/19 11:58 AM, Jonathan Underwood via bitcoin-dev wrote:
>
> Hi all,
>
> Just to be brief, I'll kick off with an attack scenario.
>
> 1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign
> according to the PSBT as-is.
> 2. I notice my UTXO was stolen by a hacker because they changed my PSBT
> input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the
> fact they changed the outputs to send to themselves, and added an input
> they signed with SIGHASH_ALL.
> 3. I lose the BTC in my UTXO.
>
> So we should definitely add to the signer checks "ensure the sighash type
> given is the type of sighash you want to sign." etc.
>
> My proposal for a wording change would be addition to the bullet list:
>
> - If a sighash type is provided, the signer MUST check that the sighash
> type is acceptable to them, and fail signing if unacceptable.
> - If a sighash type is not provided, the signer SHOULD sign using
> SIGHASH_ALL, but may sign with any sighash type they wish.
>
> Any thoughts?
>
> Thanks,
> Jon
>
> --
> -----------------
> Jonathan Underwood
> ビットバンク社チーフビットコインオフィサー
> -----------------
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190710/39f055d6/attachment.html>

2023-06-07 18:19:17

- reply

📅 Original date posted:2019-07-09
📝 Original message:Hi all,
Just to be brief, I'll kick off with an attack scenario.
1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign
according to the PSBT as-is.
2. I notice my UTXO was stolen by a hacker because they changed my PSBT
input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the
fact they changed the outputs to send to themselves, and added an input
they signed with SIGHASH_ALL.
3. I lose the BTC in my UTXO.
So we should definitely add to the signer checks "ensure the sighash type
given is the type of sighash you want to sign." etc.
My proposal for a wording change would be addition to the bullet list:
- If a sighash type is provided, the signer MUST check that the sighash
type is acceptable to them, and fail signing if unacceptable.
- If a sighash type is not provided, the signer SHOULD sign using
SIGHASH_ALL, but may sign with any sighash type they wish.
Any thoughts?
Thanks,
Jon
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190710/60601766/attachment.html>

2023-06-07 18:18:53

- reply

📅 Original date posted:2019-06-29
📝 Original message:Even if the difference is apparent outside the signed data (in the output).
Signing the data explicitly is more secure.
ie. if some sort of vulnerability / way to break this system for 1-of-1
multisig is found, someone who signed a single sig xpub whitelist will not
be exposed.
2019年6月29日(土) 13:43 Dmitry Petukhov <dp at simplexum.com>:
> В Sat, 29 Jun 2019 09:19:41 +0900
> Jonathan Underwood <junderwood at bitcoinbank.co.jp> пишет:
>
> > > Other note: you have 'unused' value of 1 for `m` in your scheme, why
> > > not require m=1 for single-sig case, and use 0 as indicator that
> > > there are a serlal number following it?
> > >
> >
> > 0x00 is single sig, aka, OP_CHECKSIG
> >
> > 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
>
> This informatin is available in per-output redeem/witness script,
> signer will be able to distinguish between multisig/single-sig by
> looking at this script. I think it only need to know the total number
> of keys participating in the signing, and check that this number
> matches the particulars of redeem/witness script.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/04fd8336/attachment.html>

2023-06-07 18:18:52

- reply

📅 Original date posted:2019-06-28
📝 Original message:replies in-line. Thanks!
2019年6月29日(土) 6:46 Dmitry Petukhov <dp at simplexum.com>:
> In your proposed field key format,
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> I think you can replace the signing pubkey with just a fingerprint of
> the master key, that would save 29 bytes per 0x02 field.
>
Good point.
> If the only entity that is concerned about the validity of the
> signature is those that possess the signing_privkey, it will check the
> signature when it sees the 0x02 field starting with its own key
> fingerprint, and will ignore the field if the signature does not match.
>
> If someone other than the signer needs to check that this xpub-package
> was signed by certain cold key, it will need to know signing_pubkey
> anyway, before it parses PSBT, as it won't have the means to check if
> certain pubkey found in 0x02 field in PSBT is related to certain
> signer, without knowing anything about the pubkey beforehand.
>
> I'm not sure if the ability of unrelated parties to verify that
> xpub-package matches its signature is useful in practice. 29 bytes per
> 0x02 field is not a big saving of space, and if this ability is actually
> useful, the saving may not be worh loosing this ability.
>
All good points, I think we'll just use the first 4 bytes of the hash160 of
the pubkey, aka fingerprint.
> Other note: you have 'unused' value of 1 for `m` in your scheme, why
> not require m=1 for single-sig case, and use 0 as indicator that there
> are a serlal number following it?
>
0x00 is single sig, aka, OP_CHECKSIG
0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
> The key for the field would be encoded as
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> for usual case, and
>
> {0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}
>
> for the case when the signing scheme actually cares about different
> versions of xpub packages signed by certain cold key
>
since OP_CHECKMULTISIG only supports at most 15-of-15 due to stack item
size limitations, we could make 0xff into this serial marker.
> Going back to the idea of moving 'complex' usecases outside of BIP174:
> maybe we could have a 'BIP-specific' field, that would have the key as
>
> {0x0?}|{BIP-number}|{bip-specific-suffix-data}
>
> so that the different usecases that are not general enough to be
> included in BIP174 itself, may have their own BIPs. Vendor-specific
> fields may also be done as a separate BIP.
>
Definitely sounds good, but the currently proposed 0x01 global type is
being added to BIP174 directly under the assumption that it is useful for
all users of PSBT, and I would argue that 0x01 being an HD change verifying
method, it only seems logical to add a similar method of "verifying"
non-self keys, aka whitelisting for security purposes, and such a feature
would require this data be included into the PSBT sent into the device.
If the consensus is that this data is unneeded, 0x01 should probably also
be a separate BIP.
Though outside the scope of this BIP, one difficulty of a whitelist feature
would be revocation of signatures. If we pre-sign a revocation cert and
somehow make the wallet blacklist if seen... then the question is "if your
signer has a trustworthy store of state, why not store the whitelist
pubkeys?"
But that feature itself should be a separate BIP.
Also, POR_COMMITMENT being in BIP174 kind of set a precedent... :-/
> В Thu, 27 Jun 2019 20:29:32 +0500
> Dmitry Petukhov <dp at simplexum.com> wrote:
>
> > Oh, I saw that you covered it in another mail:
> >
> > > The expire / revoke problem is a larger problem than this feature
> > > can handle.
> >
> > > In general, if one of the cold keys is stolen, there is rarely a
> > > situation where you are completely sure the other cold keys haven't
> > > been compromised... so the best practice would be all signers
> > > generate new keys and all funds are moved to a completely new
> > > multisig wallet (no common xpubs).
> >
> > The setup might not be 'all cold keys', but the keys with different
> > levels of exposure to possible theft. In this config, compromise of
> > one of the 'warm' keys might not necessary require changing the
> > 'cold' key.
> >
> > I'm not sure whether this usecase warrants adding extra 'serial'
> > field, but on the other hand it is rather simple change, and those who
> > does not care can always set 0.
> >
> > В Thu, 27 Jun 2019 18:14:29 +0500
> > Dmitry Petukhov <dp at simplexum.com> wrote:
> >
> > > What do you think about adding serial number to the xpub package ?
> > >
> > > The key would be
> > >
> > > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > >
> > > and if the signer have the ability to store a counter, it can reject
> > > 'outdated' xpub packages, and only accept those that was signed
> > > using the serial number that it deems recent. This would allow a
> > > limited mechanism to 'revoke' previously signed packages that have
> > > compromized keys in them.
> > >
> > > В Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
> > >
> > > > I see what you mean.
> > > >
> > > > What about this?
> > > >
> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
> > > >
> > > > Plus side: for single sig case, the key only increases by one byte
> > > > (0x00 for the {m} value)
> > > >
> > > > This way if it was 2 of 3 like before, you sign the whole "packet"
> > > > so each key only signs the packet once. Way better than n!
> > > >
> > > > Anywho. Please send your feedback. Thanks.
> > > > Jonathan
> > > >
> > > > 2019年6月27日(木) 16:27 Dmitry Petukhov <dp at simplexum.com>:
> > > >
> > > > > How would signer know that there _should_ be at least 3
> > > > > signatures signed by the key owned by this signer ?
> > > > >
> > > > > If it does not know that it should enforce 2of3 multisig, for
> > > > > example, the attacker that control only one key A can fool
> > > > > signer B by sending to 1of1 single-sig that is derived from A's
> > > > > xpub, and providing only sBxA in PSBT.
> > > > >
> > > > > If the signer does not have a hardcoded configuration that
> > > > > will mandate a particular multisig scheme, it will allow sending
> > > > > to any scheme.
> > > > >
> > > > > If the signer has a rich enough state to store updatable
> > > > > configuration, it can just store the trusted xpubs directly.
> > > > >
> > > > > Alternatively, signer can sign not individual xpubs, but whole
> > > > > xpub packages that correspond to particular multisig
> > > > > configuration, and enforce that destination addresses correspond
> > > > > to this configuration.
> > > > >
> > > > > But this would not be possible with your PSBT scheme that uses
> > > > > individual key-xpub pairs.
> > > > >
> > > > > В Thu, 27 Jun 2019 14:07:47 +0900
> > > > > Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
> > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > The way we would do it is:
> > > > > >
> > > > > > Let's say we have 3 cold keys for multisig: A B and C
> > > > > >
> > > > > > Whose xpubs are: xA xB and xC
> > > > > >
> > > > > > We all sign each other's xpubs, whose signatures are:
> > > > > > sAxB
> > > > > > sAxC
> > > > > > sBxA
> > > > > > sBxC
> > > > > > sCxA
> > > > > > sCxB
> > > > > >
> > > > > > We can then create a wallet that says "when verifying change
> > > > > > with 0x01 global type proposed by Andrew Chow, if the change
> > > > > > is multisig, we MUST require the other pubkeys to have
> > > > > > signatures via my 0x02 proposal"
> > > > > >
> > > > > > This way, all my PSBTs for my cold will have:
> > > > > > 1. an 0x01 entry to tell me how to get my change.
> > > > > > 2. All 6 of the signatures above.
> > > > > >
> > > > > > And the signer will then look at the change, check my pubkey
> > > > > > by deriving the xpub and checking equality to the
> > > > > > BIP_DERIVATION of the output... it will then check the OTHER
> > > > > > pubkeys via BIP32_DERIVATION to master fingerprint, then link
> > > > > > that fingerprint to a 0x02 sig from MY key, verifying all
> > > > > > pubkeys.
> > > > > >
> > > > > > So this proposal of mine would not only fix the "send to
> > > > > > address verification" problem for HD, but also the multisig
> > > > > > change problem with 0x01.
> > > > > >
> > > > > > Cool.
> > > > > >
> > > > > > Only thing that is kind of sad is having to include n! (of
> > > > > > m-of-n) signatures in every PSBT... but tbh, the PSBT size is
> > > > > > not of much concern.
> > > > > >
> > > > > > Thanks for the reply.
> > > > > > - Jonathan
> > > > > >
> > > > > >
> > > > > > 2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I wonder how your scheme handles multisig ?
> > > > > > >
> > > > > > > As I understand, you sign individual xpubs with cold keys,
> > > > > > > so that cold keys can check destination addresses are
> > > > > > > trusted.
> > > > > > >
> > > > > > > I seems to me that if you sign individual xpubs of a
> > > > > > > multisig warm wallet, and one key from that multisig is
> > > > > > > compromized, attackers can then create a single-sig
> > > > > > > destination address that they control, and move the coins
> > > > > > > in a chain of two transactions, first to this single-sig
> > > > > > > address, and then to an address that they independently
> > > > > > > control.
> > > > > > >
> > > > > > > My idea to prevent this [1] is to sign the whole 'xpub
> > > > > > > package' of the multisig wallet, but there is also an issue
> > > > > > > of 'partial compromize', where some of the keys in a
> > > > > > > multisig warm wallet is compromized, and you do not want to
> > > > > > > regard a particular 'xpub package' as trusted. My idea was
> > > > > > > [2] to use an auxiliary message that would be signed along
> > > > > > > with the 'xpub package', and that message can include
> > > > > > > specific 'epoch' word that hardware wallet can show
> > > > > > > prominently before signing, or have 'serial number' for
> > > > > > > xpub packages (but that will require to store last known
> > > > > > > serial inside hw wallet, making it stateful).
> > > > > > >
> > > > > > > I like the idea to extend PSBT to accomodate these schemes,
> > > > > > > but given that the huge number of possible schemes that each
> > > > > > > may probably require its own PSBT field type, I think that
> > > > > > > this is better dealt with outside of PSBT, as 'PSBT
> > > > > > > metainformation', or using some form of 'vendor-specific',
> > > > > > > or 'metainformation-specific' PSBT field. This way each
> > > > > > > usecase can be independently described in its own
> > > > > > > documentation, that would include the particulars of the
> > > > > > > format for the metainformation. This would also make it
> > > > > > > easier to implement PSBT for simple cases, because the
> > > > > > > 'core specification' would not grow that big.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
>
> > > > > > >
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
>
> > > > > > >
> > > > > > >
> > > > > > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > > > bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > Just wanted to pick your brains about an idea for PSBT
> > > > > > > > extension.
> > > > > > > >
> > > > > > > > One problem we try to solve with cold -> warm and warm ->
> > > > > > > > hot sends for our exchange wallet is "How do I know that
> > > > > > > > the address I am sending to is not a hacker's address
> > > > > > > > that was swapped in between unsigned tx creation and first
> > > > > > > > signature?"
> > > > > > > >
> > > > > > > > We have a proprietary JSON based encoding system which we
> > > > > > > > are looking to move towards PSBT, but PSBT is missing this
> > > > > > > > key functionality.
> > > > > > > >
> > > > > > > > BIP32_DERIVATION does allow us to verify the address is
> > > > > > > > from a certain XPUB, but, for example, it can not allow us
> > > > > > > > to verify a signature of that xpub.
> > > > > > > >
> > > > > > > > I have made a rough draft of the proposed key value
> > > > > > > > specification.
> > > > > > >
> > > > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
> > > > >
> > > > > > > >
> > > > > > > > The signing key path used in the spec is just randomly
> > > > > > > > chosen 31 x 4 bits shown as numbers with hardened paths.
> > > > > > > >
> > > > > > > > Since this issue seems similar to the change address
> > > > > > > > issue, I started from that as a base. With the HW wallet
> > > > > > > > case, I can verify the xpub by just deriving it locally
> > > > > > > > and comparing equality, however, in our case, we need to
> > > > > > > > verify an xpub that we do not have access to via
> > > > > > > > derivation from our cold key(s) (since we don't want to
> > > > > > > > import our warm private key into our cold signer)
> > > > > > > >
> > > > > > > > So the flow would be:
> > > > > > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > > > > > 2. Using the airgap signing tool, sign the xpub with all
> > > > > > > > cold keys. 3. Upload the signature/xpub pairs to the
> > > > > > > > online unsigned transaction generator.
> > > > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > > > > > 5. When offline signing, if the wallet detects there is a
> > > > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key,
> > > > > > > > it must verify that all outputs have BIP32_DERIVATION and
> > > > > > > > that it can verify the outputs through the derivation, to
> > > > > > > > the xpub, and to the signature.
> > > > > > > >
> > > > > > > > In my attempt to fitting this into PSBT, I am slightly
> > > > > > > > altering our current system, so don't take this as an
> > > > > > > > indication 100% of how we work in the backend.
> > > > > > > >
> > > > > > > > However, I would like to hear any feedback on this
> > > > > > > > proposal.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/aed02387/attachment-0001.html>

2023-06-07 18:18:49

- reply

📅 Original date posted:2019-06-27
📝 Original message:> By the way, why is this particular path ?
The signing key path used in the spec is just randomly chosen 31 x 4 bits
shown as numbers with hardened paths. Just wanted to make sure it wasn't a
key that people are likely to use for something else.
> It is not clear to me what public key this refers to
I just used the same sentence from the other proposal for 0x01 global tag.
It is kind of confusing, but "can be derived" implies that it is referring
to an xpub, since normal public keys can not "derive children"...
But I could change it if it would be clearer.
2019年6月27日(木) 18:47 Dmitry Petukhov <dp at simplexum.com>:
> " It should be the public key at the highest hardened derivation index
> so that the unhardened child keys used in the transaction can be
> derived."
>
> It is not clear to me what public key this refers to - does this
> refer to 'signing pubkey' ? - then the exact derivation indexes for that
> are given in the value section:
>
> m/2042083607'/959190427'/1400854130'/990526201'
>
> By the way, why is this particular path ?
>
> В Thu, 27 Jun 2019 17:16:14 +0900
> Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
>
> > I see what you mean.
> >
> > What about this?
> >
> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
> >
> > Plus side: for single sig case, the key only increases by one byte
> > (0x00 for the {m} value)
> >
> > This way if it was 2 of 3 like before, you sign the whole "packet" so
> > each key only signs the packet once. Way better than n!
> >
> > Anywho. Please send your feedback. Thanks.
> > Jonathan
> >
> > 2019年6月27日(木) 16:27 Dmitry Petukhov <dp at simplexum.com>:
> >
> > > How would signer know that there _should_ be at least 3 signatures
> > > signed by the key owned by this signer ?
> > >
> > > If it does not know that it should enforce 2of3 multisig, for
> > > example, the attacker that control only one key A can fool signer B
> > > by sending to 1of1 single-sig that is derived from A's xpub, and
> > > providing only sBxA in PSBT.
> > >
> > > If the signer does not have a hardcoded configuration that
> > > will mandate a particular multisig scheme, it will allow sending to
> > > any scheme.
> > >
> > > If the signer has a rich enough state to store updatable
> > > configuration, it can just store the trusted xpubs directly.
> > >
> > > Alternatively, signer can sign not individual xpubs, but whole xpub
> > > packages that correspond to particular multisig configuration, and
> > > enforce that destination addresses correspond to this configuration.
> > >
> > > But this would not be possible with your PSBT scheme that uses
> > > individual key-xpub pairs.
> > >
> > > В Thu, 27 Jun 2019 14:07:47 +0900
> > > Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
> > >
> > > > Thanks for the reply.
> > > >
> > > > The way we would do it is:
> > > >
> > > > Let's say we have 3 cold keys for multisig: A B and C
> > > >
> > > > Whose xpubs are: xA xB and xC
> > > >
> > > > We all sign each other's xpubs, whose signatures are:
> > > > sAxB
> > > > sAxC
> > > > sBxA
> > > > sBxC
> > > > sCxA
> > > > sCxB
> > > >
> > > > We can then create a wallet that says "when verifying change with
> > > > 0x01 global type proposed by Andrew Chow, if the change is
> > > > multisig, we MUST require the other pubkeys to have signatures
> > > > via my 0x02 proposal"
> > > >
> > > > This way, all my PSBTs for my cold will have:
> > > > 1. an 0x01 entry to tell me how to get my change.
> > > > 2. All 6 of the signatures above.
> > > >
> > > > And the signer will then look at the change, check my pubkey by
> > > > deriving the xpub and checking equality to the BIP_DERIVATION of
> > > > the output... it will then check the OTHER pubkeys via
> > > > BIP32_DERIVATION to master fingerprint, then link that
> > > > fingerprint to a 0x02 sig from MY key, verifying all pubkeys.
> > > >
> > > > So this proposal of mine would not only fix the "send to address
> > > > verification" problem for HD, but also the multisig change problem
> > > > with 0x01.
> > > >
> > > > Cool.
> > > >
> > > > Only thing that is kind of sad is having to include n! (of m-of-n)
> > > > signatures in every PSBT... but tbh, the PSBT size is not of much
> > > > concern.
> > > >
> > > > Thanks for the reply.
> > > > - Jonathan
> > > >
> > > >
> > > > 2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:
> > > >
> > > > > Hi!
> > > > >
> > > > > I wonder how your scheme handles multisig ?
> > > > >
> > > > > As I understand, you sign individual xpubs with cold keys, so
> > > > > that cold keys can check destination addresses are trusted.
> > > > >
> > > > > I seems to me that if you sign individual xpubs of a multisig
> > > > > warm wallet, and one key from that multisig is compromized,
> > > > > attackers can then create a single-sig destination address that
> > > > > they control, and move the coins in a chain of two
> > > > > transactions, first to this single-sig address, and then to an
> > > > > address that they independently control.
> > > > >
> > > > > My idea to prevent this [1] is to sign the whole 'xpub package'
> > > > > of the multisig wallet, but there is also an issue of 'partial
> > > > > compromize', where some of the keys in a multisig warm wallet is
> > > > > compromized, and you do not want to regard a particular 'xpub
> > > > > package' as trusted. My idea was [2] to use an auxiliary message
> > > > > that would be signed along with the 'xpub package', and that
> > > > > message can include specific 'epoch' word that hardware wallet
> > > > > can show prominently before signing, or have 'serial number'
> > > > > for xpub packages (but that will require to store last known
> > > > > serial inside hw wallet, making it stateful).
> > > > >
> > > > > I like the idea to extend PSBT to accomodate these schemes, but
> > > > > given that the huge number of possible schemes that each may
> > > > > probably require its own PSBT field type, I think that this is
> > > > > better dealt with outside of PSBT, as 'PSBT metainformation', or
> > > > > using some form of 'vendor-specific', or
> > > > > 'metainformation-specific' PSBT field. This way each usecase
> > > > > can be independently described in its own documentation, that
> > > > > would include the particulars of the format for the
> > > > > metainformation. This would also make it easier to implement
> > > > > PSBT for simple cases, because the 'core specification' would
> > > > > not grow that big.
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
>
> > > > >
> > > > > [2]
> > > > >
> > > > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
>
> > > > >
> > > > >
> > > > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > Just wanted to pick your brains about an idea for PSBT
> > > > > > extension.
> > > > > >
> > > > > > One problem we try to solve with cold -> warm and warm -> hot
> > > > > > sends for our exchange wallet is "How do I know that the
> > > > > > address I am sending to is not a hacker's address that was
> > > > > > swapped in between unsigned tx creation and first signature?"
> > > > > >
> > > > > > We have a proprietary JSON based encoding system which we are
> > > > > > looking to move towards PSBT, but PSBT is missing this key
> > > > > > functionality.
> > > > > >
> > > > > > BIP32_DERIVATION does allow us to verify the address is from a
> > > > > > certain XPUB, but, for example, it can not allow us to verify
> > > > > > a signature of that xpub.
> > > > > >
> > > > > > I have made a rough draft of the proposed key value
> > > > > > specification.
> > > > >
> > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
> > >
> > > > > >
> > > > > > The signing key path used in the spec is just randomly chosen
> > > > > > 31 x 4 bits shown as numbers with hardened paths.
> > > > > >
> > > > > > Since this issue seems similar to the change address issue, I
> > > > > > started from that as a base. With the HW wallet case, I can
> > > > > > verify the xpub by just deriving it locally and comparing
> > > > > > equality, however, in our case, we need to verify an xpub
> > > > > > that we do not have access to via derivation from our cold
> > > > > > key(s) (since we don't want to import our warm private key
> > > > > > into our cold signer)
> > > > > >
> > > > > > So the flow would be:
> > > > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > > > 2. Using the airgap signing tool, sign the xpub with all cold
> > > > > > keys. 3. Upload the signature/xpub pairs to the online
> > > > > > unsigned transaction generator.
> > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > > > 5. When offline signing, if the wallet detects there is a
> > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key, it
> > > > > > must verify that all outputs have BIP32_DERIVATION and that
> > > > > > it can verify the outputs through the derivation, to the
> > > > > > xpub, and to the signature.
> > > > > >
> > > > > > In my attempt to fitting this into PSBT, I am slightly
> > > > > > altering our current system, so don't take this as an
> > > > > > indication 100% of how we work in the backend.
> > > > > >
> > > > > > However, I would like to hear any feedback on this proposal.
> > > > > >
> > > > > > Thanks,
> > > > > > Jonathan
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/e247bc0d/attachment.html>

2023-06-07 18:18:49

- reply

📅 Original date posted:2019-06-28
📝 Original message:Thanks for the reply Peter. Comments inline:
2019年6月28日(金) 23:37 Peter D. Gray <peter at coinkite.com>:
> Thanks I get the idea better now: You want the PSBT creator to be
> able to indicate to the signers that it (the PSBT creator) controls
> specific outputs that don't otherwise look like change.
>
> Some problems:
>
> > extended private key of the current signer derived from the
> > signer's root to m/2042083607'/959190427'/1400854130'/990526201'
>
> 1) The PSBT creator would need to know that private key, and the Coldcard,
> as a matter
> of policy, will never export a private subkey.
>
I think you have misunderstood. The signature inserted into this 0x02 field
is generated BY the signer (Coldkey) airgapped ahead of time. Then the
signature (and all the xpubs that were signed, since basically the "key"
value contains the "pubkey" and "message" while the "value" part has the
"signature". so all data items for verification are present.) will be
stored on the unsigned transaction preparing app. (MyTrezor dot com etc.
have an encrypted storage through Dropbox + encrypting with Trezor, so
they, for instance, could store the "whitelist signatures" on that dropbox
feature.
> 2) The 'm' in that path depends on who is reading the PSBT file, in the
> multisig
> case. Each cosigner would need a different version of the PSBT file
Again, this is the m of the signer's root. The signer should have an xprv,
or some sort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that
gets turned into a xprv. That xprv is m in this case... in the case that
some offline signer is storing the xprv of some path like "xprv/25'/42'" or
something, then the signer's "identity" is whatever xprv that signer holds
and not any of the xprvs derived from that first xprv.
The reason we want only one HD key to sign it is because we want the signer
to be able to generate that path from the root xprv they hold, check that
the pubkey matched the pubkey for verification, then verify. Now the signer
knows "oh, I have signed this xpub / multisig setup before, therefore I
trust it"
> 3) XPUB's are big and hard to parse, and this addition is using lots of
> them.
>
Any app requiring this level of security would gladly add a few millisecond
for parsing some xpubs.
Any HD wallet that can sign using HD derived keys already has the necessary
tools to parse an xpub.
> 4) Coinjoins, and more complex script types, will want to authorize
> outputs that the PSBT signer may not fully understand. Your proposal
> would only help P2PKH and M-of-N multisig users.
>
Yes. This proposal is not a requirement. It is just a reservation for a
slot in the key-value scheme for a use case that many exchanges and
hardware wallets should implement. We have implemented something similar to
this using JSON format internally, but since HW wallet makers seem to be
moving toward PSBT adoption, I would love for this info to be possible to
be sent into an HW wallet so that Trezor etc. can implement this
"whitelist" type situation in a way that the Trezor can trust. (remember, a
"whitelist" that just lives in my trezor dot com website cache etc. is
prone to modification, whereas with my proposal the worst case is a hacker
deletes a signature, so Trezor doesn't trust something it should have, and
fails signing. It can not add itself to the "whitelist" without the HW
wallet private key.)
To fix, may I propose:
>
>
The following suggestions seems to be predicated on a misunderstanding of
my proposal, so I will hold off for now.
> - the signer and PSBT creator must share a pubkey/private key out of band
> (setup time)
> - the origin of that key is out of scope of this standard (but it could be
> derived via BIP32)
> - the PSBT creator can, optionally, sign any or all output sections by
> number using that key
>
> I would prefer the signatures are in the global section, and the
> signature is over all the bytes in the indicated output section,
> as originally serialized when it came into the signer's possession.
>
> We should be able to support multiple signers for individual outputs,
> and also multiple signatures for the same output section. That would
> support different derived keys per co-signer, and also quorum
> approval or other policies like that.
>
> Afterthought: Might be good to allow signature over the unsigned
> transaction, or
> maybe it should be part of the signature always.
>
> ---
> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> A3A31BAD 5A2A5B10
>
> On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> > Hi Peter,
> >
> > tl;dr The problem this solves is "How can a signer verify an address with
> > HD changing the address every time?"
> >
> > As an aside: (This is sort of explaining the current PR for the 0x01
> global
> > field (separate from mine))
> > The problem is more easily understood with change addresses: If someone
> can
> > alter my PSBT before signing, they could replace my change address with
> > their address, and my signer would not know unless the signer just
> guesses
> > all the path sets it knows, then derives thousands of change addresses
> and
> > searches (most likely a signer is offline, so gap limit doesn't work
> since
> > we can't tell which change addresses have tx history. So the 0x01 global
> > tag will tell the signer "here's how you get from your master private key
> > to the xpub used in the change output's output BIP32_DERIVATION tag...
> you
> > can then derive the same key and check it is yours before signing."
> >
> > Back to my proposal, this problem extends across wallets, since,
> > for example, if I want to send from my cold wallet to my warm wallet, I
> > don't want to give my cold signer my warm master key just so it can
> derive
> > and check the key. That's what signatures are for. So this proposal says
> "A
> > signer can be built to only sign if it sees a signature that itself has
> > signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> > outputs, and if the output doesn't match it will reject and not sign"
> >
> > This creates a sort of "chain of trust" for the wallet.
> >
> > Currently the best way to prevent this (hacker swapping the send to
> > address) without using signatures is to reuse the same address every time
> > you want to send to the warm wallet, since after a few times, the signers
> > (people) will be able to remember the address.
> >
> > This is a huge HD drawback for high security requirement environments.
> > Having this data in the PSBT standard will allow Trezor etc. to create an
> > enforceable whitelist feature.
> >
> > Let me know if you have feedback on the details.
> >
> > Thanks,
> > Jon
> >
> > 2019年6月28日(金) 0:07 Peter D. Gray <peter at coinkite.com>:
> >
> > > I haven't studied the new proposal in depth, but my first impression
> is:
> > >
> > > Wouldn't it just be easier and better to just sign the entire "outputs"
> > > section of the PSBT?
> > >
> > > The signature would cover every byte, and therefore would cover any
> > > future BIP additions to the outputs area, and also help non-multisig
> > > cases today.
> > >
> > > ---
> > > Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> > > A3A31BAD 5A2A5B10
> > >
> > >
> >
> > --
> > -----------------
> > Jonathan Underwood
> > ビットバンク社チーフビットコインオフィサー
> > -----------------
> >
> > 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
> >
> > 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/4b55a1c7/attachment-0001.html>

2023-06-07 18:18:48

- reply

📅 Original date posted:2019-06-27
📝 Original message:Hi Peter,
tl;dr The problem this solves is "How can a signer verify an address with
HD changing the address every time?"
As an aside: (This is sort of explaining the current PR for the 0x01 global
field (separate from mine))
The problem is more easily understood with change addresses: If someone can
alter my PSBT before signing, they could replace my change address with
their address, and my signer would not know unless the signer just guesses
all the path sets it knows, then derives thousands of change addresses and
searches (most likely a signer is offline, so gap limit doesn't work since
we can't tell which change addresses have tx history. So the 0x01 global
tag will tell the signer "here's how you get from your master private key
to the xpub used in the change output's output BIP32_DERIVATION tag... you
can then derive the same key and check it is yours before signing."
Back to my proposal, this problem extends across wallets, since,
for example, if I want to send from my cold wallet to my warm wallet, I
don't want to give my cold signer my warm master key just so it can derive
and check the key. That's what signatures are for. So this proposal says "A
signer can be built to only sign if it sees a signature that itself has
signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
outputs, and if the output doesn't match it will reject and not sign"
This creates a sort of "chain of trust" for the wallet.
Currently the best way to prevent this (hacker swapping the send to
address) without using signatures is to reuse the same address every time
you want to send to the warm wallet, since after a few times, the signers
(people) will be able to remember the address.
This is a huge HD drawback for high security requirement environments.
Having this data in the PSBT standard will allow Trezor etc. to create an
enforceable whitelist feature.
Let me know if you have feedback on the details.
Thanks,
Jon
2019年6月28日(金) 0:07 Peter D. Gray <peter at coinkite.com>:
> I haven't studied the new proposal in depth, but my first impression is:
>
> Wouldn't it just be easier and better to just sign the entire "outputs"
> section of the PSBT?
>
> The signature would cover every byte, and therefore would cover any
> future BIP additions to the outputs area, and also help non-multisig
> cases today.
>
> ---
> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> A3A31BAD 5A2A5B10
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/eee0ccf7/attachment.html>

2023-06-07 18:18:47

- reply

📅 Original date posted:2019-06-27
📝 Original message:There is no need, as you can look at the number of xpubs and use that as n.
Your wallet will not allow {m=2}{xpub1}{xpub2} signed message to vouch for
2 of 4 because you signed 2 of 2 where the n is shown by the number of
xpubs signed.
There is no need to add the extra byte, except maybe to help people who are
implementing a wallet checking some features to remember to check for the
number of total keys.
----
The expire / revoke problem is a larger problem than this feature can
handle.
In general, if one of the cold keys is stolen, there is rarely a situation
where you are completely sure the other cold keys haven't been
compromised... so the best practice would be all signers generate new keys
and all funds are moved to a completely new multisig wallet (no common
xpubs).
- Jonathan
2019年6月27日(木) 18:20 Dmitry Petukhov <dp at simplexum.com>:
> You're right re order of the keys, I forgot that redeem/witness
> scripts are included in outputs.
>
> But regarding the number of the keys, you need to always include all of
> xpubs, because otherwise, if you only put `m` in PSBT, and you use
> 2of3, for example, attacker may put 2 as `m`, two of your xpubs, but
> then use redeem/witness scripts for 2of4, where two other keys are
> under attacker's control.
>
> If you only encode `n`, and allow any 'm of n' scheme, then in 2of3
> case, if the attackers have control of only one of the keys, they can
> use redeem/witness scripts for 1of3, where two other keys are under
> their control.
>
> It seems to me that you need to sign the whole configuration:
> `n`, `m`, and the xpubs.
>
> And then there's a question of how to conveniently `expire` the keys
> that were compromized. If the attackers have a signature of
> `n+n+xpubs` package for some configuration that include the keys that
> was compromized, they can use that old signed package to fool the
> signer.
>
> Signer would need to somehow distinguish between old and new
> configurations, or you would need to change the keys in all the signers
> even if one is compromized, so the already-signed packages would become
> invalid.
>
> You could do without changing all the keys when only one is compromized
> by including a serial number in the xpub package (but that means signer
> will need to have a state where it would store the latest serial
> number), or you need some message to be included in the package that a
> human can check when manually signing, to ensure that 'obsolete' xpub
> package was not used.
>
> В Thu, 27 Jun 2019 17:56:06 +0900
> Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
>
> > The output will have redeemscript and witnessscript so order is not
> > necessary. I can just look at the multisig script and find the pubkey
> > inside it.
> >
> > -Jonathan
> >
> > 2019年6月27日(木) 17:45 Dmitry Petukhov <dp at simplexum.com>:
> >
> > > > m value for a multisig (set 0 for non-multisig), followed by 1 or
> > > > more 78 byte serialized extended public keys sorted in canonical
> > > > order
> > >
> > > Sorting xpubs would work if the addresses also sort their pubkeys
> > > (like in BIP67)
> > >
> > > But if the pubkey order in address creation is fixed, you better
> > > have the fixed order for xpubs, otherwise you would need to try all
> > > combinations of derived pubkeys when checking if the addresss match
> > > the presented xpubs. That would be factorial of the number of keys,
> > > not feasible beyond very small number of keys.
> > >
> > > Bitcoin Core, for example, currently does not support BIP67 and
> > > supports only fixed pubkey positions in their script descriptors
> > > specification.
> > >
> > > You also need to include all xpubs to match the address, for m of n
> > > standard multisig, you need to include n and check that number of
> > > keys is exactly n.
> > >
> > > Otherwise your would not be able to construct the address to
> > > compare to the destination address that you need to check, as you
> > > need all pubkesy to construct P2SH or P2WSH address.
> > >
> > > With Shnorr-musig, you probably can interpolate the combined pubkey
> > > out of m paticpant pubkeys (but don't cite me on this, I might be
> > > wrong)
> > >
> > > В Thu, 27 Jun 2019 17:16:14 +0900
> > > Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
> > >
> > > > I see what you mean.
> > > >
> > > > What about this?
> > > >
> > >
> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
>
> > > >
> > > > Plus side: for single sig case, the key only increases by one byte
> > > > (0x00 for the {m} value)
> > > >
> > > > This way if it was 2 of 3 like before, you sign the whole
> > > > "packet" so each key only signs the packet once. Way better than
> > > > n!
> > > >
> > > > Anywho. Please send your feedback. Thanks.
> > > > Jonathan
> > > >
> > > > 2019年6月27日(木) 16:27 Dmitry Petukhov <dp at simplexum.com>:
> > > >
> > > > > How would signer know that there _should_ be at least 3
> > > > > signatures signed by the key owned by this signer ?
> > > > >
> > > > > If it does not know that it should enforce 2of3 multisig, for
> > > > > example, the attacker that control only one key A can fool
> > > > > signer B by sending to 1of1 single-sig that is derived from A's
> > > > > xpub, and providing only sBxA in PSBT.
> > > > >
> > > > > If the signer does not have a hardcoded configuration that
> > > > > will mandate a particular multisig scheme, it will allow
> > > > > sending to any scheme.
> > > > >
> > > > > If the signer has a rich enough state to store updatable
> > > > > configuration, it can just store the trusted xpubs directly.
> > > > >
> > > > > Alternatively, signer can sign not individual xpubs, but whole
> > > > > xpub packages that correspond to particular multisig
> > > > > configuration, and enforce that destination addresses
> > > > > correspond to this configuration.
> > > > >
> > > > > But this would not be possible with your PSBT scheme that uses
> > > > > individual key-xpub pairs.
> > > > >
> > > > > В Thu, 27 Jun 2019 14:07:47 +0900
> > > > > Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
> > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > The way we would do it is:
> > > > > >
> > > > > > Let's say we have 3 cold keys for multisig: A B and C
> > > > > >
> > > > > > Whose xpubs are: xA xB and xC
> > > > > >
> > > > > > We all sign each other's xpubs, whose signatures are:
> > > > > > sAxB
> > > > > > sAxC
> > > > > > sBxA
> > > > > > sBxC
> > > > > > sCxA
> > > > > > sCxB
> > > > > >
> > > > > > We can then create a wallet that says "when verifying change
> > > > > > with 0x01 global type proposed by Andrew Chow, if the change
> > > > > > is multisig, we MUST require the other pubkeys to have
> > > > > > signatures via my 0x02 proposal"
> > > > > >
> > > > > > This way, all my PSBTs for my cold will have:
> > > > > > 1. an 0x01 entry to tell me how to get my change.
> > > > > > 2. All 6 of the signatures above.
> > > > > >
> > > > > > And the signer will then look at the change, check my pubkey
> > > > > > by deriving the xpub and checking equality to the
> > > > > > BIP_DERIVATION of the output... it will then check the OTHER
> > > > > > pubkeys via BIP32_DERIVATION to master fingerprint, then link
> > > > > > that fingerprint to a 0x02 sig from MY key, verifying all
> > > > > > pubkeys.
> > > > > >
> > > > > > So this proposal of mine would not only fix the "send to
> > > > > > address verification" problem for HD, but also the multisig
> > > > > > change problem with 0x01.
> > > > > >
> > > > > > Cool.
> > > > > >
> > > > > > Only thing that is kind of sad is having to include n! (of
> > > > > > m-of-n) signatures in every PSBT... but tbh, the PSBT size is
> > > > > > not of much concern.
> > > > > >
> > > > > > Thanks for the reply.
> > > > > > - Jonathan
> > > > > >
> > > > > >
> > > > > > 2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I wonder how your scheme handles multisig ?
> > > > > > >
> > > > > > > As I understand, you sign individual xpubs with cold keys,
> > > > > > > so that cold keys can check destination addresses are
> > > > > > > trusted.
> > > > > > >
> > > > > > > I seems to me that if you sign individual xpubs of a
> > > > > > > multisig warm wallet, and one key from that multisig is
> > > > > > > compromized, attackers can then create a single-sig
> > > > > > > destination address that they control, and move the coins
> > > > > > > in a chain of two transactions, first to this single-sig
> > > > > > > address, and then to an address that they independently
> > > > > > > control.
> > > > > > >
> > > > > > > My idea to prevent this [1] is to sign the whole 'xpub
> > > > > > > package' of the multisig wallet, but there is also an issue
> > > > > > > of 'partial compromize', where some of the keys in a
> > > > > > > multisig warm wallet is compromized, and you do not want to
> > > > > > > regard a particular 'xpub package' as trusted. My idea was
> > > > > > > [2] to use an auxiliary message that would be signed along
> > > > > > > with the 'xpub package', and that message can include
> > > > > > > specific 'epoch' word that hardware wallet can show
> > > > > > > prominently before signing, or have 'serial number' for
> > > > > > > xpub packages (but that will require to store last known
> > > > > > > serial inside hw wallet, making it stateful).
> > > > > > >
> > > > > > > I like the idea to extend PSBT to accomodate these schemes,
> > > > > > > but given that the huge number of possible schemes that
> > > > > > > each may probably require its own PSBT field type, I think
> > > > > > > that this is better dealt with outside of PSBT, as 'PSBT
> > > > > > > metainformation', or using some form of 'vendor-specific',
> > > > > > > or 'metainformation-specific' PSBT field. This way each
> > > > > > > usecase can be independently described in its own
> > > > > > > documentation, that would include the particulars of the
> > > > > > > format for the metainformation. This would also make it
> > > > > > > easier to implement PSBT for simple cases, because the
> > > > > > > 'core specification' would not grow that big.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
> > >
> > > > > > >
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
> > >
> > > > > > >
> > > > > > >
> > > > > > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
> > > > > > > bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > Just wanted to pick your brains about an idea for PSBT
> > > > > > > > extension.
> > > > > > > >
> > > > > > > > One problem we try to solve with cold -> warm and warm ->
> > > > > > > > hot sends for our exchange wallet is "How do I know that
> > > > > > > > the address I am sending to is not a hacker's address
> > > > > > > > that was swapped in between unsigned tx creation and
> > > > > > > > first signature?"
> > > > > > > >
> > > > > > > > We have a proprietary JSON based encoding system which we
> > > > > > > > are looking to move towards PSBT, but PSBT is missing
> > > > > > > > this key functionality.
> > > > > > > >
> > > > > > > > BIP32_DERIVATION does allow us to verify the address is
> > > > > > > > from a certain XPUB, but, for example, it can not allow
> > > > > > > > us to verify a signature of that xpub.
> > > > > > > >
> > > > > > > > I have made a rough draft of the proposed key value
> > > > > > > > specification.
> > > > > > >
> > > > >
> > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
>
> > > > >
> > > > > > > >
> > > > > > > > The signing key path used in the spec is just randomly
> > > > > > > > chosen 31 x 4 bits shown as numbers with hardened paths.
> > > > > > > >
> > > > > > > > Since this issue seems similar to the change address
> > > > > > > > issue, I started from that as a base. With the HW wallet
> > > > > > > > case, I can verify the xpub by just deriving it locally
> > > > > > > > and comparing equality, however, in our case, we need to
> > > > > > > > verify an xpub that we do not have access to via
> > > > > > > > derivation from our cold key(s) (since we don't want to
> > > > > > > > import our warm private key into our cold signer)
> > > > > > > >
> > > > > > > > So the flow would be:
> > > > > > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > > > > > 2. Using the airgap signing tool, sign the xpub with all
> > > > > > > > cold keys. 3. Upload the signature/xpub pairs to the
> > > > > > > > online unsigned transaction generator.
> > > > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > > > > > 5. When offline signing, if the wallet detects there is a
> > > > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key,
> > > > > > > > it must verify that all outputs have BIP32_DERIVATION and
> > > > > > > > that it can verify the outputs through the derivation, to
> > > > > > > > the xpub, and to the signature.
> > > > > > > >
> > > > > > > > In my attempt to fitting this into PSBT, I am slightly
> > > > > > > > altering our current system, so don't take this as an
> > > > > > > > indication 100% of how we work in the backend.
> > > > > > > >
> > > > > > > > However, I would like to hear any feedback on this
> > > > > > > > proposal.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/6e5ce627/attachment-0001.html>

2023-06-07 18:18:46

- reply

📅 Original date posted:2019-06-27
📝 Original message:When I say order is not necessary I mean, I won't have to brute force order.
Either way, if we don't sort the xpubs in the key, it would be possible to
create multiple key value pairs for essentially the same group of pubkeys.
"I only want to sign if the multisig is in this order" is pointless.
And like I said, output PSBT includes redeemscript and witnessscript, so my
app can just say "if no redeemscript or witnessscript or BIP32_DERIVATION
for the output, fail"
- Jonathan
2019年6月27日(木) 17:56 Jonathan Underwood <junderwood at bitcoinbank.co.jp>:
> The output will have redeemscript and witnessscript so order is not
> necessary. I can just look at the multisig script and find the pubkey
> inside it.
>
> -Jonathan
>
> 2019年6月27日(木) 17:45 Dmitry Petukhov <dp at simplexum.com>:
>
>> > m value for a multisig (set 0 for non-multisig), followed by 1 or
>> > more 78 byte serialized extended public keys sorted in canonical
>> > order
>>
>> Sorting xpubs would work if the addresses also sort their pubkeys (like
>> in BIP67)
>>
>> But if the pubkey order in address creation is fixed, you better have
>> the fixed order for xpubs, otherwise you would need to try all
>> combinations of derived pubkeys when checking if the addresss match the
>> presented xpubs. That would be factorial of the number of keys, not
>> feasible beyond very small number of keys.
>>
>> Bitcoin Core, for example, currently does not support BIP67 and supports
>> only fixed pubkey positions in their script descriptors specification.
>>
>> You also need to include all xpubs to match the address, for m of n
>> standard multisig, you need to include n and check that number of keys
>> is exactly n.
>>
>> Otherwise your would not be able to construct the address to compare to
>> the destination address that you need to check, as you need all pubkesy
>> to construct P2SH or P2WSH address.
>>
>> With Shnorr-musig, you probably can interpolate the combined pubkey out
>> of m paticpant pubkeys (but don't cite me on this, I might be wrong)
>>
>> В Thu, 27 Jun 2019 17:16:14 +0900
>> Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
>>
>> > I see what you mean.
>> >
>> > What about this?
>> >
>> https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
>> >
>> > Plus side: for single sig case, the key only increases by one byte
>> > (0x00 for the {m} value)
>> >
>> > This way if it was 2 of 3 like before, you sign the whole "packet" so
>> > each key only signs the packet once. Way better than n!
>> >
>> > Anywho. Please send your feedback. Thanks.
>> > Jonathan
>> >
>> > 2019年6月27日(木) 16:27 Dmitry Petukhov <dp at simplexum.com>:
>> >
>> > > How would signer know that there _should_ be at least 3 signatures
>> > > signed by the key owned by this signer ?
>> > >
>> > > If it does not know that it should enforce 2of3 multisig, for
>> > > example, the attacker that control only one key A can fool signer B
>> > > by sending to 1of1 single-sig that is derived from A's xpub, and
>> > > providing only sBxA in PSBT.
>> > >
>> > > If the signer does not have a hardcoded configuration that
>> > > will mandate a particular multisig scheme, it will allow sending to
>> > > any scheme.
>> > >
>> > > If the signer has a rich enough state to store updatable
>> > > configuration, it can just store the trusted xpubs directly.
>> > >
>> > > Alternatively, signer can sign not individual xpubs, but whole xpub
>> > > packages that correspond to particular multisig configuration, and
>> > > enforce that destination addresses correspond to this configuration.
>> > >
>> > > But this would not be possible with your PSBT scheme that uses
>> > > individual key-xpub pairs.
>> > >
>> > > В Thu, 27 Jun 2019 14:07:47 +0900
>> > > Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
>> > >
>> > > > Thanks for the reply.
>> > > >
>> > > > The way we would do it is:
>> > > >
>> > > > Let's say we have 3 cold keys for multisig: A B and C
>> > > >
>> > > > Whose xpubs are: xA xB and xC
>> > > >
>> > > > We all sign each other's xpubs, whose signatures are:
>> > > > sAxB
>> > > > sAxC
>> > > > sBxA
>> > > > sBxC
>> > > > sCxA
>> > > > sCxB
>> > > >
>> > > > We can then create a wallet that says "when verifying change with
>> > > > 0x01 global type proposed by Andrew Chow, if the change is
>> > > > multisig, we MUST require the other pubkeys to have signatures
>> > > > via my 0x02 proposal"
>> > > >
>> > > > This way, all my PSBTs for my cold will have:
>> > > > 1. an 0x01 entry to tell me how to get my change.
>> > > > 2. All 6 of the signatures above.
>> > > >
>> > > > And the signer will then look at the change, check my pubkey by
>> > > > deriving the xpub and checking equality to the BIP_DERIVATION of
>> > > > the output... it will then check the OTHER pubkeys via
>> > > > BIP32_DERIVATION to master fingerprint, then link that
>> > > > fingerprint to a 0x02 sig from MY key, verifying all pubkeys.
>> > > >
>> > > > So this proposal of mine would not only fix the "send to address
>> > > > verification" problem for HD, but also the multisig change problem
>> > > > with 0x01.
>> > > >
>> > > > Cool.
>> > > >
>> > > > Only thing that is kind of sad is having to include n! (of m-of-n)
>> > > > signatures in every PSBT... but tbh, the PSBT size is not of much
>> > > > concern.
>> > > >
>> > > > Thanks for the reply.
>> > > > - Jonathan
>> > > >
>> > > >
>> > > > 2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:
>> > > >
>> > > > > Hi!
>> > > > >
>> > > > > I wonder how your scheme handles multisig ?
>> > > > >
>> > > > > As I understand, you sign individual xpubs with cold keys, so
>> > > > > that cold keys can check destination addresses are trusted.
>> > > > >
>> > > > > I seems to me that if you sign individual xpubs of a multisig
>> > > > > warm wallet, and one key from that multisig is compromized,
>> > > > > attackers can then create a single-sig destination address that
>> > > > > they control, and move the coins in a chain of two
>> > > > > transactions, first to this single-sig address, and then to an
>> > > > > address that they independently control.
>> > > > >
>> > > > > My idea to prevent this [1] is to sign the whole 'xpub package'
>> > > > > of the multisig wallet, but there is also an issue of 'partial
>> > > > > compromize', where some of the keys in a multisig warm wallet is
>> > > > > compromized, and you do not want to regard a particular 'xpub
>> > > > > package' as trusted. My idea was [2] to use an auxiliary message
>> > > > > that would be signed along with the 'xpub package', and that
>> > > > > message can include specific 'epoch' word that hardware wallet
>> > > > > can show prominently before signing, or have 'serial number'
>> > > > > for xpub packages (but that will require to store last known
>> > > > > serial inside hw wallet, making it stateful).
>> > > > >
>> > > > > I like the idea to extend PSBT to accomodate these schemes, but
>> > > > > given that the huge number of possible schemes that each may
>> > > > > probably require its own PSBT field type, I think that this is
>> > > > > better dealt with outside of PSBT, as 'PSBT metainformation', or
>> > > > > using some form of 'vendor-specific', or
>> > > > > 'metainformation-specific' PSBT field. This way each usecase
>> > > > > can be independently described in its own documentation, that
>> > > > > would include the particulars of the format for the
>> > > > > metainformation. This would also make it easier to implement
>> > > > > PSBT for simple cases, because the 'core specification' would
>> > > > > not grow that big.
>> > > > >
>> > > > > [1]
>> > > > >
>> > > > >
>> > >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
>>
>> > > > >
>> > > > > [2]
>> > > > >
>> > > > >
>> > >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
>>
>> > > > >
>> > > > >
>> > > > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via
>> > > > > bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > > > >
>> > > > > > Hello all,
>> > > > > >
>> > > > > > Just wanted to pick your brains about an idea for PSBT
>> > > > > > extension.
>> > > > > >
>> > > > > > One problem we try to solve with cold -> warm and warm -> hot
>> > > > > > sends for our exchange wallet is "How do I know that the
>> > > > > > address I am sending to is not a hacker's address that was
>> > > > > > swapped in between unsigned tx creation and first signature?"
>> > > > > >
>> > > > > > We have a proprietary JSON based encoding system which we are
>> > > > > > looking to move towards PSBT, but PSBT is missing this key
>> > > > > > functionality.
>> > > > > >
>> > > > > > BIP32_DERIVATION does allow us to verify the address is from a
>> > > > > > certain XPUB, but, for example, it can not allow us to verify
>> > > > > > a signature of that xpub.
>> > > > > >
>> > > > > > I have made a rough draft of the proposed key value
>> > > > > > specification.
>> > > > >
>> > >
>> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
>> > >
>> > > > > >
>> > > > > > The signing key path used in the spec is just randomly chosen
>> > > > > > 31 x 4 bits shown as numbers with hardened paths.
>> > > > > >
>> > > > > > Since this issue seems similar to the change address issue, I
>> > > > > > started from that as a base. With the HW wallet case, I can
>> > > > > > verify the xpub by just deriving it locally and comparing
>> > > > > > equality, however, in our case, we need to verify an xpub
>> > > > > > that we do not have access to via derivation from our cold
>> > > > > > key(s) (since we don't want to import our warm private key
>> > > > > > into our cold signer)
>> > > > > >
>> > > > > > So the flow would be:
>> > > > > > 1. Securely verify the xpub of the warm / hot wallet.
>> > > > > > 2. Using the airgap signing tool, sign the xpub with all cold
>> > > > > > keys. 3. Upload the signature/xpub pairs to the online
>> > > > > > unsigned transaction generator.
>> > > > > > 4. Include one keyval pair per coldkey/xpub pairing.
>> > > > > > 5. When offline signing, if the wallet detects there is a
>> > > > > > global keyval XPUB_SIGNATURE with its pubkey in the key, it
>> > > > > > must verify that all outputs have BIP32_DERIVATION and that
>> > > > > > it can verify the outputs through the derivation, to the
>> > > > > > xpub, and to the signature.
>> > > > > >
>> > > > > > In my attempt to fitting this into PSBT, I am slightly
>> > > > > > altering our current system, so don't take this as an
>> > > > > > indication 100% of how we work in the backend.
>> > > > > >
>> > > > > > However, I would like to hear any feedback on this proposal.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Jonathan
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> >
>>
>>
>
> --
> -----------------
> Jonathan Underwood
> ビットバンク社チーフビットコインオフィサー
> -----------------
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/c0a55da6/attachment-0001.html>

2023-06-07 18:18:45

- reply

📅 Original date posted:2019-06-26
📝 Original message:Hello all,
Just wanted to pick your brains about an idea for PSBT extension.
One problem we try to solve with cold -> warm and warm -> hot sends for our
exchange wallet is "How do I know that the address I am sending to is not a
hacker's address that was swapped in between unsigned tx creation and first
signature?"
We have a proprietary JSON based encoding system which we are looking to
move towards PSBT, but PSBT is missing this key functionality.
BIP32_DERIVATION does allow us to verify the address is from a certain
XPUB, but, for example, it can not allow us to verify a signature of that
xpub.
I have made a rough draft of the proposed key value specification.
https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
The signing key path used in the spec is just randomly chosen 31 x 4 bits
shown as numbers with hardened paths.
Since this issue seems similar to the change address issue, I started from
that as a base. With the HW wallet case, I can verify the xpub by just
deriving it locally and comparing equality, however, in our case, we need
to verify an xpub that we do not have access to via derivation from our
cold key(s) (since we don't want to import our warm private key into our
cold signer)
So the flow would be:
1. Securely verify the xpub of the warm / hot wallet.
2. Using the airgap signing tool, sign the xpub with all cold keys.
3. Upload the signature/xpub pairs to the online unsigned transaction
generator.
4. Include one keyval pair per coldkey/xpub pairing.
5. When offline signing, if the wallet detects there is a global keyval
XPUB_SIGNATURE with its pubkey in the key, it must verify that all outputs
have BIP32_DERIVATION and that it can verify the outputs through the
derivation, to the xpub, and to the signature.
In my attempt to fitting this into PSBT, I am slightly altering our current
system, so don't take this as an indication 100% of how we work in the
backend.
However, I would like to hear any feedback on this proposal.
Thanks,
Jonathan
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/82c9ecc0/attachment.html>

2023-06-07 18:18:45

- reply

📅 Original date posted:2019-06-27
📝 Original message:Thanks for the reply.
The way we would do it is:
Let's say we have 3 cold keys for multisig: A B and C
Whose xpubs are: xA xB and xC
We all sign each other's xpubs, whose signatures are:
sAxB
sAxC
sBxA
sBxC
sCxA
sCxB
We can then create a wallet that says "when verifying change with 0x01
global type proposed by Andrew Chow, if the change is multisig, we MUST
require the other pubkeys to have signatures via my 0x02 proposal"
This way, all my PSBTs for my cold will have:
1. an 0x01 entry to tell me how to get my change.
2. All 6 of the signatures above.
And the signer will then look at the change, check my pubkey by deriving
the xpub and checking equality to the BIP_DERIVATION of the output... it
will then check the OTHER pubkeys via BIP32_DERIVATION to master
fingerprint, then link that fingerprint to a 0x02 sig from MY key,
verifying all pubkeys.
So this proposal of mine would not only fix the "send to address
verification" problem for HD, but also the multisig change problem with
0x01.
Cool.
Only thing that is kind of sad is having to include n! (of m-of-n)
signatures in every PSBT... but tbh, the PSBT size is not of much concern.
Thanks for the reply.
- Jonathan
2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:
> Hi!
>
> I wonder how your scheme handles multisig ?
>
> As I understand, you sign individual xpubs with cold keys, so that cold
> keys can check destination addresses are trusted.
>
> I seems to me that if you sign individual xpubs of a multisig warm
> wallet, and one key from that multisig is compromized, attackers can
> then create a single-sig destination address that they control, and
> move the coins in a chain of two transactions, first to this single-sig
> address, and then to an address that they independently control.
>
> My idea to prevent this [1] is to sign the whole 'xpub package' of the
> multisig wallet, but there is also an issue of 'partial compromize',
> where some of the keys in a multisig warm wallet is compromized, and
> you do not want to regard a particular 'xpub package' as trusted. My
> idea was [2] to use an auxiliary message that would be signed along with
> the 'xpub package', and that message can include specific 'epoch' word
> that hardware wallet can show prominently before signing, or have
> 'serial number' for xpub packages (but that will require to store last
> known serial inside hw wallet, making it stateful).
>
> I like the idea to extend PSBT to accomodate these schemes, but given
> that the huge number of possible schemes that each may probably
> require its own PSBT field type, I think that this is better dealt with
> outside of PSBT, as 'PSBT metainformation', or using some form of
> 'vendor-specific', or 'metainformation-specific' PSBT field. This way
> each usecase can be independently described in its own documentation,
> that would include the particulars of the format for the
> metainformation. This would also make it easier to implement PSBT for
> simple cases, because the 'core specification' would not grow that big.
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
>
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
>
>
> В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hello all,
> >
> > Just wanted to pick your brains about an idea for PSBT extension.
> >
> > One problem we try to solve with cold -> warm and warm -> hot sends
> > for our exchange wallet is "How do I know that the address I am
> > sending to is not a hacker's address that was swapped in between
> > unsigned tx creation and first signature?"
> >
> > We have a proprietary JSON based encoding system which we are looking
> > to move towards PSBT, but PSBT is missing this key functionality.
> >
> > BIP32_DERIVATION does allow us to verify the address is from a certain
> > XPUB, but, for example, it can not allow us to verify a signature of
> > that xpub.
> >
> > I have made a rough draft of the proposed key value specification.
> >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
> >
> > The signing key path used in the spec is just randomly chosen 31 x 4
> > bits shown as numbers with hardened paths.
> >
> > Since this issue seems similar to the change address issue, I started
> > from that as a base. With the HW wallet case, I can verify the xpub
> > by just deriving it locally and comparing equality, however, in our
> > case, we need to verify an xpub that we do not have access to via
> > derivation from our cold key(s) (since we don't want to import our
> > warm private key into our cold signer)
> >
> > So the flow would be:
> > 1. Securely verify the xpub of the warm / hot wallet.
> > 2. Using the airgap signing tool, sign the xpub with all cold keys.
> > 3. Upload the signature/xpub pairs to the online unsigned transaction
> > generator.
> > 4. Include one keyval pair per coldkey/xpub pairing.
> > 5. When offline signing, if the wallet detects there is a global
> > keyval XPUB_SIGNATURE with its pubkey in the key, it must verify that
> > all outputs have BIP32_DERIVATION and that it can verify the outputs
> > through the derivation, to the xpub, and to the signature.
> >
> > In my attempt to fitting this into PSBT, I am slightly altering our
> > current system, so don't take this as an indication 100% of how we
> > work in the backend.
> >
> > However, I would like to hear any feedback on this proposal.
> >
> > Thanks,
> > Jonathan
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/14367388/attachment-0001.html>

2023-06-07 18:18:45

- reply

📅 Original date posted:2019-06-27
📝 Original message:I see what you mean.
What about this?
https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
Plus side: for single sig case, the key only increases by one byte (0x00
for the {m} value)
This way if it was 2 of 3 like before, you sign the whole "packet" so each
key only signs the packet once. Way better than n!
Anywho. Please send your feedback. Thanks.
Jonathan
2019年6月27日(木) 16:27 Dmitry Petukhov <dp at simplexum.com>:
> How would signer know that there _should_ be at least 3 signatures
> signed by the key owned by this signer ?
>
> If it does not know that it should enforce 2of3 multisig, for example,
> the attacker that control only one key A can fool signer B by
> sending to 1of1 single-sig that is derived from A's xpub, and providing
> only sBxA in PSBT.
>
> If the signer does not have a hardcoded configuration that
> will mandate a particular multisig scheme, it will allow sending to any
> scheme.
>
> If the signer has a rich enough state to store updatable configuration,
> it can just store the trusted xpubs directly.
>
> Alternatively, signer can sign not individual xpubs, but whole xpub
> packages that correspond to particular multisig configuration, and
> enforce that destination addresses correspond to this configuration.
>
> But this would not be possible with your PSBT scheme that uses
> individual key-xpub pairs.
>
> В Thu, 27 Jun 2019 14:07:47 +0900
> Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
>
> > Thanks for the reply.
> >
> > The way we would do it is:
> >
> > Let's say we have 3 cold keys for multisig: A B and C
> >
> > Whose xpubs are: xA xB and xC
> >
> > We all sign each other's xpubs, whose signatures are:
> > sAxB
> > sAxC
> > sBxA
> > sBxC
> > sCxA
> > sCxB
> >
> > We can then create a wallet that says "when verifying change with 0x01
> > global type proposed by Andrew Chow, if the change is multisig, we
> > MUST require the other pubkeys to have signatures via my 0x02
> > proposal"
> >
> > This way, all my PSBTs for my cold will have:
> > 1. an 0x01 entry to tell me how to get my change.
> > 2. All 6 of the signatures above.
> >
> > And the signer will then look at the change, check my pubkey by
> > deriving the xpub and checking equality to the BIP_DERIVATION of the
> > output... it will then check the OTHER pubkeys via BIP32_DERIVATION
> > to master fingerprint, then link that fingerprint to a 0x02 sig from
> > MY key, verifying all pubkeys.
> >
> > So this proposal of mine would not only fix the "send to address
> > verification" problem for HD, but also the multisig change problem
> > with 0x01.
> >
> > Cool.
> >
> > Only thing that is kind of sad is having to include n! (of m-of-n)
> > signatures in every PSBT... but tbh, the PSBT size is not of much
> > concern.
> >
> > Thanks for the reply.
> > - Jonathan
> >
> >
> > 2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:
> >
> > > Hi!
> > >
> > > I wonder how your scheme handles multisig ?
> > >
> > > As I understand, you sign individual xpubs with cold keys, so that
> > > cold keys can check destination addresses are trusted.
> > >
> > > I seems to me that if you sign individual xpubs of a multisig warm
> > > wallet, and one key from that multisig is compromized, attackers can
> > > then create a single-sig destination address that they control, and
> > > move the coins in a chain of two transactions, first to this
> > > single-sig address, and then to an address that they independently
> > > control.
> > >
> > > My idea to prevent this [1] is to sign the whole 'xpub package' of
> > > the multisig wallet, but there is also an issue of 'partial
> > > compromize', where some of the keys in a multisig warm wallet is
> > > compromized, and you do not want to regard a particular 'xpub
> > > package' as trusted. My idea was [2] to use an auxiliary message
> > > that would be signed along with the 'xpub package', and that
> > > message can include specific 'epoch' word that hardware wallet can
> > > show prominently before signing, or have 'serial number' for xpub
> > > packages (but that will require to store last known serial inside
> > > hw wallet, making it stateful).
> > >
> > > I like the idea to extend PSBT to accomodate these schemes, but
> > > given that the huge number of possible schemes that each may
> > > probably require its own PSBT field type, I think that this is
> > > better dealt with outside of PSBT, as 'PSBT metainformation', or
> > > using some form of 'vendor-specific', or 'metainformation-specific'
> > > PSBT field. This way each usecase can be independently described in
> > > its own documentation, that would include the particulars of the
> > > format for the metainformation. This would also make it easier to
> > > implement PSBT for simple cases, because the 'core specification'
> > > would not grow that big.
> > >
> > > [1]
> > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
> > >
> > > [2]
> > >
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
> > >
> > >
> > > В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bitcoin-dev
> > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > > Hello all,
> > > >
> > > > Just wanted to pick your brains about an idea for PSBT extension.
> > > >
> > > > One problem we try to solve with cold -> warm and warm -> hot
> > > > sends for our exchange wallet is "How do I know that the address
> > > > I am sending to is not a hacker's address that was swapped in
> > > > between unsigned tx creation and first signature?"
> > > >
> > > > We have a proprietary JSON based encoding system which we are
> > > > looking to move towards PSBT, but PSBT is missing this key
> > > > functionality.
> > > >
> > > > BIP32_DERIVATION does allow us to verify the address is from a
> > > > certain XPUB, but, for example, it can not allow us to verify a
> > > > signature of that xpub.
> > > >
> > > > I have made a rough draft of the proposed key value specification.
> > > >
> > >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
>
> > > >
> > > > The signing key path used in the spec is just randomly chosen 31
> > > > x 4 bits shown as numbers with hardened paths.
> > > >
> > > > Since this issue seems similar to the change address issue, I
> > > > started from that as a base. With the HW wallet case, I can
> > > > verify the xpub by just deriving it locally and comparing
> > > > equality, however, in our case, we need to verify an xpub that we
> > > > do not have access to via derivation from our cold key(s) (since
> > > > we don't want to import our warm private key into our cold signer)
> > > >
> > > > So the flow would be:
> > > > 1. Securely verify the xpub of the warm / hot wallet.
> > > > 2. Using the airgap signing tool, sign the xpub with all cold
> > > > keys. 3. Upload the signature/xpub pairs to the online unsigned
> > > > transaction generator.
> > > > 4. Include one keyval pair per coldkey/xpub pairing.
> > > > 5. When offline signing, if the wallet detects there is a global
> > > > keyval XPUB_SIGNATURE with its pubkey in the key, it must verify
> > > > that all outputs have BIP32_DERIVATION and that it can verify the
> > > > outputs through the derivation, to the xpub, and to the signature.
> > > >
> > > > In my attempt to fitting this into PSBT, I am slightly altering
> > > > our current system, so don't take this as an indication 100% of
> > > > how we work in the backend.
> > > >
> > > > However, I would like to hear any feedback on this proposal.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > >
> > >
> >
>
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/30b46b5a/attachment-0001.html>

2023-06-07 18:15:13

- reply

📅 Original date posted:2018-11-16
📝 Original message:Nope.
This is how Electrum treats BIP39 restoring as well, try it out.
-Jon
2018年11月16日(金) 23:04、Neill Miller さん（neillm at thecodefactory.org）のメッセージ:
> On Fri, Nov 09, 2018 at 02:17:30PM +0900, Jonathan Underwood via
> bitcoin-dev wrote:
> > If more apps would implement to the word of the BIP39 spec, multiple
> > languages make sense, but since reality is no one follows the spec (/the
> > spec is way too open to interpretation) then expecting every app to load
> > every language is unreasonable.
> >
> > Electrum actually handles BIP39 recovery the way the BIP specifies. I can
> > restore random strings if I want, and it warns me, and I can ignore it
> if I
> > wish.
>
> Electrum mnemonics are not based on BIP39, which is why it can do
> this.
>
> -Neill.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181116/545faa2c/attachment.html>

2023-06-07 18:15:12

- reply

📅 Original date posted:2018-11-09
📝 Original message:> as it seems bad design to have to fix and maintain a wordlist for every
language as the checksum depends on it.
>From BIP39:
> The conversion of the mnemonic sentence to a binary seed is completely
independent from generating the sentence. This results in rather simple
code; there are no constraints on sentence structure and clients are free
to implement their own wordlists or even whole sentence generators,
allowing for flexibility in wordlists for typo detection or other purposes.
>
> Although using a mnemonic not generated by the algorithm described in
"Generating the mnemonic" section is possible, this is not advised and
software must compute a checksum for the mnemonic sentence using a wordlist
and issue a warning if it is invalid.
So BIP39 states "no constraints on sentence structure and clients are free
to implement their own wordlists or even whole sentence generators" and yet
at the same time one paragraph later "this is not advised and software must
compute a checksum for the mnemonic sentence using a wordlist and issue a
warning if it is invalid"...
My interpretation of this:
1. ChecksumCheck function attempts to 1. find the wordlist 2. calculate the
checksum.
2. If it fails to find the wordlist, return false
3. If the checksum doesn't match return false
4. If ChecksumCheck returns false, "issue a warning" but do not block seed
generation. "We couldn't check if your phrase is correct... you're on your
own"
99.99% of implementing apps interpretation: (remember, error handling for
userspace is not done by the BIP39 library, but the app that uses it)
1. Run ChecksumCheck
2. If False, hard fail, do not allow seed generation.
If more apps would implement to the word of the BIP39 spec, multiple
languages make sense, but since reality is no one follows the spec (/the
spec is way too open to interpretation) then expecting every app to load
every language is unreasonable.
Electrum actually handles BIP39 recovery the way the BIP specifies. I can
restore random strings if I want, and it warns me, and I can ignore it if I
wish.
Anywho. The BIP39 multi-language feature is crucial for non-English
speakers especially from Asia. Maybe northern Europeans have no problem
with English word spelling, but watching a normal Japanese person write
down their English mnemonic is painful.
One letter at a time, worried they wrote it wrong... still make mistakes...
lose money because of it.
Whereas users of Copay etc. that support Japanese wordlist write down their
seed easily, and I have never heard of a Japanese newbie complaining about
"but I'm writing it just how I have it written down" about their Japanese
seed... only English.
Not trying to give anyone a hard time, just telling the facts: lack of
localized words for recovery phrase causes more money loss than supporting
it. (When push comes to shove, at the very least Electrum will always
support their recovery because it lets you hash anything)
This is all anecdotal of course. Just sharing my experience evangelizing in
Japan.
Thanks,
Jon
2018年11月8日(木) 21:16 SomberNight via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Do you specifically want to support changing the language of seed
> words, while keeping the bip32 root seed they generate unchanged?
> What is the usecase for this?
>
> You mention that BIP39 already supports a few different languages.
> While this is true, many (I would guess most!) wallets only
> support the English wordlist.
> There are doubts even from the authors of the BIP whether it was
> a good idea in the first place to support multiple languages [0].
> I don't find this surprising as it seems bad design to have to fix and
> maintain a wordlist for every language as the checksum depends on it.
> The supported wordlists are effectively a part of the specification,
> and every new list would just make that specification larger.
>
> If changing the language of seeds is not a requirement, then look
> into Electrum seeds. They are language/wordlist agnostic.
>
> Mnemonic Sentence => PBKDF2 => BIP-0032 Seed
>
> The bip32 seed is derived by hashing the normalized mnemonic, and the
> checksum is derived the same way but by using a different cheaper
> hash (single round of HMAC-SHA512; generation grinds until it matches
> a pattern) [1]. For example, "9dk" is a valid segwit electrum seed.
>
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015507.html
> [1]: http://docs.electrum.org/en/latest/seedphrase.html
>
>
> > Date: Wed, 7 Nov 2018 00:16:41 +0800
> > From: Weiji Guo weiji.g at gmail.com
> > Subject: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language
> > support
> >
> > Hello everyone,
> >
> > I just realized that BIP-0039 is language dependent. I was assuming the
> > other way till I looked closer. The way the seed is derived from a
> BIP-0039
> > entropy, as is shown below, depends on which language to generate the
> > mnemonic sentence:
> >
> > Entropy <=> Mnemonic Sentence => PBKDF2 => BIP-0032 Seed
> >
> > Therefore when a user choose a non-English mnemonic code he or she is
> stuck
> > with that language. Meanwhile only a few native languages are supported.
> >
> > SLIP-0039 does not solve this issue in a user friendly way by providing
> > only an English wordlist. That's understandable as it aims to provide SSS
> > capability. However those users who do not speak English or recognize
> > English words will suffer.
> >
> > What I am trying to bring to attention of the community is that, no
> matter
> > if we make a new version of BIP-0039, or a new BIP (with SSS support), or
> > to enhance SLIP-0039, we really need to address this language issue.
> >
> > Here are what I propose:
> >
> > 1. The mnemonic code should be only a representation of underlying
> entropy
> > or (pre) master secret, seed, whatever. In this way, the same
> seed/secret
> > could be displayed in English or in Chinese or other languages. Then
> there
> > could be 3rd party conversion tools to support translations in case
> any
> > wallet software or device does not support all specified languages.
> Now it
> > looks like:
> >
> > Mnemonic Sentence <=> Entropy => PBKDF2 => BIP-0032 Seed
> >
> >
> > 2. Given that only 8 languages are supported in BIP-0039, we should allow
> > the seed/secret to be represented in decimal numbers, each ranging from 0
> > to 2047. So those who cannot find a native language support yet having
> > difficulty coping words in other languages could choose to just use
> numbers.
> >
> > So far I don't have a preference how this should be implemented. I'd like
> > to hear from community first.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181109/f93c2a37/attachment-0001.html>