* [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets
@ 2017-09-06 22:29 Pavol Rusnak
2017-09-07 3:52 ` Kabuto Samourai
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Pavol Rusnak @ 2017-09-06 22:29 UTC (permalink / raw)
To: Pavol Rusnak via bitcoin-dev
The discussion about changing bip32 version bytes for SegWit got me
thinking and I ended up with what I think is the best proposal:
https://github.com/satoshilabs/slips/blob/master/slip-0032.md
(It is hosted in SL repo for now, but if there is will, I would love to
have this added to BIP repo as an extension to BIP32)
Feel free to comment.
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-06 22:29 [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets Pavol Rusnak @ 2017-09-07 3:52 ` Kabuto Samourai 2017-09-07 16:25 ` Pavol Rusnak 2017-09-07 4:29 ` Thomas Voegtlin 2017-09-07 16:47 ` Jonas Schnelli 2 siblings, 1 reply; 15+ messages in thread From: Kabuto Samourai @ 2017-09-07 3:52 UTC (permalink / raw) To: Pavol Rusnak, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1481 bytes --] Thanks for the proposal. Aside from potential privacy implications of revealing the derivation path for non BIP-44, 45, 49 HD nodes, this scheme is superior to the alternate {x,y,z}pub idea. Since coin_type is part of the path, the 'xpub' prefix may be shared across all coins if they so choose. This format provides lock-in for BIP-49 going forward and opens the door for a parallel native-SegWit BIP. The birthday field is interesting. Could you provide some motivation for its inclusion? Could you also add some test vectors? There are a few minor grammar / spelling errors, but we can nitpick those after this goes to the pull request stage on bitcoin/bips. On Wed, Sep 6, 2017 at 5:29 PM, Pavol Rusnak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > The discussion about changing bip32 version bytes for SegWit got me > thinking and I ended up with what I think is the best proposal: > > https://github.com/satoshilabs/slips/blob/master/slip-0032.md > > (It is hosted in SL repo for now, but if there is will, I would love to > have this added to BIP repo as an extension to BIP32) > > Feel free to comment. > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > CTO, SatoshiLabs > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -Kabuto PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99 [-- Attachment #2: Type: text/html, Size: 2530 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 3:52 ` Kabuto Samourai @ 2017-09-07 16:25 ` Pavol Rusnak 2017-09-07 16:30 ` Kabuto Samourai 0 siblings, 1 reply; 15+ messages in thread From: Pavol Rusnak @ 2017-09-07 16:25 UTC (permalink / raw) To: Kabuto Samourai, Bitcoin Protocol Discussion On 07/09/17 05:52, Kabuto Samourai wrote: > The birthday field is interesting. Could you provide some motivation for > its inclusion? Birthday is something SPV wallet developers have been wanting for years. It helps them with the initial scan, so SPV wallet does not have to download every block in the blockchain, but only the ones after birthday. > Could you also add some test vectors? I will add some test vectors, when we agree this is the way to go. > There are a few minor grammar / spelling errors, but we can nitpick > those after this goes to the pull request stage on bitcoin/bips. +1 -- Best Regards / S pozdravom, Pavol "stick" Rusnak CTO, SatoshiLabs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:25 ` Pavol Rusnak @ 2017-09-07 16:30 ` Kabuto Samourai 2017-09-07 16:37 ` Pavol Rusnak 0 siblings, 1 reply; 15+ messages in thread From: Kabuto Samourai @ 2017-09-07 16:30 UTC (permalink / raw) To: Pavol Rusnak; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 943 bytes --] > Birthday Why not make this block height, rather than a timestamp? On Thu, Sep 7, 2017 at 11:25 AM, Pavol Rusnak <stick@satoshilabs•com> wrote: > On 07/09/17 05:52, Kabuto Samourai wrote: > > The birthday field is interesting. Could you provide some motivation for > > its inclusion? > > Birthday is something SPV wallet developers have been wanting for years. > It helps them with the initial scan, so SPV wallet does not have to > download every block in the blockchain, but only the ones after birthday. > > > Could you also add some test vectors? > > I will add some test vectors, when we agree this is the way to go. > > > There are a few minor grammar / spelling errors, but we can nitpick > > those after this goes to the pull request stage on bitcoin/bips. > > +1 > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > CTO, SatoshiLabs > -- -Kabuto PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99 [-- Attachment #2: Type: text/html, Size: 1687 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:30 ` Kabuto Samourai @ 2017-09-07 16:37 ` Pavol Rusnak 2017-09-07 18:02 ` Peter Todd 0 siblings, 1 reply; 15+ messages in thread From: Pavol Rusnak @ 2017-09-07 16:37 UTC (permalink / raw) To: Kabuto Samourai; +Cc: Bitcoin Protocol Discussion On 07/09/17 18:30, Kabuto Samourai wrote: > Why not make this block height, rather than a timestamp? Blockheight depends on the chain. XPUB is not tied to particular chain/coin. Also there are already cryptocurrencies that do not use blockchain, but directed acyclic graph (DAG) for storing transactions. So it would not be obvious what number to use as a blockheight. OTOH all blockchains contain timestamps in their blocks, so we can use that. -- Best Regards / S pozdravom, Pavol "stick" Rusnak CTO, SatoshiLabs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:37 ` Pavol Rusnak @ 2017-09-07 18:02 ` Peter Todd 0 siblings, 0 replies; 15+ messages in thread From: Peter Todd @ 2017-09-07 18:02 UTC (permalink / raw) To: Pavol Rusnak, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 955 bytes --] On Thu, Sep 07, 2017 at 06:37:19PM +0200, Pavol Rusnak via bitcoin-dev wrote: > On 07/09/17 18:30, Kabuto Samourai wrote: > > Why not make this block height, rather than a timestamp? > > Blockheight depends on the chain. XPUB is not tied to particular > chain/coin. > > Also there are already cryptocurrencies that do not use blockchain, but > directed acyclic graph (DAG) for storing transactions. So it would not > be obvious what number to use as a blockheight. > > OTOH all blockchains contain timestamps in their blocks, so we can use that. More to the point, even for the blockchains that don't contain timestamps in their blocks, their blocks do exist in our spacetime continum and thus are created at a specific point in time. :) If someone does however come up with an example of a blockchain that does not occupy our spacetime continum, I'd love to hear about it! -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-06 22:29 [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets Pavol Rusnak 2017-09-07 3:52 ` Kabuto Samourai @ 2017-09-07 4:29 ` Thomas Voegtlin 2017-09-07 16:23 ` Pavol Rusnak 2017-09-07 16:47 ` Jonas Schnelli 2 siblings, 1 reply; 15+ messages in thread From: Thomas Voegtlin @ 2017-09-07 4:29 UTC (permalink / raw) To: bitcoin-dev On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev wrote: > The discussion about changing bip32 version bytes for SegWit got me > thinking and I ended up with what I think is the best proposal: > > https://github.com/satoshilabs/slips/blob/master/slip-0032.md > > (It is hosted in SL repo for now, but if there is will, I would love to > have this added to BIP repo as an extension to BIP32) > > Feel free to comment. > Your proposal forces wallets to use the derivation path in order to determine the type of output script. it will work only in the context of BIP43. Therefore, it should not be proposed as a BIP32 improvement, but as a improvement of BIP43. A solution is still needed to wallets who do not wish to use BIP43 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 4:29 ` Thomas Voegtlin @ 2017-09-07 16:23 ` Pavol Rusnak 2017-09-07 16:33 ` Kabuto Samourai ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Pavol Rusnak @ 2017-09-07 16:23 UTC (permalink / raw) To: Thomas Voegtlin, Bitcoin Protocol Discussion On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote: > A solution is still needed to wallets who do not wish to use BIP43 What if we added another byte field OutputType for wallets that do not follow BIP43? 0x00 - P2PKH output type 0x01 - P2WPKH-in-P2SH output type 0x02 - native Segwit output type Would that work for you? The question is whether this field should be present only if depth==0x00 or at all times. What is your suggestion, Thomas? -- Best Regards / S pozdravom, Pavol "stick" Rusnak CTO, SatoshiLabs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:23 ` Pavol Rusnak @ 2017-09-07 16:33 ` Kabuto Samourai 2017-09-07 19:35 ` Andreas Schildbach 2017-09-07 20:39 ` Thomas Voegtlin 2 siblings, 0 replies; 15+ messages in thread From: Kabuto Samourai @ 2017-09-07 16:33 UTC (permalink / raw) To: Pavol Rusnak, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1262 bytes --] OutputType byte solution is nearly equivalent to {x,y,z} and adds redundant data. Implementations could erroneously (maliciously) assign the wrong output type for the given purpose field. We could reduce the scope of this improvement to BIP43, as suggested by Thomas. BIP32-generic wallets may implement something else. On Thu, Sep 7, 2017 at 11:23 AM, Pavol Rusnak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote: > > A solution is still needed to wallets who do not wish to use BIP43 > > What if we added another byte field OutputType for wallets that do not > follow BIP43? > > 0x00 - P2PKH output type > 0x01 - P2WPKH-in-P2SH output type > 0x02 - native Segwit output type > > Would that work for you? > > The question is whether this field should be present only if depth==0x00 > or at all times. What is your suggestion, Thomas? > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > CTO, SatoshiLabs > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- -Kabuto PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99 [-- Attachment #2: Type: text/html, Size: 2187 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:23 ` Pavol Rusnak 2017-09-07 16:33 ` Kabuto Samourai @ 2017-09-07 19:35 ` Andreas Schildbach 2017-09-07 20:00 ` Pavol Rusnak 2017-09-07 20:39 ` Thomas Voegtlin 2 siblings, 1 reply; 15+ messages in thread From: Andreas Schildbach @ 2017-09-07 19:35 UTC (permalink / raw) To: bitcoin-dev On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote: > On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote: >> A solution is still needed to wallets who do not wish to use BIP43 > > What if we added another byte field OutputType for wallets that do not > follow BIP43? > > 0x00 - P2PKH output type > 0x01 - P2WPKH-in-P2SH output type > 0x02 - native Segwit output type > > Would that work for you? I think that would work. > The question is whether this field should be present only if depth==0x00 > or at all times. What is your suggestion, Thomas? In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still we need this field. I think it should always be present if a chain is limited to a certain script type. There is however the case where even on one chain, script types are mixed. In this case the field should be omitted and the wallet needs to scan for all (known) types. Afaik Bitcoin Core is taking this path. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 19:35 ` Andreas Schildbach @ 2017-09-07 20:00 ` Pavol Rusnak 0 siblings, 0 replies; 15+ messages in thread From: Pavol Rusnak @ 2017-09-07 20:00 UTC (permalink / raw) To: Andreas Schildbach, Bitcoin Protocol Discussion On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote: > In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still > we need this field. But the depth of exported public key will be null. It does not make sense to export xpub for m or m/0' for your particular case. > I think it should always be present if a chain is > limited to a certain script type. I am fine with having the path there all the time. > There is however the case where even on one chain, script types are > mixed. In this case the field should be omitted and the wallet needs to > scan for all (known) types. Afaik Bitcoin Core is taking this path. Is that really the case? Why come up with a hierarchy and then don't use it? -- Best Regards / S pozdravom, Pavol "stick" Rusnak CTO, SatoshiLabs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:23 ` Pavol Rusnak 2017-09-07 16:33 ` Kabuto Samourai 2017-09-07 19:35 ` Andreas Schildbach @ 2017-09-07 20:39 ` Thomas Voegtlin 2 siblings, 0 replies; 15+ messages in thread From: Thomas Voegtlin @ 2017-09-07 20:39 UTC (permalink / raw) To: bitcoin-dev On 07.09.2017 18:23, Pavol Rusnak wrote: > On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote: >> A solution is still needed to wallets who do not wish to use BIP43 > > What if we added another byte field OutputType for wallets that do not > follow BIP43? > > 0x00 - P2PKH output type > 0x01 - P2WPKH-in-P2SH output type > 0x02 - native Segwit output type > > Would that work for you? > > The question is whether this field should be present only if depth==0x00 > or at all times. What is your suggestion, Thomas? > well, in my initial proposal, I wrote that this value should be user visible. That is why I used version bytes. If you create an extra byte field, and then use base58 or bech32 encoding, the value will not be user visible anymore. The initial implementation of segwit xpub/xprv in Electrum used a flag that was not user visible (I added 1 to the bip32 version bytes, which leaves the xpub/xprv prefix unchanged). I have experimented with that invisible flag for more than 6 months now, and I am now convinced that it is better to make that flag user visible. The reason is that when users create wallets with multisig scripts, they need to combine several master public keys. However, these master public keys should all be of the same type: it would not make sense to create a 2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By imposing that all master keys are of the same type, we ensure that all cosigners agree on the script type that will be used to derive addresses. In other words, if users are exposed to master keys and need to manipulate them, it is better to let them see what they are doing. OTOH if you do not plan to expose your users to these keys, you probably do not need a serialization format. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-06 22:29 [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets Pavol Rusnak 2017-09-07 3:52 ` Kabuto Samourai 2017-09-07 4:29 ` Thomas Voegtlin @ 2017-09-07 16:47 ` Jonas Schnelli 2017-09-07 18:09 ` Peter Todd 2017-09-07 18:38 ` Pavol Rusnak 2 siblings, 2 replies; 15+ messages in thread From: Jonas Schnelli @ 2017-09-07 16:47 UTC (permalink / raw) To: Pavol Rusnak, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1753 bytes --] Thanks for the proposal. Three points it could see as possible improvements: 1. From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years. Always round down to the beginning of the week when the key was created. But not sure if it’s worth to save ~two bytes for that. Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better). 2. Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths. 3. Would adding a version bit make sense to allow future extensions? /jonas > Am 06.09.2017 um 15:29 schrieb Pavol Rusnak via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>: > > The discussion about changing bip32 version bytes for SegWit got me > thinking and I ended up with what I think is the best proposal: > > https://github.com/satoshilabs/slips/blob/master/slip-0032.md > > (It is hosted in SL repo for now, but if there is will, I would love to > have this added to BIP repo as an extension to BIP32) > > Feel free to comment. > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > CTO, SatoshiLabs > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:47 ` Jonas Schnelli @ 2017-09-07 18:09 ` Peter Todd 2017-09-07 18:38 ` Pavol Rusnak 1 sibling, 0 replies; 15+ messages in thread From: Peter Todd @ 2017-09-07 18:09 UTC (permalink / raw) To: Jonas Schnelli, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1428 bytes --] On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote: > Thanks for the proposal. > > Three points it could see as possible improvements: > > 1. > From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years. > Always round down to the beginning of the week when the key was created. > But not sure if it’s worth to save ~two bytes for that. > Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better). Note how private key birthday is a potential privacy issue in certain cases. Rare of course, because usually you don't release your private keys! But users will on occasion have those keys be compromised. Personally, I'd advocate rounding down to month-level resolution, as that should be both enough to handle any likely reorg scenario, and it's still a precision that won't add much extra scanning ot any reasonably old (~1yr) wallet. Note also how if transactions created with private keys in a seed use nLockTime, you can ensure coins won't exist in a block older than the seed birthday by simply ensuring that nLockTime is set to a more recent date then that birthday under all circumstances. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets 2017-09-07 16:47 ` Jonas Schnelli 2017-09-07 18:09 ` Peter Todd @ 2017-09-07 18:38 ` Pavol Rusnak 1 sibling, 0 replies; 15+ messages in thread From: Pavol Rusnak @ 2017-09-07 18:38 UTC (permalink / raw) To: Jonas Schnelli, Bitcoin Protocol Discussion [-- Attachment #1.1: Type: text/plain, Size: 1731 bytes --] On 07/09/17 18:47, Jonas Schnelli wrote: > But not sure if it’s worth to save ~two bytes for that. I think it's not worth complicating the field just to save two bytes. But if we agree (for privacy reasons) that resolution of this field should be reduced to week-level (as suggested by Jonas) or month-level (as sugested by Peter), we could use just 16 bits for this. TBH I think TREZOR will provide hardcoded constant for this field (1.1.2014 for all its P2PKH xpubs and 1.8.2017 for all its P2WPKH-in-P2SH xpubs). So no privacy is lost in this case, but if we want to ENFORCE this on BIP level, we should decrease the resolution. > 2. > Would it make sense to have special depth bytes that directly implies it’s a BIP44 master key (and therefore avoid the bip32 path serialisation)? I know some „centralised“ table need to be available for that which may be not a good idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 0xFF) for predefined paths. I think this is exactly what Thomas meant by "wallet developers are going to use dirtier tricks" in his email, that's why I specifically tried to avoid this. I see no good reason to do this, unless we want to save some bytes and I don't think we are in need of doing this. > 3. > Would adding a version bit make sense to allow future extensions? I think changing the human-readable part is the way to go. That way the wallet can immediately say if it understands the format or not, without parsing the binary data contents. Version bits were introduced in older standards, because there was no such thing as human-readable prefix. -- Best Regards / S pozdravom, Pavol "stick" Rusnak CTO, SatoshiLabs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-09-07 20:39 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-06 22:29 [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets Pavol Rusnak 2017-09-07 3:52 ` Kabuto Samourai 2017-09-07 16:25 ` Pavol Rusnak 2017-09-07 16:30 ` Kabuto Samourai 2017-09-07 16:37 ` Pavol Rusnak 2017-09-07 18:02 ` Peter Todd 2017-09-07 4:29 ` Thomas Voegtlin 2017-09-07 16:23 ` Pavol Rusnak 2017-09-07 16:33 ` Kabuto Samourai 2017-09-07 19:35 ` Andreas Schildbach 2017-09-07 20:00 ` Pavol Rusnak 2017-09-07 20:39 ` Thomas Voegtlin 2017-09-07 16:47 ` Jonas Schnelli 2017-09-07 18:09 ` Peter Todd 2017-09-07 18:38 ` Pavol Rusnak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox