Nostr notes by

📅 Original date posted:2015-08-13 📝 Original message:> ...

2023-06-07T17:34:48Z

In reply to nevent1q…65l3
_________________________

📅 Original date posted:2015-08-13
📝 Original message:> On Aug 13, 2015, at 2:52 AM, Ashley Holman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> A concern I have is about security (hash rate) as a function of block size.
>
> I am assuming that hash rate is correlated with revenue from mining.
>
> Total revenue from fees as a function of block size should be a curve. On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 as there is no competition for block space.

This isn’t necessarily true. Every miner has its own mining policy. If they choose to delay including transactions proportional to their fee + first seen, then you create a time based fee market. Want quick confirmation? Pay a high fee. Don’t care that much? Pay a low fee (and anywhere in between). This market would work just fine even if block capacity was unbounded.

jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/9b9afe12/attachment.sig>;

📅 Original date posted:2015-07-28 📝 Original message:> ...

2023-06-07T15:43:41Z

In reply to nevent1q…a9wg
_________________________

📅 Original date posted:2015-07-28
📝 Original message:> Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…
>

The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.

jp

📅 Original date posted:2015-07-23 📝 Original message:There ...

2023-06-07T15:43:00Z

In reply to nevent1q…cg4m
_________________________

📅 Original date posted:2015-07-23
📝 Original message:There really isn't any need for a 3rd party here. Those "services" can just be the miners themselves.

jp

> On Jul 24, 2015, at 8:56 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>
>> Quality of service as in:
>>
>>> X satoshi / kb = included in block currently worked on;
>>
>>> Y satoshi / kb = included in next block;
>>
>>> Z satoshi / kb = included in block after that, etc.
>>
>> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>>
>> Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.
>>
>> It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.
>>
>> jp
>
>
> The scheme I’ve been considering is the use of services (separate from miners) that guarantee inclusion for you for some predetermined price and then do the bidding on your behalf. Via contracts you can guarantee you get included within a certain number of blocks or you receive a full refund…or even possibly receive compensation for failure to deliver.

📅 Original date posted:2015-07-23 📝 Original message:Miners ...

2023-06-07T15:42:59Z

In reply to nevent1q…qzt5
_________________________

📅 Original date posted:2015-07-23
📝 Original message:Miners could include their fee tiers in the coinbase, but this is obviously open to manipulation, with little recourse (unless they are a pool and miners move away because of it).

In any event, I think that trying out a solution that is both simple and involves the least number of parties necessary is preferable.

Have miners set their tiers, have users select the level of quality they want, ignore the block size.

Miners will adapt their tiers depending on how many transactions actually end up in them. If for example they set the first tier to be $1 to be included in the current block and no user chooses that level of service, they've obviously priced themselves out of the market. The opposite is also true; if a tier is popular they can choose to increase the cost of that tier.

jp

> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>
>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>
>> jp
>>
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>
>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>
>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>
>>>
>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> Doesn't matter.
>>>>
>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>
>>>> jp
>>>>
>>>>
>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>>
>>>>>
>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>> start excluding transactions.
>>>>>
>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>
>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>> =LY1+
>>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-07-23 📝 Original ...

2023-06-07T15:42:58Z

In reply to nevent1q…3vec
_________________________

📅 Original date posted:2015-07-23
📝 Original message:Doesn't matter.

It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.

jp

> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> And it's obvious how a size cap would interfere with such a QoS scheme.
>> Miners wouldn't be able to deliver the below guarantees if they have to
>> start excluding transactions.
>
> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
> =LY1+
> -----END PGP SIGNATURE-----
>

📅 Original date posted:2015-07-23 📝 Original message:I ...

2023-06-07T15:42:58Z

In reply to nevent1q…rnkn
_________________________

📅 Original date posted:2015-07-23
📝 Original message:I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.

jp

> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>
> Negotiating directly with miners via smart contracts seems difficult at best.
>
>
>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Doesn't matter.
>>
>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>
>> jp
>>
>>
>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>>
>>>
>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>> start excluding transactions.
>>>
>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>>
>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>> =LY1+
>>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-07-23 📝 Original message:And ...

2023-06-07T15:42:57Z

In reply to nevent1q…208x
_________________________

📅 Original date posted:2015-07-23
📝 Original message:And it's obvious how a size cap would interfere with such a QoS scheme. Miners wouldn't be able to deliver the below guarantees if they have to start excluding transactions.

> On Jul 24, 2015, at 8:45 AM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Quality of service as in:
>
>> X satoshi / kb = included in block currently worked on;
>
>> Y satoshi / kb = included in next block;
>
>> Z satoshi / kb = included in block after that, etc.
>
> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>
> Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.
>
> It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.
>
> jp
>
>> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>>
>>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>>
>>> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>>>
>>> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>>>
>>> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>>>
>>> jp
>>
>> Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-07-23 📝 Original ...

2023-06-07T15:42:57Z

In reply to nevent1q…8qcw
_________________________

📅 Original date posted:2015-07-23
📝 Original message:Quality of service as in:

> X satoshi / kb = included in block currently worked on;

> Y satoshi / kb = included in next block;

> Z satoshi / kb = included in block after that, etc.

Block count starts when transaction is first seen. Miners can set X, Y, Z.

Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.

It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.

jp

> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>
>> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>>
>> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>>
>> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>>
>> jp
>
> Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.

📅 Original date posted:2015-07-23 📝 Original message:You ...

2023-06-07T15:42:56Z

In reply to nevent1q…z53p
_________________________

📅 Original date posted:2015-07-23
📝 Original message:You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.

A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.

Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.

jp

> On Jul 24, 2015, at 8:04 AM, Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I should also add that I think those who claim that fee pressure will scare away users and break the industry are *seriously* underestimating human ingenuity in the face of a challenge. We can do this - we can overcome this obstacle…we can find good solutions to a fee market. Unless someone can come up with another way to pay for the operation of the network, we NEED to do this. What makes anyone think it will be easier to do later rather than now? The longer we wait, the lower block rewards get, the larger the deployed infrastructure, the larger our userbase, the HARDER it will be to solve it. We should solve it now - we will be much better off for it…and so will our users.
>
>
>>> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>
>>>
>>> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr at fragnetics.com> wrote:
>>>
>>> Scaling the network will come in the form of a combination of many
>>> optimizations. Just because we do not know for sure how to eventually
>>> serve 7 billion people does not mean we should make decisions on
>>> global validation that impact our ability to serve the current set of
>>> users.
>>
>> Agreed. But I believe the economic and security arguments I gave regarding fees and incentives still hold and are largely separate from the scalability issue. Please correct me if I overlooked something.
>>
>>
>>> Also, blocking a change because it's "more important to address issues
>>> such as..." other improvements will further slow down the discussion.
>>> I believe an increase will not prevent the development of other
>>> improvements that we need - in contrast, the sooner we can get over
>>> the limit (which, as you agree, needs to be changed at some point),
>>> the sooner we can get back to work.
>>
>> An increase in block size at this time will exacerbate security concerns around nodes relying on other nodes to validate (particularly miners and wallets). It’s not really a matter of having limited developer resources that need to be budgeted, as you seem to suggest.
>>
>> Regarding developments on properly handling fees, there must exist the economic need for it before there’s an earnest effort to solve it. Increasing the block size right now will, in all likelihood, delay this effort. I’d much prefer to first let the fee market evolve because it’s a crucial component to the protocol’s design and its security model…and so we can get a better sense for fee economics. Then we might be able to figure out better approaches to block size changes in the future that makes sense economically…perhaps with mechanisms that can dynamically adjust it to reflect resource availability and network load.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/596bbb00/attachment.html>;

📅 Original date posted:2015-04-07 📝 Original message:FYI, ...

2023-06-07T15:32:18Z

In reply to nevent1q…eau8
_________________________

📅 Original date posted:2015-04-07
📝 Original message:FYI,

https://eprint.iacr.org/2015/310.pdf

jp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150407/f1e62e19/attachment.html>;

📅 Original date posted:2014-11-26 📝 Original message:This ...

2023-06-07T15:27:32Z

In reply to nevent1q…e4c2
_________________________

📅 Original date posted:2014-11-26
📝 Original message:This paper was just posted on reddit that describes how an attacker can de-anonymize clients on the bitcoin network. It mentions that the core devs were contacted prior to publication. I was just wondering, how many of these issues have already been addressed?

Paper (University of Luxembourg):
http://orbilu.uni.lu/handle/10993/18679 <http://orbilu.uni.lu/handle/10993/18679>;

Kind regards,

Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141125/01250a5f/attachment.html>;

📅 Original date posted:2014-04-08 📝 Original ...

2023-06-07T15:17:43Z

In reply to nevent1q…8573
_________________________

📅 Original date posted:2014-04-08
📝 Original message:Isn't that just conceding that p2p protocol A is better than p2p protocol B?

Can't Bitcoin Core's block fetching be improved to get similar performance as a torrent + import?

Currently it's hard to go wide on data fetching because headers first is still pretty 'beefy'. The headers can be compressed, which would get you about 50% savings.

Also, maybe adding a layer that groups block headers into a single hash (say, 2016 headers), and then being able to fetch those (possibly compressed) header 'blocks' from multiple sources in parallel. And fanning out block fetches even further, favoring fast nodes.

Just thinking out loud.

jp

> On Apr 7, 2014, at 8:44 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
>> On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>>> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>>> BTW, did we already agree on the service bits for an archive node?
>>
>> I'm still very concerned that a binary archive bit will cause extreme
>> load hot-spotting and the kind of binary "Use lots of resources YES or
>> NO" I think we're currently suffering some from, but at that point
>> enshrined in the protocol.
>>
>> It would be much better to extend the addr messages so that nodes can
>> indicate a range or two of blocks that they're serving, so that all
>> nodes can contribute fractionally according to their means. E.g. if
>> you want to offer up 8 GB of distributed storage and contribute to the
>> availability of the blockchain, without having to swollow the whole
>> 20, 30, 40 ... gigabyte pill.
>>
>> Already we need that kind of distributed storage for the most recent
>> blocks to prevent extreme bandwidth load on archives, so extending it
>> to arbitrary ranges is only more complicated because there is
>> currently no room to signal it.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2014-03-12 📝 Original message:On Mar ...

2023-06-07T15:15:15Z

In reply to nevent1q…x4cf
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On Mar 12, 2014, at 08:55 AM, Pavol Rusnak <stick at gk2.sk> wrote:

On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
Yes I am. There are some differences between BIP 39 and my proposal though.
- BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers.

Which is better IMO. I can't imagine anyone writing down a long Base58
encoded string.

That depends on your use case. A list of words is totally fine for someone to write down, a long string of case sensitive letters is easier to put into a QR code.

- BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length.

Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).

I stand corrected.

- BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan.

This is nice addition, indeed. But we needed to limit the data as
possible in order not to increase the number of words needed to be noted
down.

My proposal didn't have this either initially, but it was deemed an essential feature for SPV clients.

- BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it.

It has a detection. Not correction though.

If I understand the code correctly (and please correct me if I'm wrong), the validation only happens on the mnemonic list, not on the password:

"Described method also provides plausible deniability, because every passphrase generates a valid seed (and thus deterministic wallet) but only the correct one will make the desired wallet available"

So upon entering a password with a typo, the user will not be notified of an error, but be presented with a wallet balance of 0, after the blockchain has been scanned. I'm sorry, but that's not the kind of experience I would want to present to my users.

- BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512.
- BIP 39 can't outsource the KDF computation to a 3rd party.

True, but having one or two solid options are better than having
gazillions of possible options.

5 defined KDFs out of a possible 32 is hardly "gazillions".

- BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility.

True, but they are encouraged to use the list provided. Possibility to
outsource KDF outside of your "standard" breaks much more compatibility
than this.

Would you care to elaborate how optional outsourcing of the KDF breaks compatibility?

jp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/c685124f/attachment.html>;

📅 Original date posted:2014-03-12 📝 Original message:On Mar ...

2023-06-07T15:15:14Z

In reply to nevent1q…rzpx
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On Mar 12, 2014, at 09:49 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:

Jean-Paul, it may be worth noting that the BIP39 word list is integrated into Bitcoinj so will likely become the de facto standard for Android, Trezor web and several desktop wallets. Anyone deviating from that word list would likely find themselves in an isolated pocket.

Regarding the timestamp, MultiBit HD uses a simple timestamp of "number of days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum appended". Thus a new seed generated on 27 January 2014 would have "1850/01" as its checksum.

I'm a bit confused, are you changing the way the checksum is calculated, or fudging the input seed to produce a specific checksum? Or is checksum in this case another value calculated over the mnemonic list?

When creating a new wallet the users are tested that they have written the timestamp down along with the associated 12/18/24 words.

So this is specific to MultiBit HD? Wouldn't it be better to include this into the BIP?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/98bf75f9/attachment.html>;

📅 Original date posted:2014-03-12 📝 Original message:On Mar ...

2023-06-07T15:15:13Z

In reply to nevent1q…vy4t
_________________________

📅 Original date posted:2014-03-12
📝 Original message:On Mar 12, 2014, at 6:11 AM, Pavol Rusnak <stick at gk2.sk> wrote:

> On 03/12/2014 04:17 AM, Jean-Paul Kogelman wrote:
>> We've been hard at work updating the spec to include features that were requested. We've removed the Scrypt dependency that was present in the initial drafts, added new KDFs, added plausible deniability and have a reference implementation.
>
> Are you aware of BIP-0039?
>
> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
>
>

Yes I am. There are some differences between BIP 39 and my proposal though.

- BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers.
- BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length.
- BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan.
- BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it.
- BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512.
- BIP 39 can't outsource the KDF computation to a 3rd party.
- BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility.

jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/0e89e648/attachment.sig>;

📅 Original date posted:2014-03-12 📝 Original message:Hi ...

2023-06-07T15:15:12Z

In reply to nevent1q…4mcc
_________________________

📅 Original date posted:2014-03-12
📝 Original message:Hi everyone,

We've been hard at work updating the spec to include features that were requested. We've removed the Scrypt dependency that was present in the initial drafts, added new KDFs, added plausible deniability and have a reference implementation.

Kind regards,

Jean-Paul Kogelman

---

Recent changes:

15-02-2014 - Updated wording of various parts.
06-02-2014 - Added Will Yager's implementation as reference.
05-02-2014 - Changed prefix to 2 bytes, 'RK' and 'rk' for clear version and encrypted version respectively.
05-02-2014 - Added entropy field to encrypted version, moved KDF field from prefix into entropy field.
05-02-2014 - Changed computation of H to use PBKDF2-HMAC-SHA512 instead of Scrypt.
05-02-2014 - Changed checksum field to bloom field in encrypted version. Now supports 2 passwords.
27-12-2013 - Added some clarifications such as password character set (UTF-8) and endianness of fields.
26-12-2013 - Changed checksum to double SHA256 of private key, added 3rd party KDF support.
01-10-2013 - Expanded the salt to be prefix + date + checksum and renamed 'master seed' to 'root key'.
24-07-2013 - Added user selectable KDF + parameters, encoded in the prefix.
22-07-2013 - Added 2 byte creation date field, as a result, the prefix is expanded to 3 bytes.

BIP:
Title: Base58 encoded HD Wallet root key with optional encryption
Author: Jean-Paul Kogelman
Status: Draft
Type: Informational
Created: 18-07-2013

Abstract

This proposal describes a method for encoding and optionally encrypting a Bitcoin Hierarchical Deterministic (HD) Wallet root key. Encoded root keys are intended for use on paper wallets. Each string contains all the information needed to verify and reconstitute an HD wallet except for the optional passphrases. The encrypted version uses salting and a user selectable key derivation function (KDF) + parameters to resist brute-force attacks at varying degrees and optionally a second password for plausible deniability.

The method provides two encoding methodologies in 3 lengths each (16, 32 and 64 byte root keys). One is a clear version of the root key with verification information for integrity checking and the other is an encrypted representation.

Additionally a 2 byte compressed date field is present to limit the block chain rescan on wallet import.

Motivation

The extended private keys proposed in BIP 0032 are long, fixed length records and don't offer any form of security. The root key used to generate the HD wallet is typically shorter than the extended master private key that results from it.

A compact representation of the root key is easier to handle and a 2-factor version of the root key record allows for safe storage and the creation of paper wallets by 3rd parties. The KDF and its parameters are user selectable, allowing for a varying level of resistance against brute force attacks. This proposal currently defines 5 sets of parameters with room for 27 more that can be defined at a later date. Implementors are advised to contact the author with new KDF proposals.

Copyright

This proposal is hereby placed in the public domain.

Rationale

User story: As a Bitcoin user who uses HD wallets, I would like the ability to store my wallet root key in a compact form as a paper wallet.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to have a 3rd party create a paper wallet with my root key in it, without having access to the funds stored in the wallet.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to choose the strength of the root key depending on my security requirements and how I wish to store it.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to import a root key into a simplified payment verification (SPV) client without having to redownload the entire block chain, but rater a limited range, to find associated transactions.

User story: As a Bitcoin user who uses HD wallets, I would like to choose the KDF and its parameters that is used to hash the passphrase that protects my root key to fit my security needs and available processing power.

User story: As a Bitcoin user who uses HD wallets, I would like to outsource the KDF computation to a 3rd party with more processing power.

User story: As a Bitcoin user who uses HD wallets, I would like to have a second password that can decrypt a second root key.

Specification

This proposal makes use of the following functions and definitions:

All input/output text is to be UTF-8 encoded

AES256Encrypt, AES256Decrypt: The AES block cipher, applied in ECB mode.

SHA256, SHA512: The hash algorithms of the same name.

HMAC-SHA512: The HMAC message authentication code algorithm, using SHA512 as the hash function

PBKDF2-HMAC-SHA512: The PBKDF2 key derivation algorithm, described in PKCS #5 v2.0 and RFC 2898, using HMAC-SHA512 as the pseudorandom function

Scrypt: The key stretching algorithm of the same name

Base58Check: The textual data encoding frequently used by various Bitcoin-related systems

"Root Key": The 16/32/64 byte value encoded in the wallet. This value is used to derive the private keys for addresses in the Bitcoin Wallet

"Master Key": The primary Bitcoin private key, which is derived from the Root Key

"||" refers to concatenation, not the logical OR operation

"G", "N": Constants defined as part of the secp256k1 elliptic curve. G is an elliptic curve point, and N is a large positive integer.

Prefix

The Base58Check representation of the wallet will start with "RK" (Root Key) if the wallet is unencrypted, and will start with "rk" if the wallet is encrypted.

Proposed specification

Unencrypted wallet:

Prefixes:
0x28C1: 16 byte root key, no encryption. 24 byte total length
0x4AC5: 32 byte root key, no encryption. 40 byte total length
0xFBB3: 64 byte root key, no encryption. 72 byte total length

These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.

"date" is a 2-byte, little endian field containing the number of weeks since jan 1st 2013. It is used to optimize blockchain scan upon wallet import.

"checksum" is the first 4 bytes of SHA256(SHA256(master_secret)), where master_secret is the "Master Secret Key (IL)" from the BIP32 specification. In other words, "checksum"=SHA256(SHA256(HMAC-SHA512("Bitcoin seed", root_key)[0:32]))[0:4].

"root_key" is the 16/32/64 byte root key used for the HD wallet

In summary, the clear wallet looks like this:
[prefix, 2 bytes][date, 2 bytes][checksum, 4 bytes][root_key, 16/32/64 bytes]

Range in Base58Check encoding for clear 16 byte root key (prefix RK):
Minimum value: RK52zvuD3xRhwto8JDTonxhru6awsFfNqKCTmT (based on 0x28 0xC1 plus twenty-two 0x00's)
Maximum value: RKCsfF9RpLnrxo1kp2o7mfWYeAV1NNYxWSMRym (based on 0x28 0xC1 plus twenty-two 0xFF's)

Range in Base58Check encoding for clear 32 byte root key (prefix RK):
Minimum value: RK15fXAj9BEMooghtx2gY5YrSh23LYKS8mZnaz8oYf1EDnqAwtAADGMVUDHG (based on 0x4A 0xC5 plus thirty-eight 0x00's)
Maximum value: RK5MUEoFU24QARcsX5HR2ieCjem468hDeQm4J2aH5zsCVJXUCGn6nsVQEFhN (based on 0x4A 0xC5 plus thirty-eight 0xFF's)

Range in Base58Check encoding for clear 64 byte root key (prefix RK):
Minimum value: RK1uXsCQAKqaa2s7YBDeaLS2KTqZcNjjQSgdSfDv4fqGkTw8KBfZ2ND4Cp7vHdzhjJ2C2Jtf4CwgScRnXvpzuQT2W4Vj2SgCyfBgpTzF (based on 0xFB 0xB3 plus seventy 0x00's)
Maximum value: RK3B9TMn55dey3an1oHpwB81FPZboakivYtqFvCaeknPzPK4iTvoFKzxVWKcD9YfJwjkyS36bqnSqjibUurcQ7J2EsQww5zPpJNzqjkw (based on 0xFB 0xB3 plus seventy 0xFF's)

Encrypted wallet:

Prefixes:

0xF83F: 16 byte root key, encrypted. 26 byte total length
0x6731: 32 byte root key, encrypted. 43 byte total length
0x4EB4: 64 byte root key, encrypted. 76 byte total length

These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.

"date" is a 2-byte, little endian field containing the number of weeks since jan 1st 2013. It is used to optimize blockchain scan upon wallet import. The maximum value of 0xFFFF results in: jan 1st 3269

"entropy" is a 2/3/4 byte (corresponding to whether the key is 16/32/64 bytes) field. The first five bits contain the KDF type, and all other bits contain random data. This is used as a salt to make cracking the wallet password harder.

"bloom_filter" is a 4 byte little-endian field containing a bloom filter to check that the user entered their password correctly.

"encrypted_root_key" is the 16/32/64 byte encrypted root key used for the HD wallet

In summary, the encrypted wallet looks like this:
[prefix, 2 bytes][date, 2 bytes][entropy, 2/3/4 bytes][bloom_filter, 4 bytes][encrypted_root_key, 16/32/64 bytes]

Range in Base58Check encoding for encrypted 16 byte root key (prefix rk):
Minimum value: rk2V4R2ys91WigNPL5nots6a97rfMnwTkPAb2XgNo (based on 0xF8 0x3F plus twenty-four 0x00's)
Maximum value: rk57mv9oertBLsHfncAvqnbetCBdNS1gFHQaFsD3p (based on 0xF8 0x3F plus twenty-four 0xFF's)

Range in Base58Check encoding for encrypted 32 byte root key (prefix rk):
Minimum value: rk1CYsqKjsbXa7uvncEaW4XSeVzcpq1U9yDMxd2cWwfkGf1FMjENaVThYpLRNwqo (based on 0x67 0x31 plus fourty-one 0x00's)
Maximum value: rk7Xw5b6fidaCk489LhaiMqHkZo7RYGTmzvJY9A5joxe8KXAn8BC66cmQPYYYvy8 (based on 0x67 0x31 plus fourty-one 0xFF's)

Range in Base58Check encoding for encrypted 64 byte root key (prefix rk):
Minimum value: rk48BmQWeQbATSXbP5U6XVsXRJTs4Ea1TVZBbHLPPsboCFyxDj2Jaz2JAJno97hq6dq2bANLuWydY8QSZgKVGhPRZazXt1swPXwzVLw1QnVAz (based on 0x4E 0xB4 plus seventy-four 0x00's)
Maximum value: rkCRtT9R9kuAapCaLQFif5uo8gUrjgKsvYmGGTpX2ZTjTfwe9M7A6KezTh7f4FDxfZFVbHypodMNnNdmWYb8mzTokHXVR1u7KicrLLFFu7GJW (based on 0x4E 0xB4 plus seventy-four 0xFF's)

Encoding of KDF + parameters:

A number of KDF functions are available, to accommodate a wide range of possible use cases. The KDFs are defined as follows:

ID KDF Parameters
0x00 scrypt n = 2^14, r = 8, p = 8
0x01 scrypt n = 2^16, r = 16, p = 16
0x02 scrypt n = 2^18, r = 16, p = 16
0x08 PBKDF2-HMAC-SHA512 iterations = 216
0x09 PBKDF2-HMAC-SHA512 iterations = 221

All other possible values (3-7 and 10-31) are reserved.

Please note that KDFs 1 and 2 will probably not run on mobile devices. KDFs 8 and 9 are very memory efficient.

Generation of date:

The purpose of the date field is to make scanning the blockchain for transactions to/from this wallet faster. The date *must* be on or before the date of the first transaction to/from the wallet. If the date is unknown (e.g. on an embedded device) or the user does not wish to reveal the wallet creation date, this field can be set to zero (which may incur a performance penalty for the wallet software). When importing, it is advised to start scanning from a few days before the encoded date. The date field is a little-endian integer containing the number of weeks, rounded down, since Jan 1st 2013.

Examples:

sep 18th 2013 - jan 1st 2013 = 260 days = 37 weeks 1 day = rounded down becomes 0x0025
mar 3rd 2027 - jan 1st 2013 = 5174 days = 739 weeks 1 day = rounded down becomes 0x02E3

Derivation of Master Key from Root Key (please see BIP 0032 for a full description of HD wallets):

1. Take 16/32/64 byte Root Key. Call it S
2. Calculate I = HMAC-SHA512(key = "Bitcoin seed", msg = S)
3. Let IL = I[0:32]. IL is the Master Key
4. If IL is 0 or IL >= N, where N is the curve order of Secp256k1 (the elliptic curve used by Bitcoin), the Root Key is invalid and a new one should be chosen.

Encryption:

Let "passphrase" be the user's chosen passphrase
Let "fake_passphrase" be the user's chosen second passphrase, or a randomly generated string if the user chose not to use a second passphrase
Let "KDF" be the chosen key derivation function
Let "root_key" be the 16/32/64 byte Root Key

1. Create the correct "Prefix" and "Date" field
2. Create the random "Entropy" field and encode the KDF number in the top 5 bits
3. Let "salt" = Prefix || Date || Entropy
4. Calculate "preH" = HMAC-SHA512(key = salt, msg = passphrase)
5. Calculate "strongH" = KDF(msg = preH, salt = preH, output_len = 64) This step can be outsourced to a 3rd party, if desired.
6. Calculate "postH" = HMAC-SHA512(key = passphrase, msg = salt)
7. Calculate "H" = PBKDF-HMAC-SHA512(msg = postH, salt = strongH, iterations = 210, output_len = len(root_key) + 32)
8. Calculate "whitened_key" = root_key XOR H[0:len(root_key)]
9. Calculate "encrypted_key" = AES256Encrypt(message = whitened_key, key = HR), where HR is the last 32 bytes of H
10. Calculate "fake_key" by decrypting encrypted_key with fake_passphrase
11. Calculate "bloom_filter", containing root_key and fake_key. See the "Bloom Filter" section for more info.

encrypted_wallet = Prefix || Date || Entropy || bloom_filter || encrypted_key

Decryption of Root Key:

Let "passphrase" be the passphrase provided by the user

1. Extract "Prefix", "Date", "Entropy", "bloom_filter", and "encrypted_key" from the encrypted wallet
2. Determine the correct KDF from the top 5 bits of Entropy.
3. Let "salt" = Prefix || Date || Entropy
4. Perform steps 4 through 7 of Encryption to derive "H"
5. Calculate "whitened_key" = AES256Decrypt(message = encrypted_key, key = HR), where HR is the last 32 bytes of H
6. Calculate "root_key" = whitened_key XOR H[0:len(whitened_key)]
7. Verify that root_key is a member of bloom_filter

Bloom Filter:

The Bloom Filter is a data structure that allows us to check, within a range of probability, whether or not some piece of data has been added to it. In this case, we want to make sure that the user entered their password correctly, so we're checking that the decrypted root_key corresponds to the one that was added to the bloom filter when the wallet was created.

Bloom Filter Creation:

1. Let "bloom_filter" be an empty (set to all zeros) 32-bit, little-endian integer
2. To add an element "X" to bloom_filter,
3. Calculate "E" = SHA256(SHA256(HMAC-SHA512("Bitcoin seed", X)[0:32]))[0:11]. Note, this corresponds to the same algorithm used as a checksum for un-encrypted wallets. It also corresponds to the double-SHA of the Master Key.
4. For each of the 11 bytes in E (call each byte "B"):
4a. calculate "N" = B & 0x1F. N will range from 0 to 31. Set the Nth bit in bloom_filter to 1

You can add more items to the bloom filter, if desired. However, the filter parameters are optimized for 2 items (one "real" password/wallet, and one "fake" password/wallet). Please note that adding more items will drastically increase the chance of a false positive when entering a password. The chance of a password similar to a correct password passing the filter becomes more likely. This will generate a different Root Key and not the original one the user intended to decrypt.

Bloom Filter Verification:

Let "X" be some item
Let "bloom_filter" be the Bloom Filter you want to check if X belongs to

1. Calculate "x_only_filter", which is a Bloom Filter with X added to it
2. Ensure that any bit that is set in x_only_filter is also set in bloom_filter (i.e. x_only_filter & bloom_filter == x_only_filter)
3. If all bits set in x_only_filter are also set in bloom_filter, you know X is probably a member of bloom_filter. If not, X is definitely *not* a member of bloom_filter.

Suggestions for implementers of proposal with alt-chains

This proposal is network and coin agnostic (so long as the coin in question uses SECP256K1 ECC). Alt-coin implementors are advised to change the prefixes so that encoded root keys do not start with “RK" or “rk”.

Reference implementation

Python reference implementation: https://github.com/wyager/Encrypted-HD-wallet

Acknowledgements

Will Yager for the Python reference implementation and rewording of parts of this specification.
Mike Caldwell for BIP 0038, which this proposal borrows heavily from.

See Also

BIP 0032 Hierarchical Deterministic Wallets: https://en.bitcoin.it/wiki/BIP_0032
BIP 0038 Passphrase-protected private key: https://en.bitcoin.it/wiki/BIP_0038

Test vectors

The primary password will always decrypt the same root key, regardless of KDF selection, however, the secondary password will generate a different root key for every KDF.

Test 1:

Root Key 000102030405060708090a0b0c0d0e0f
Creation 04-02-2014
Clear RK6nEaou4eFQC4SfrHtdh9jpnEme4K9dt2jBmG
Password Satoshi
Public Address 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma
Private extended key xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
Public extended key xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8
Second password Alpaca
Encrypted (KDF0) rk354bXH1JsXTwWmuvRskFWoeUX8hMjQiseNM7wj6
Public Address 1Ndr6DnQm5EefVhTdKjXC3vH5qGRa1FCng
Private extended key xprv9s21ZrQH143K3TxQaa6hd8mPR9Bw2ue1H5TMjUYuUEPEDUTxK7PZ191poMob8zbU5hsckCQoBFYtQZzbgxtYz1acbLmFQtjcbWSYhQ7kSZE
Public extended key xpub661MyMwAqRbcFx2sgbdhzGi7yB2RSNMreJNxXrxX2ZvD6Go6rehoYwLJecVAuhHhMPSuMStnLHbzQ4CCyPqbVyLP4F2SmiLTcE3oicmA81M
Encrypted (KDF1) rk354bq4dXW8VB67XSZzQdVLFJFz64v1Dh1i12VTY
Public Address 12cbi9vTjpZ8RjinLc2fJp1iDkL96xMQoe
Private extended key xprv9s21ZrQH143K4JxBYKwi5dGE59G4vtRGLiyinEPxMdgYdPe6UqMrgJneacME8JQuoskvEzEZ1vnHwW8i1h4Mwm5wj5BUPJWf764QfkkvFAQ
Public extended key xpub661MyMwAqRbcGo2eeMUiSmCxdB6ZLM97hwuKacoZuyDXWByF2Ng7E778RrYidat9n9Ht5cYrdS4gwVBA2g8VHAro7b4Gbvo2NKTLP9STuvP
Encrypted (KDF8) rk354dUN5yrKvrMQRneKJvdJFf77WDJw5ZfeeRt4H
Public Address 14z6Vm4TRxd9ueasFahwBxYJ8jfhwhX4bt
Private extended key xprv9s21ZrQH143K2AaodGyHvDBQFrFcDdHVJj15zqJUkU1wuLS5kFxgE9rGBvh8rAUeenfhhwC91efxn8kHbhKGeTaQkkyGFvbKiAuLcx8t8qP
Public extended key xpub661MyMwAqRbcEefGjJWJHM88ot66d61LfwvgoDi6JoYvn8mEHoGvmxAk3DfcWWuDBqMUmPoXA28pa2uMnQFxKQe21Df5uQAGADCpcdZHAGe
Encrypted (KDF9) rk354dedikaytYJ7D4btpcVfGuakfixf5yj2SnTcX
Public Address 17tzY2huzjbcRNV7e7BshxQ8UPrZhznBgn
Private extended key xprv9s21ZrQH143K3Xt1wRGXFZ6D76dGLyGTWxvPv1QhkRcyPCbi6kM7WJG9dH6X9UMmzoTwoix3BsnzKf7ZkkpinPw8hyGaNLWzmcbemJVUWTj
Public extended key xpub661MyMwAqRbcG1xV3SoXch2wf8TkkRzJtBqziPpKJm9xFzvreHfN46adUXfeFiVokTrKsBvK3zBgDJcUThjDtXAZ2dw9SYg74YMFjENB4aa

Test 2:

Root Key 7f0ad7d595be13e6fe4cf1fa0fbb6ae9c26c5d9b09920709414982b6363d5844
Creation 04-02-2014
Clear RK22qqMb3CozsQfTTbSVsLEgXcjekut99SuSHn6urU4vWxjiQneHWVYabWgv
Password Nakamoto
Public Address 1A54ECavJaJAoLGqqNrPd9Y3cvSvkL2Roz
Private extended key xprv9s21ZrQH143K3f9hMVvcbY4EX4CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAcL6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8bDr118t3
Public extended key xpub661MyMwAqRbcG9EATXTcxfzy563ANKxjyK7fykABT1ooL5A6iQw4NukpHShDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgfkQvYBQPP
Second password hunter2
Encrypted (KDF0) rk2cMHki73WbrYgo7XK9kSr6CGBPsMjU3uZf3f3qxCv4QoGy63DkBoGJKhPdvUtp
Public Address 16UCUo31Y7qDMWSs68FBAW759X4K3PZ9kN
Private extended key xprv9s21ZrQH143K2dojoDyxmK7SLnyqSvn56oysqu2Ctf24Rdux6JFLReRgcH5KAM1GxCTVxjpc13Mh18kSmYqUep5EkbDvQJfEEVeLZXhyuYj
Public extended key xpub661MyMwAqRbcF7tCuFWy8T4AtppKrPVvU2uUeHRpSzZ3JSF6dqZaySkATZEZWFcAMxqhD7oTdcaufofFy1WGLF7U21rztvTv6qmGrPq7s2W
Encrypted (KDF1) rk2cMJ1KizRTPbBv8zaECpcQEY66SiZcfM2yAuCpdjDbJsdgZu9xdoFDpGuTVRYe
Public Address 15PXuaVAiU2fEEAsUjxWYHtzoM4D6FaC5F
Private extended key xprv9s21ZrQH143K35ajB7SFjQJAzrmGbAJyp7iBYxhB3DcY9CC8XW5GkAHXDe2HXG6hUS3iquPbGAPuZygXm43BgYamWxiDN5sFm7w12db4uvU
Public extended key xpub661MyMwAqRbcFZfCH8yG6YEuYtbkzd2qBLdnMM6nbZ9X1zXH53PXHxc14vcMHtfJRGTZVgj2gz8sc6sUuYoFub9HaBzkfaxguH4Byqo9NhK
Encrypted (KDF8) rk2cMNSiQsAATQ19Y12nhGuL2uksZVASxNXAdjqrU3KaVcLH71No442sH1YvcwDL
Public Address 13jQ3pnGznGNTC2LVxJz1m27opav8WPVvH
Private extended key xprv9s21ZrQH143K3aA9djUAAX1ASAcdqtuHEXmypDNd8gNy5PH4nm7y4QrieVdw7iQgA46LCJJAxdcN4qrP87Tp8XzJQbw7aeH3LPK8G7Zj6YT
Public extended key xpub661MyMwAqRbcG4Ecjm1AXewtzCT8FMd8bkhacbnEh1uwxBcDLJSDcDBCVnvvrsENPhxpCZ3FYVokSvwfJJFVU9KF3ctQQJp229pgcFLavKJ
Encrypted (KDF9) rk2cMPALytexkDuxm6QREojvgzoKcgKNeURPXDTVzPdZmbfzM2R3RX75Qqu4Yk5r
Public Address 1NBQsYC1vhfbkEoiPWmUb1QN36cCsMxcti
Private extended key xprv9s21ZrQH143K4X6wJWAQbDawhqb2DaQT7mjbPhqNBHmspzrD1J5kcnb5syHr9LQggN3PtmvkjbMVs4zgTyjWmqKS4ix7J92z59cvbkF5W1s
Public extended key xpub661MyMwAqRbcH1BQQXhQxMXgFsRWd38JUzfCC6EyjdJrhoBMYqQ1AauZjGev413kscEPLn4s3XmiDoL1pevGUKACx5ZhhPHvujKaVpe5TRt

Test 3:

Root Key fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8 a8784817e7b7875726f6c696663605d5a5754514e4b484542
Creation 04-02-2014
Clear RK2BvY13FUD6bX25tA7XDyfAn7zbXSL8pR6TRE3EHZZ8qBm9qEyZRih8x1XhhcZwjcTfpe1Qjydn4KU dia8Wf1NshUusP1D38i88MLU9
Password Vires In Numeris
Public Address 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg
Private extended key xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
Public extended key xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB
Second password Quis Custodiet Ipsos Custodes?
Encrypted (KDF0) rk5ySVmNtFzgWZFXAehk6Akvf5PanApA5Y12arynxXZF7Lhc1YqaudukJFngEBXkpc4RGqqkM3ZW4RjE7HwhWTB5Uxi7pXy7vuKouQuZZzoTP
Public Address 1AbB8okTm3SgcHnqKskQFfBd1MndDq1G75
Private extended key xprv9s21ZrQH143K4PUz4iSDMmUE9uovNGnZE6jZdKPDqozk8nBHBk3FRXo3tJEt4TFfo7Tkhnc9TAzUFvg7hsg7M1SddHF6nX9bBw9Tn968Aki
Public extended key xpub661MyMwAqRbcGsZTAjyDiuQxhweQmjWQbKfARhnqQ9Xj1aWRjHMVyL7XjaDV9SNrb7S8YvGtTGUkrRLS3kTDbRKRq26khyJDyKDuquaBqRM
Encrypted (KDF1) rk5ySWZriEipJWKyL6X8Rd86cgKn9qgGC7C4QYLVCjhyuBZiKXezzf6vjyJBXtFmP1f4qzaAAP5baRhKP4yCGo6LAU9keJCvRXoU77SUNmg1o
Public Address 1Fzh1NoMtYUBAoKQ2Lsb6rA81bKFfNx2az
Private extended key xprv9s21ZrQH143K4KmLN9WLjPsVmKgVXPUfAScqkGeifQpTeXFw2X4ijfWNMDMtu4qfbbHZ69VSLcCMiGLHSLaQQY7Rb3PzHMRLLqVN6mjrGHP
Public extended key xpub661MyMwAqRbcGoqoUB3M6XpEKMWyvrCWXfYSYf4LDkMSXKb5a4NyHTprCW3JAJ66rn947iM9iyzUoS4CSXhsDZyuaks5hueT9wtDSdm91ga
Encrypted (KDF8) rk5ySbwggFoh8MZ1CnxqSeKwzag9ifrECtToowiRYKRgcueyMGX39yBGwxbY7ExKeTSmCRHokToThN8pxYWA9WQKrouVuatCMjcvX8PZ16tPf
Public Address 1AiALvRHrWwjViJn5Q6oki4qVZ5p7SepfB
Private extended key xprv9s21ZrQH143K3CHptaD7aNZBUAYhjmCe5ceDLttwqKoQ3F73DRHNrSAVphAX2okZDWK82Eznf4bpmv9qjHZ7nzQjv2qNqXV8YwCWQEw2jiA
Public extended key xpub661MyMwAqRbcFgNHzbk7wWVv2CPC9DvVSqZp9HJZPfLNv3SBkxbdQEUyfwf9rtzBwBvKTV2WDejdPupDmihidJmDTTgXpar3r48kNiGhEzC
Encrypted (KDF9) rk5ySd2iHrVJ1CZ86Pyt6zerNzzBHfZo2rcBAX4MKNzX7doCZnNpBMc3pPf6igTCnk796isqtaEdcfagrN8Pced9VAtENVBtpugBLnjiGd28h
Public Address 1Gazv3FH8oDxUUzgrRmWL14X3oBY5myDdQ
Private extended key xprv9s21ZrQH143K3YMD7T6LoFVGttrMKj9jxGAxfCv3pv6ZQfWcuBV5pqdcjyooGrqa8NeraYUuiTWJSWuz4fVMiCuEK8tWggZ6yMZZK7xLBkx
Public extended key xpub661MyMwAqRbcG2RgDUdMAPS1SvgqjBsbKV6ZTbKfPFdYHTqmSioLNdx6bH6v4uA4MWygDxbDDbVGPCurrTm5RwMnh14jEaswhA6nFK1bFd2

Test 4:

Root Key 6ca4a27ac660c683340f59353b1375a9
Creation 04-02-2014
Clear RK6nEmXZj2nqgtCVWk3s7Suvz2XtWrdhDPpJqS
Password 聡中本
Public Address 1JVncPbsdB2s4zHim3VdAWNkZ8JANBZ1U9
Private extended key xprv9s21ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8dq8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbgxw2QA
Public extended key xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fchw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o
Second password Bitcoin
Encrypted (KDF0) rk354bYQBax15mmBSLTpaVuLRb9nDuaVbEseqBWpG
Public Address 1AGXnLksHQgovEyQvj8kY9QtFV2x8D1Nm
Private extended key xprv9s21ZrQH143K3BMoPfivq74do9mxCnKRTZHWScTvVyrxGtCNvGd8bCZJk1Npwnds3ghiy4TTwmwtbSkpzTFcqLup57AWqm3NvRr6sNs7ZVt
Public extended key xpub661MyMwAqRbcFfSGVhFwCF1NMBcScF3GpnD7EzsY4KPw9gXXTowP8zsnbJTDhU9o9Sj9M63Qx6bZhZ7gS6AzNjNehPUbqdhc6th1VA1FGVg
Encrypted (KDF1) rk354bi6JiGeb5suvydsNtTosocEbpWcjoK7VL9Xv
Public Address 1DkoSDVN7aYZnGe3wUCXAjqc3cXT9oiHhG
Private extended key xprv9s21ZrQH143K2Su2mQR7u6pweA8kwv4y3bKkvUeJUanC4eT7VVp64VxNH5uzwY12wE315rZMMf5XJQLcNLPBF7zcgoFv29UM3R9ctDqdshr
Public extended key xpub661MyMwAqRbcEvyVsRx8GEmgCByFMNnpQpFMis3v2vKAwSnG338LcJGr8NDyhCcF7QV65cmybwrhCkYre87pkG3NCpckbc2itaJknWnwGGX
Encrypted (KDF8) rk354dLtDHN3mPNSFABTNrhKmweKPZ55LJ31EM3k6
Public Address 1QShZTrKPJPBcstuYX5JKRHPs1HUtD7y8
Private extended key xprv9s21ZrQH143K43FPi9awkCScXaAY4mEJje4PhS5uk2R67QU6p7bHXbvwgRdcwU9xZozYZ9hqfjm6ccAbGgU5eN4fp7uMY59MGq8swJVQPKW
Public extended key xpub661MyMwAqRbcGXKrpB7x7LPM5c12UDxA6ryzVpVXJMx4zCoFMeuY5QFRXfg1tnVaP3Fv1tmhoV8jrRG29Gip9FwW7j3vGLNneaMepS1QuHP
Encrypted (KDF9) rk354diEYQb4EdNjyosAZGNAB8L1spefWdz7RmZfX
Public Address 1NLVhK8AQn7p2edvTtFJgTz6itrBeHZ4Wa
Private extended key xprv9s21ZrQH143K2stwSFWe4rPabNH1k1EVwQKwr7poayVZNPJup716aWVjDBVRVRh8gSgZhTP4uiaNuCkFbXXJCbDSnmvwNbnCuvQqHDDj7Ew
Public extended key xpub661MyMwAqRbcFMyQYH3eRzLK9Q7W9TxMJdFYeWER9K2YFBe4MeKM8JpD4RrrKNRrTMT9T7FvDbvWhzAXT68HxuyZGJ9BkC6G3ZiMjj1UT76

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140311/fba653b4/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140311/fba653b4/attachment.sig>;

📅 Original date posted:2013-11-15 📝 Original message:On Nov ...

2023-06-07T15:09:36Z

In reply to nevent1q…8uzr
_________________________

📅 Original date posted:2013-11-15
📝 Original message:On Nov 15, 2013, at 05:10 PM, Luke-Jr <luke at dashjr.org> wrote:

On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
So "a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times".
Then at least you are not using the same word for two different meanings
and you're using stuff more familiar in popular lexicon.
I dont think it's helpful for users if we use the word "blocks".

"Confirmations" in a numeric context isn't correct, though. We're using to it
because we've been using Bitcoin so long, but to the average person they would
expect it to mean something more than it is. If not referring to blocks, then
perhaps "witnessed N times"?

Why not call it "Clearing" for transactions with < 6 confirmations and "Cleared" for >= 6?

The round ticker should be enough of an indication of the progress.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131116/efd41732/attachment.html>;

📅 Original date posted:2013-10-25 📝 Original message:Would ...

2023-06-07T15:08:08Z

In reply to nevent1q…76qt
_________________________

📅 Original date posted:2013-10-25
📝 Original message:Would it make sense to use either fixed length strings or maybe even enums?

On Oct 25, 2013, at 05:34 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
Mike Hearn has been lobbying for an "error" message in the Bitcoin p2p protocol for years (at least since the "ban peers if they send us garbage" denial-of-service mitigation code was pull-requested). This came up again with my proposed "smartfee" changes, which would drop low-priority or low-fee transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131026/eeabfe72/attachment.html>;

📅 Original date posted:2013-10-19 📝 Original message:On ...

2023-06-07T15:07:40Z

In reply to nevent1q…ay0x
_________________________

📅 Original date posted:2013-10-19
📝 Original message:On 2013-10-19, at 4:21 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:

> I submitted the proposal to the mailing list on July 19, 2003.

That would be 2013. sorry.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131019/9197f456/attachment.sig>;

📅 Original date posted:2013-10-21 📝 Original message:On ...

2023-06-07T15:07:39Z

In reply to nevent1q…mx3h
_________________________

📅 Original date posted:2013-10-21
📝 Original message:On 2013-10-21, at 2:44 AM, Arto Bendiken <arto at bendiken.net> wrote:

>
> Indeed. The BIP analogs that immediately come to mind would be the
> enhancement proposal processes for Python, XMPP, and BitTorrent:

Bitcoin's BIP process is directly based off of Python's PEP process.

Quote from BIP 1, History:

This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131021/327b7918/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131021/327b7918/attachment.sig>;

📅 Original date posted:2013-10-19 📝 Original message:I ...

2023-06-07T15:07:39Z

In reply to nevent1q…kze8
_________________________

📅 Original date posted:2013-10-19
📝 Original message:I submitted the proposal to the mailing list on July 19, 2003.

On 2013-10-19, at 3:29 PM, Luke-Jr <luke at dashjr.org> wrote:

> On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
>> I have a question regarding this part. I wrote a BIP for base 58 encoding /
>> encryption of BIP 32 root keys. The BIP page states that we shouldn't add
>> to this list ourselves, but should contact you for a BIP number. I have
>> contacted you a couple times on bitcointalk for a BIP number, but haven't
>> received a response (or do those requests explicitly have to go to your
>> email address)?
>
> See BIP 1 for the process.. proposals go to this mailing list first.
>
> Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131019/1a0c4767/attachment.sig>;

📅 Original date posted:2013-10-21 📝 Original message:How ...

2023-06-07T15:07:37Z

In reply to nevent1q…uahl
_________________________

📅 Original date posted:2013-10-21
📝 Original message:How about putting them into sub directories that map onto the status of the BIP?

Reading BIP 1, that would make:

Accepted
Active
Draft
Deferred
Final
Rejected
Replaced
Withdrawn

Would that place NODE_BLOOM and BIP 38 in Deferred?

On 2013-10-20, at 11:43 PM, Peter Todd <pete at petertodd.org> wrote:

> On Sun, Oct 20, 2013 at 11:40:26PM -0700, Jean-Paul Kogelman wrote:
>>
>> I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live?
>
> Sure, I think Jeff mentioned the idea of a specific drafts/ directory
> within the repository. (could also do a rejected/)
>
> Less of an issue in some ways when it's all in git - just point people
> to your bips fork.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000099eaa116fac83a2b0e097cae3391c794990e128c8e162d91a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131020/9af62985/attachment.sig>;

📅 Original date posted:2013-10-21 📝 Original message:I was ...

2023-06-07T15:07:37Z

In reply to nevent1q…jewm
_________________________

📅 Original date posted:2013-10-21
📝 Original message:I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live?

On 2013-10-20, at 11:25 PM, Peter Todd <pete at petertodd.org> wrote:

> On Sun, Oct 20, 2013 at 08:27:47PM -0400, Jeff Garzik wrote:
>> On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete at petertodd.org> wrote:
>>> FWIW I think that BIP's should have been done as a github repository,
>>> allowing for dealing with this stuff transparently as a pull-request.
>>> It'd also be useful to handle BIP's that way to make it easy to archive
>>> them, update them, and keep a log of what and why they were updated.
>>> Just put them in markdown format, which is pretty much feature
>>> equivalent to the wiki now that markdown supports images.
>>
>> Agreed -- let's do it. I nominate you to do the conversion, and we'll
>> put it up at github.com/bitcoin/bips.git.
>
> Done: https://github.com/petertodd/bips/
>
> GitHub supports MediaWiki these days, so just directly copying from
> 'View Source' in the bitcoin.it wiki worked pretty well; I archived the
> exact text of BIP. Tables, images and math is all supported by github
> and look fine, although github doesn't seem to support coloration in
> tables. Users wishing to edit their pull-req's or create new ones can do
> so easily by forking the repository - they can see their changes as they
> go in GitHub.
>
> I've probably missed some stuff re: formatting, and I haven't changed
> any of the submission guideline text in bip 1 yet, but that's probably
> 90% of the work done.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000245a735ccc14b98552e152f773c07efa2e89dd7f0463f61cf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131020/6a8548ee/attachment.sig>;

📅 Original date posted:2013-10-19 📝 Original ...

2023-06-07T15:07:36Z

In reply to nevent1q…q2sd
_________________________

📅 Original date posted:2013-10-19
📝 Original message:>> Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.
>
> Having it on the BIP page *does* make it more official, at least the way
> we've been using the BIP page, which is to filter out the proposals that
> haven't gotten much support at all. (or maybe are just controversial)

Interesting. The main reason I wrote my proposal was because the only proposal that came close to covering the same area was BIP 39, which at that time had 2 paragraphs of text (although admittedly did link to a text file off site where the draft was being developed). And currently there are 2 proposals that have numbers allocated but are empty (BIP 40 and 41) with no references to the development or discussion.

I appreciate the fact that acceptance of proposals on the BIP page are more strict, but it may be desirable to have the enforcement be more uniform. Also, BIP 38 is gaining more acceptance out in the community (many sites support the import of these keys and a growing number of paper wallet sites / coin / card vendors are offering it as an option), yet it's still missing from the BIP list, which seems to me a bit counter to the arguments given about community acceptance.

> FWIW I myself haven't pushed hard for getting an "official" BIP number
> for my draft NODE_BLOOM BIP, even though I've got support from most of
> the dev team on the pull-request:
> https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
> where I could get one assigned - Litecoin for instance has made that
> change - but really I just see that as a formality; that it's still a
> controversial idea is much more relevant.

> In any case I don't see any working code in your email, I'd suggest
> writing some. You're BIP would be much more likely to be accepted if you
> were more involved in wallet development.

Good point. I'm developing my own client (which has the code up and running, with unit tests), but I'm not ready to release it just yet until I've got all the client's alpha features working. Would putting contact information there so people can ask for the relevant code be sufficient until I have my client up on github?

jp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131019/237fe29a/attachment.sig>;

📅 Original date posted:2013-10-19 📝 Original message:On ...

2023-06-07T15:07:35Z

In reply to nevent1q…v6x6
_________________________

📅 Original date posted:2013-10-19
📝 Original message:On 2013-10-19, at 4:20 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke at dashjr.org> wrote:
>> See BIP 1 for the process.. proposals go to this mailing list first.
>
> FWIW, he did post to the mailing list and he got an underwhelming response:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development

Although I agree that the number of responses on the mailing list was minimal, they were overall positive. Mike voiced concerns about not having a date field to limit the rescan when importing, but other than that, most of the discussion was on bitcointalk. I've made a number of revisions, trying to incorporate the suggestions that were given. Obviously this doesn't mean that the draft is final (specifically the KDF's that can be used is still up for debate and having 29 undefined ID's means it's reasonably future proof).

Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.

jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131019/995fc3a3/attachment.sig>;

📅 Original date posted:2013-10-19 📝 Original message:On ...

2023-06-07T15:07:34Z

In reply to nevent1q…yvkd
_________________________

📅 Original date posted:2013-10-19
📝 Original message:On 2013-10-19, at 1:40 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> "I wasn't even allowed to edit the wiki"
>
> I'm confused about this, if he's referring to en.bitcoin.it. Editing
> it is open to anyone who is willing to pay the 0.01
> (https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
> a policy set by the bitcoin development community, though I'm not sure
> that its a terrible one. I've both paid it on behalf of other users
> and made edits on behalf of people who didn't want to go to it. At
> least relative to some policy which requires actual approval the
> payment antispam is at least open to anyone with Bitcoin.

I have a question regarding this part. I wrote a BIP for base 58 encoding / encryption of BIP 32 root keys. The BIP page states that we shouldn't add to this list ourselves, but should contact you for a BIP number. I have contacted you a couple times on bitcointalk for a BIP number, but haven't received a response (or do those requests explicitly have to go to your email address)?

Proposal in question: https://bitcointalk.org/index.php?topic=258678.0

Cheers,

jp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131019/198c2b9c/attachment.sig>;

📅 Original date posted:2013-07-22 📝 Original message:I ...

2023-06-07T15:04:53Z

In reply to nevent1q…j9we
_________________________

📅 Original date posted:2013-07-22
📝 Original message:I added a 2 byte 'weeks since 2013-01-01' field and updated the prefixes, ranges and test vectors.

The updated proposal lives here:
https://bitcointalk.org/index.php?topic=258678

Cheers,

jp

On Jul 22, 2013, at 06:14 AM, Mike Hearn <mike at plan99.net> wrote:

This isn't usable for SPV wallets unless it has a birthday in it. Otherwise you either need to scan the entire chain (slow) or find a fully indexed copy of the block chain (expensive, more centralised). Just add a UNIX time as an extra 4 bytes, or if you want to save a few characters then use a uint16 that represents "days since birth of this specification".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130722/c200153c/attachment.html>;

📅 Original date posted:2013-07-22 📝 Original message:Hi ...

2023-06-07T15:04:53Z

In reply to nevent1q…hsxj
_________________________

📅 Original date posted:2013-07-22
📝 Original message:Hi Mike,

I had a similar request on the forums. I suggested adding either a 2 byte 'weeks since genesis' or 'months since genesis', but starting from spec birth works too. Would either of those work for you?

jp

On Jul 22, 2013, at 6:14 AM, Mike Hearn <mike at plan99.net> wrote:

> This isn't usable for SPV wallets unless it has a birthday in it. Otherwise you either need to scan the entire chain (slow) or find a fully indexed copy of the block chain (expensive, more centralised). Just add a UNIX time as an extra 4 bytes, or if you want to save a few characters then use a uint16 that represents "days since birth of this specification".

📅 Original date posted:2013-07-19 📝 Original message:I do, ...

2023-06-07T15:04:52Z

In reply to nevent1q…ukf7
_________________________

📅 Original date posted:2013-07-19
📝 Original message:I do, but it's currently not in shippable form. Would the encoding / decoding functions suffice?

jp

On Jul 19, 2013, at 10:54 AM, "Andreas M. Antonopoulos" <andreas at rooteleven.com> wrote:

Jean-Paul,

Very interesting. I have a beta BIP0038 compliant paper wallet and I'm working on BIP0032 paper wallets at the moment.

This is definitely necessary and a great approach to combine BIP0038 and BIP0032.

Do you have reference code?

On Fri, Jul 19, 2013 at 10:46 AM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:

Hi everyone,

I'm looking for feedback on the proposal below.

Kind regards,

Jean-Paul

---
BIP:
Title: Base58 encoded HD Wallet master seed with optional encryption
Author: Jean-Paul Kogelman
Status: Draft
Type: Informational
Created: 17-07-2013

...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130719/efb998ec/attachment.html>;

📅 Original date posted:2013-07-19 📝 Original message:Hi ...

2023-06-07T15:04:52Z

In reply to nevent1q…4827
_________________________

📅 Original date posted:2013-07-19
📝 Original message:Hi Jeremy,

The main reason is to stick as close to BIP 0038 as possible, allowing implementers to reuse existing code paths. This proposal and BIP 0032 don't really put any restrictions on content of the seed itself (as can be seen in test vector 1).

jp

On Jul 19, 2013, at 11:09 AM, Jeremy Spilman <jeremy at taplink.co> wrote:

Very clear write-up Jean!

Quick question - what is the purpose of step 10 of the encryption process -- why XOR the master seed with some bytes of the hashed passphrase before encrypting the XOR'd master seed with the remaining bytes of the hashed passphrase? Versus simply encrypting the master seed with the hashed passphrase of equal length to the seed?

Does this basically serve the fucntion of an IV?

Do you really need this since the master seed must be high entropy random bytes in the first place?

Thanks,
--Jeremy

On Fri, 19 Jul 2013 10:46:44 -0700, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:

Hi everyone,

I'm looking for feedback on the proposal below.

Kind regards,

Jean-Paul

---
BIP:
Title: Base58 encoded HD Wallet master seed with optional encryption
Author: Jean-Paul Kogelman
Status: Draft
Type: Informational
Created: 17-07-2013

Abstract

This proposal describes a method for encoding and optionally encrypting a Bitcoin Hierarchical Deterministic (HD) Wallet master seed. Encoded master seeds are intended for use on paper wallets. Each string contains all the information needed to verify and reconstitute an HD wallet except for the optional passphrase. The encrypted version uses salting and scrypt to resist brute-force attacks.

The method provides two encoding methodologies in 3 lengths each (16, 32 and 64 byte seeds). One is a clear version of the master seed with verification information for integrity checking and the other is an encrypted representation.

A 32-bit hash of the resulting master Bitcoin public address is encoded in plain text within each seed record, so in the case of an encrypted seed, it can be correlated to a Bitcoin public address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin public address can be derived through successful decoding and optional decryption of the master seed record.

Motivation

The extended private keys proposed in BIP 0032 are long, fixed length records and don't offer any form of security. The master seed used to generate the HD wallet is typically shorter than the extended master private key that results from it.

A compact representation of the master seed is easier to handle and a 2-factor version of the master seed record allows for safe storage and the creation of paper wallets by 3rd parties.

Copyright

This proposal is hereby placed in the public domain.

Rationale

User story: As a Bitcoin user who uses HD wallets, I would like the ability to store my wallet master seed in a compact form as a paper wallet.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to have a 3rd party create a paper wallet with my master seed in it, without having access to the funds stored in the wallet.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to choose the strength of the master seed depending on my security requirements and how I wish to store it.

Specification

This proposal makes use of the following functions and definitions:

AES256Encrypt, AES256Decrypt: the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and a variable legth of input and deterministically yields output data of similar length to the input.

SHA256: a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.

RIPEMD160: a well known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 20-byte hash.

scrypt: A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.

HMAC-SHA512: Produces a 64 byte (512 bit) hash based message authentication code using the SHA512 hash function using a seed (in our case we will use a byte representation of "Bitcoin seed") and an aribtrary input message. The output will be 64 bytes.

Base58Check: a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

G, N: Constants defined as part of the secp256k1 elliptic curve. G is an elliptic curve point, and N is a large positive integer.

Prefix

It is proposed that the resulting Base58Check-encoded string start with either "WS" for clear master seed records or "ws" for 2-factor master seed records. The prefixes "WS" and "ws" were chosen as abreviations of the term "Wallet Seed" and upper case to indicate whether it's a clear representation and lower case when it's a 2-factor representation.

To keep the size of the encrypted key equal to the clear version, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin public address as salt.

Proposed specification

There are 2 seed record representations with 3 lengths each, resulting in a total of 6 different object identifier prefixes.

Prefix 0x1093: Clear 16 byte master seed, total length: 22 bytes
Prefix 0x1E68: Clear 32 byte master seed, total length: 38 bytes
Prefix 0x665A: Clear 64 byte master seed, total length: 70 bytes

Prefix 0x1EE4: 2-factor 16 byte master seed, total length: 22 bytes
Prefix 0x38AE: 2-factor 32 byte master seed, total length: 38 bytes
Prefix 0xBECB: 2-factor 64 byte master seed, total length: 70 bytes

These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.

How the user sees it: 35, 57 or 101 characters always starting with either "WS" or "ws".

Count of payload bytes (beyond prefix): 20, 36 or 68

Payload format:
4 bytes: SHA256(SHA256(master_bitcoin_public_address))[0...3], used both for typo checking and as salt.
16, 32 or 64 bytes: either a clear representation or an encrypted representation of the master seed.

Range in Base58Check encoding for clear 16 byte master seed (prefix WS):
Minimum value: WSJ5JnjiRZT8b15aZr6GGWzt2VMBPapmhBQ (based on 0x10 0x93 plus twenty 0x00's)
Maximum value: WShQumr1iGdbTpWiesWbb189p7rSLBiq3EJ (based on 0x10 0x93 plus twenty 0xFF's)

Range in Base58Check encoding for clear 32 byte master seed (prefix WS):
Minimum value: WS7SqjMWhDGCagcZxCk317LLWyWUny7465ENGKEKuxBf5sFvRHmRRfCgr (based on 0x1E 0x68 plus thirty-six 0x00's)
Maximum value: WSLAbo8WHEQr1Z1cv26Z5njh5URHMo9fPiDFYE2NpCwmAoPZwDxzm3PjB (based on 0x1E 0x68 plus thirty-six 0xFF's)

Range in Base58Check encoding for clear 64 byte master seed (prefix WS):
Minimum value: WS2cMzM9WrogWVLKYFzTaTXZnYCryY31uptmdevXuRFBXTWJhmt4No9Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1Mi85kadBD4TPsL (based on 0x66 0x5A plus sixty-eight 0x00's)
Maximum value: WS6PXJ1HoJXn9hyLz8uXQEy2ZajAVaFDTViXhZDthwYbhyvfHRqjwU4FoGpepCbuuycAwMFbgoZB6E48baqD1c9PdMNUZCSSBmfE7 (based on 0x66 0x5A plus sixty-eight 0xFF's)

Range in Base58Check encoding for 2-factor 16 byte master seed (prefix ws):
Minimum value: ws1nyTi9KjdRkJda4Yh1KkXSLC8SZ6kKzEM (based on 0x1E 0xE4 plus twenty 0x00's)
Maximum value: wsR8aSpScSotd84i9a7LeEei7pdhVkeciX8 (based on 0x1E 0xE4 plus twenty 0xFF's)

Range in Base58Check encoding for 2-factor 32 byte master seed (prefix ws):
Minimum value: wsC8sayZpTpeX3k6jcCMeTedDapXkXd7SZpRJbSjdeqKBJ2Vnrm1xyfD3 (based on 0x38 0xAE plus thirty-six 0x00's)
Maximum value: wsQrdekZQUyHwv99hRYsj93yn5jLKMfikCoJaWEnXubRGEA9Jnxg5KaPW (based on 0x38 0xAE plus thirty-six 0xFF's)

Range in Base58Check encoding for 2-factor 64 byte master seed (prefix ws):
Minimum value: ws4XTrriTEyyy2TrGWv9R7o94CyBiN69S2VxiK5tVW9htEi48w54sQ43JChCmadoGtYpZSu7vqbbQTMemCSyyToyLPPMjughcXNxE (based on 0xBE 0xCB plus sixty-eight 0x00's)
Maximum value: ws8JdAWrjgi5cF6siPqDEuEbqFVVEQJLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsDQ5ZjpcrMMuNu7nnHyJ5j9x1Fcg5iUwvZ7krH (based on 0xBE 0xCB plus sixty-eight 0xFF's)

Generation of master seed:

1. Take either an existing 16, 32 or 64 byte master seed S, or generate one from a (P)RNG.
2. Calculate I = HMAC-SHA512(key = "Bitcoin seed", msg = S)
3. Split I into two 32-byte sequences, IL and IR.
4. Use IL as master secret key. IR, the master chain code is not relevant here.
5. In case IL is 0 or >= N, the master key is invalid. Go back to step 1 if generating, or in case of a provided master seed, return an error.
6. Compute the public key K = IL*G
7. Calculate the master Bitcoin public address A = Base58Check(RIPEMD160(SHA256(K)))
8. Calculate the salt = SHA256(SHA256(A))[0...3]

Encryption:

9. Derive a hash H from the passphrase using scrypt
- Parameters: passphrase is the passphrase itself encoded in UTF-8, salt = salt, n = 16384, r = 8, p = 8, length = seed length + 32
10. The first number of bytes in H, equal to length of seed S are used to xor seed S. Call the result X.
11. Do AES256Encrypt(message = X, key = last 32 bytes of H), call this encrypted_seed.

The encrypted_master_seed is the Base58Check-encoded concatenation of the following, which totals 2 + 4 + seed length bytes (22, 38 or 70 bytes):

encrypted_master_seed = prefix + salt + encrypted_seed

The clear version is:

master_seed = prefix + salt + seed S

Decryption:

1. Collect encrypted_master_seed and passphrase from user.
2. Perform step 9 of encryption with the passphrase and the salt from the encrypted_master_seed.
3. With the encrypted_seed from encrypted_master_seed do AES256Decrypt(message = encrypted_seed, key = last 32 bytes of H), call this decrypted_seed.
4. With the first number of bytes in H, equal to the length of the decrypted_seed, perform the xor operation on decrypted_seed and call the result S.
5. Perform generation steps 2 until 8 and verify that the generated salt is equal to the salt from encrypted_master_seed.

Suggestions for implementers of proposal with alt-chains

This proposal involves hashing of a text representation of a public address which for Bitcoin includes the leading '1'. Alt-chains can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encoded master seeds do not start with "WS" or "ws".

Bitcoin testnet representation

This proposal does not cover separate Bitcoin testnet representations of encoded master seeds, although since the 4 salt bytes are based on a double SHA256 of the Bitcoin public address, they will be different for Bitcoin testnet public addresses and validation will fail.

Reference implementation

TODO

Test vectors

Test 1:

Seed : 000102030405060708090a0b0c0d0e0f
Clear : WSZsLQ5c1uKrRQugbrZNYsvMhRixiaWaVmJ
Password : Satoshi
Encrypted : wsHb15443fYPmneEXskd6wUZeP15fCiA69n
Address : 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma
xprv : xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
xpub : xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8

Test 2:

Seed : 7f0ad7d595be13e6fe4cf1fa0fbb6ae9c26c5d9b09920709414982b6363d5844
Clear : WSB7z3izBZwDoaAUA4mDpEHzAZsA5zfTWu3cCxhkaLtZ4Ur6n6mXsgpMK
Password : Nakamoto
Encrypted : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGpxuvgETRsv8J1wHNANJ
Address : 1A54ECavJaJAoLGqqNrPd9Y3cvSvkL2Roz
xprv : xprv9s21ZrQH143K3f9hMVvcbY4EX4CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAcL6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8bDr118t3
xpub : xpub661MyMwAqRbcG9EATXTcxfzy563ANKxjyK7fykABT1ooL5A6iQw4NukpHShDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgfkQvYBQPP

Test 3:

Seed : fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542
Clear : WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYmauV9X4W8tLJke1DH8UP8YMsDLdsjwgodcghjjKqkWQmk3t7qDbNMJVBDKcD2s
Password : Vires In Numeris
Encrypted : ws7vDy7RjqMvcPX7GeakKvdK6vDKGhRSjQtaRfKUVQrJXwwetLSeTdNgGzn5BKZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9UnQuwt
Address : 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg
xprv : xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
xpub : xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB

Test 4:

Seed : 6ca4a27ac660c683340f59353b1375a9
Clear : WSXnfK5CJbDoSwcqMfz7Xqy3avuPHSxDQQk
Password : 聡中本
Encrypted : wsFWKz3c5eeHRwtJveSdFvwUrmoNVkJ5ns2
Address : 1JVncPbsdB2s4zHim3VdAWNkZ8JANBZ1U9
xprv : xprv9s21ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8dq8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbgxw2QA
xpub : xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fchw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o

Acknowledgements

Mike Caldwell for BIP 0038, which this proposal borrows heavily from.

See Also

BIP 0032 Hierarchical Deterministic Wallets: https://en.bitcoin.it/wiki/BIP_0032
BIP 0038 Passphrase-protected private key: https://en.bitcoin.it/wiki/BIP_0038

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130719/22cd4c64/attachment.html>;

📅 Original date posted:2013-07-19 📝 Original message:Hi ...

2023-06-07T15:04:51Z

In reply to nevent1q…spe4
_________________________

📅 Original date posted:2013-07-19
📝 Original message:Hi everyone,

I'm looking for feedback on the proposal below.

Kind regards,

Jean-Paul

---
BIP:
Title: Base58 encoded HD Wallet master seed with optional encryption
Author: Jean-Paul Kogelman
Status: Draft
Type: Informational
Created: 17-07-2013

Abstract

This proposal describes a method for encoding and optionally encrypting a Bitcoin Hierarchical Deterministic (HD) Wallet master seed. Encoded master seeds are intended for use on paper wallets. Each string contains all the information needed to verify and reconstitute an HD wallet except for the optional passphrase. The encrypted version uses salting and scrypt to resist brute-force attacks.

The method provides two encoding methodologies in 3 lengths each (16, 32 and 64 byte seeds). One is a clear version of the master seed with verification information for integrity checking and the other is an encrypted representation.

A 32-bit hash of the resulting master Bitcoin public address is encoded in plain text within each seed record, so in the case of an encrypted seed, it can be correlated to a Bitcoin public address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin public address can be derived through successful decoding and optional decryption of the master seed record.

Motivation

The extended private keys proposed in BIP 0032 are long, fixed length records and don't offer any form of security. The master seed used to generate the HD wallet is typically shorter than the extended master private key that results from it.

A compact representation of the master seed is easier to handle and a 2-factor version of the master seed record allows for safe storage and the creation of paper wallets by 3rd parties.

Copyright

This proposal is hereby placed in the public domain.

Rationale

User story: As a Bitcoin user who uses HD wallets, I would like the ability to store my wallet master seed in a compact form as a paper wallet.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to have a 3rd party create a paper wallet with my master seed in it, without having access to the funds stored in the wallet.

User story: As a Bitcoin user who uses HD wallets, I would like the ability to choose the strength of the master seed depending on my security requirements and how I wish to store it.

Specification

This proposal makes use of the following functions and definitions:

AES256Encrypt, AES256Decrypt: the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and a variable legth of input and deterministically yields output data of similar length to the input.

SHA256: a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.

RIPEMD160: a well known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 20-byte hash.

scrypt: A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.

HMAC-SHA512: Produces a 64 byte (512 bit) hash based message authentication code using the SHA512 hash function using a seed (in our case we will use a byte representation of "Bitcoin seed") and an aribtrary input message. The output will be 64 bytes.

Base58Check: a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

G, N: Constants defined as part of the secp256k1 elliptic curve. G is an elliptic curve point, and N is a large positive integer.

Prefix

It is proposed that the resulting Base58Check-encoded string start with either "WS" for clear master seed records or "ws" for 2-factor master seed records. The prefixes "WS" and "ws" were chosen as abreviations of the term "Wallet Seed" and upper case to indicate whether it's a clear representation and lower case when it's a 2-factor representation.

To keep the size of the encrypted key equal to the clear version, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin public address as salt.

Proposed specification

There are 2 seed record representations with 3 lengths each, resulting in a total of 6 different object identifier prefixes.

Prefix 0x1093: Clear 16 byte master seed, total length: 22 bytes
Prefix 0x1E68: Clear 32 byte master seed, total length: 38 bytes
Prefix 0x665A: Clear 64 byte master seed, total length: 70 bytes

Prefix 0x1EE4: 2-factor 16 byte master seed, total length: 22 bytes
Prefix 0x38AE: 2-factor 32 byte master seed, total length: 38 bytes
Prefix 0xBECB: 2-factor 64 byte master seed, total length: 70 bytes

These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.

How the user sees it: 35, 57 or 101 characters always starting with either "WS" or "ws".

Count of payload bytes (beyond prefix): 20, 36 or 68

Payload format:
4 bytes: SHA256(SHA256(master_bitcoin_public_address))[0...3], used both for typo checking and as salt.
16, 32 or 64 bytes: either a clear representation or an encrypted representation of the master seed.

Range in Base58Check encoding for clear 16 byte master seed (prefix WS):
Minimum value: WSJ5JnjiRZT8b15aZr6GGWzt2VMBPapmhBQ (based on 0x10 0x93 plus twenty 0x00's)
Maximum value: WShQumr1iGdbTpWiesWbb189p7rSLBiq3EJ (based on 0x10 0x93 plus twenty 0xFF's)

Range in Base58Check encoding for clear 32 byte master seed (prefix WS):
Minimum value: WS7SqjMWhDGCagcZxCk317LLWyWUny7465ENGKEKuxBf5sFvRHmRRfCgr (based on 0x1E 0x68 plus thirty-six 0x00's)
Maximum value: WSLAbo8WHEQr1Z1cv26Z5njh5URHMo9fPiDFYE2NpCwmAoPZwDxzm3PjB (based on 0x1E 0x68 plus thirty-six 0xFF's)

Range in Base58Check encoding for clear 64 byte master seed (prefix WS):
Minimum value: WS2cMzM9WrogWVLKYFzTaTXZnYCryY31uptmdevXuRFBXTWJhmt4No9Eejoj3apqyU5RkyXsGHFPbZd14oz7Fv1Mi85kadBD4TPsL (based on 0x66 0x5A plus sixty-eight 0x00's)
Maximum value: WS6PXJ1HoJXn9hyLz8uXQEy2ZajAVaFDTViXhZDthwYbhyvfHRqjwU4FoGpepCbuuycAwMFbgoZB6E48baqD1c9PdMNUZCSSBmfE7 (based on 0x66 0x5A plus sixty-eight 0xFF's)

Range in Base58Check encoding for 2-factor 16 byte master seed (prefix ws):
Minimum value: ws1nyTi9KjdRkJda4Yh1KkXSLC8SZ6kKzEM (based on 0x1E 0xE4 plus twenty 0x00's)
Maximum value: wsR8aSpScSotd84i9a7LeEei7pdhVkeciX8 (based on 0x1E 0xE4 plus twenty 0xFF's)

Range in Base58Check encoding for 2-factor 32 byte master seed (prefix ws):
Minimum value: wsC8sayZpTpeX3k6jcCMeTedDapXkXd7SZpRJbSjdeqKBJ2Vnrm1xyfD3 (based on 0x38 0xAE plus thirty-six 0x00's)
Maximum value: wsQrdekZQUyHwv99hRYsj93yn5jLKMfikCoJaWEnXubRGEA9Jnxg5KaPW (based on 0x38 0xAE plus thirty-six 0xFF's)

Range in Base58Check encoding for 2-factor 64 byte master seed (prefix ws):
Minimum value: ws4XTrriTEyyy2TrGWv9R7o94CyBiN69S2VxiK5tVW9htEi48w54sQ43JChCmadoGtYpZSu7vqbbQTMemCSyyToyLPPMjughcXNxE (based on 0xBE 0xCB plus sixty-eight 0x00's)
Maximum value: ws8JdAWrjgi5cF6siPqDEuEbqFVVEQJLyhKinDPFJ2T84m8Qib2kS4y4Sji8YCQsDQ5ZjpcrMMuNu7nnHyJ5j9x1Fcg5iUwvZ7krH (based on 0xBE 0xCB plus sixty-eight 0xFF's)

Generation of master seed:

1. Take either an existing 16, 32 or 64 byte master seed S, or generate one from a (P)RNG.
2. Calculate I = HMAC-SHA512(key = "Bitcoin seed", msg = S)
3. Split I into two 32-byte sequences, IL and IR.
4. Use IL as master secret key. IR, the master chain code is not relevant here.
5. In case IL is 0 or >= N, the master key is invalid. Go back to step 1 if generating, or in case of a provided master seed, return an error.
6. Compute the public key K = IL*G
7. Calculate the master Bitcoin public address A = Base58Check(RIPEMD160(SHA256(K)))
8. Calculate the salt = SHA256(SHA256(A))[0...3]

Encryption:

9. Derive a hash H from the passphrase using scrypt
- Parameters: passphrase is the passphrase itself encoded in UTF-8, salt = salt, n = 16384, r = 8, p = 8, length = seed length + 32
10. The first number of bytes in H, equal to length of seed S are used to xor seed S. Call the result X.
11. Do AES256Encrypt(message = X, key = last 32 bytes of H), call this encrypted_seed.

The encrypted_master_seed is the Base58Check-encoded concatenation of the following, which totals 2 + 4 + seed length bytes (22, 38 or 70 bytes):

encrypted_master_seed = prefix + salt + encrypted_seed

The clear version is:

master_seed = prefix + salt + seed S

Decryption:

1. Collect encrypted_master_seed and passphrase from user.
2. Perform step 9 of encryption with the passphrase and the salt from the encrypted_master_seed.
3. With the encrypted_seed from encrypted_master_seed do AES256Decrypt(message = encrypted_seed, key = last 32 bytes of H), call this decrypted_seed.
4. With the first number of bytes in H, equal to the length of the decrypted_seed, perform the xor operation on decrypted_seed and call the result S.
5. Perform generation steps 2 until 8 and verify that the generated salt is equal to the salt from encrypted_master_seed.

Suggestions for implementers of proposal with alt-chains

This proposal involves hashing of a text representation of a public address which for Bitcoin includes the leading '1'. Alt-chains can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encoded master seeds do not start with "WS" or "ws".

Bitcoin testnet representation

This proposal does not cover separate Bitcoin testnet representations of encoded master seeds, although since the 4 salt bytes are based on a double SHA256 of the Bitcoin public address, they will be different for Bitcoin testnet public addresses and validation will fail.

Reference implementation

TODO

Test vectors

Test 1:

Seed : 000102030405060708090a0b0c0d0e0f
Clear : WSZsLQ5c1uKrRQugbrZNYsvMhRixiaWaVmJ
Password : Satoshi
Encrypted : wsHb15443fYPmneEXskd6wUZeP15fCiA69n
Address : 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma
xprv : xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
xpub : xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8

Test 2:

Seed : 7f0ad7d595be13e6fe4cf1fa0fbb6ae9c26c5d9b09920709414982b6363d5844
Clear : WSB7z3izBZwDoaAUA4mDpEHzAZsA5zfTWu3cCxhkaLtZ4Ur6n6mXsgpMK
Password : Nakamoto
Encrypted : wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGpxuvgETRsv8J1wHNANJ
Address : 1A54ECavJaJAoLGqqNrPd9Y3cvSvkL2Roz
xprv : xprv9s21ZrQH143K3f9hMVvcbY4EX4CfxsEtc6C5BMkZtgGpTGpxAscoq7SLSAcL6k5dxaZ9s4SChrtfSFoKpijuwAnhuPn76eva6W8bDr118t3
xpub : xpub661MyMwAqRbcG9EATXTcxfzy563ANKxjyK7fykABT1ooL5A6iQw4NukpHShDxYgeso4NHscFmqcVEtdUt61c8RCf7FqXK9z6sgfkQvYBQPP

Test 3:

Seed : fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542
Clear : WS6186bsAkSaGRjRZ1UGyCGigxsXPvnYGSqNHJYmauV9X4W8tLJke1DH8UP8YMsDLdsjwgodcghjjKqkWQmk3t7qDbNMJVBDKcD2s
Password : Vires In Numeris
Encrypted : ws7vDy7RjqMvcPX7GeakKvdK6vDKGhRSjQtaRfKUVQrJXwwetLSeTdNgGzn5BKZZqz1BBdaHBFYfLvNUSxDaoP1ojJMMJD9UnQuwt
Address : 1JEoxevbLLG8cVqeoGKQiAwoWbNYSUyYjg
xprv : xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
xpub : xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB

Test 4:

Seed : 6ca4a27ac660c683340f59353b1375a9
Clear : WSXnfK5CJbDoSwcqMfz7Xqy3avuPHSxDQQk
Password : 聡中本
Encrypted : wsFWKz3c5eeHRwtJveSdFvwUrmoNVkJ5ns2
Address : 1JVncPbsdB2s4zHim3VdAWNkZ8JANBZ1U9
xprv : xprv9s21ZrQH143K3mJ4upPSDfXdA34yNjem6PSsXT63vm8dq8ikUJv4iiTD3PrSKtdGZXFVD689z5T7knXo55BjcHS2WL3Syp2DbGgnbgxw2QA
xpub : xpub661MyMwAqRbcGFNY1qvSaoUMi4uTnCNcTcNUKqVfV6fchw3u1rEKGWmgtfUMRKLgUHNZ7dfsh8Ys6SLwUojZqScFBQL3dFGF3QywNLJVZ2o

Acknowledgements

Mike Caldwell for BIP 0038, which this proposal borrows heavily from.

See Also

BIP 0032 Hierarchical Deterministic Wallets: https://en.bitcoin.it/wiki/BIP_0032
BIP 0038 Passphrase-protected private key: https://en.bitcoin.it/wiki/BIP_0038

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130719/eb2ecd1f/attachment.html>;