Jean-Paul Kogelman [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-07-19 to 2017-09-27
💬 Posted a total of 51 messages
📚 Participated in the following categories: Bitcoin-development, RFC, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304

Profile Code

nprofile1qqsgwnayf5gskggeyz96d7e8vpmenut2qryzzseqrttlz7dgnuxlxjgkvedaw

Author Public Key

npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304

Show more details

Last Notes

2023-06-07 18:06:31

- reply

📅 Original date posted:2017-09-27
📝 Original message:Perhaps having authors consent to certain types of changes when they submit their BIP?
> On Sep 27, 2017, at 1:20 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> Op 27 sep. 2017, om 22:01 heeft Bryan Bishop via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>>
>>> On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> What do people think about modifying BIP 2 to allow editors to merge these
>>> kinds of changes without involving the Authors? Strictly speaking, BIP 2
>>> shouldn't be changed now that it is Active, but for such a minor revision, I
>>> think an exception is reasonable.
>>
>> Even minor revisions can not change the meaning of text. Changing a single word can often have a strange impact on the meaning of the text. There should be some amount of care exercised here. Maybe it would be okay as long as edits are mentioned in the changelog at the bottom of each document, or mention that the primary authors have not reviewed suggested changes, or something as much; otherwise the reader might not be aware to check revision history to see what's going on.
>
> Perhaps it's enough to @mention authors in the PR and give them a week to object before merging?
>
> Sjors
> _______________________________________________
> 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/20170927/b5952838/attachment.html>

2023-06-07 18:01:50

- reply

📅 Original date posted:2017-05-30
📝 Original message:That would invalidate any pre-signed transactions that are currently out there. You can't just change the rules out from under people.
> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> The 1MB classic block size prevents quadratic hashing
>> problems from being any worse than they are today.
>>
>
> Add a transaction-size limit of, say, 10kb and the quadratic hashing problem is a non-issue. Donezo.
> _______________________________________________
> 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/20170530/aa4c361d/attachment.html>

2023-06-07 17:58:59

- reply

📅 Original date posted:2017-04-04
📝 Original message:Tom,
It's clear that you have some rather large gaps in your knowledge of Bitcoin, its rules, implementation and game theory. I highly encourage you spend some time learning more about these things before continuing posting here.
https://www.reddit.com/r/BitcoinBeginners/ is a good place to start. It's a safe place where you can ask any question you want without fear of being laughed at.
Kind regards,
Jean-Paul
> On Apr 4, 2017, at 8:44 AM, Greg Sanders via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> That's BIP30, he linked BIP34: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004
>
>> On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Can you tell me where it is enforced?
>>
>> The only place I found was here;
>> https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793
>>
>> which doesn’t enforce it, all that code does is check that the txid is
>> unknown or fully spent.
>> And since the below idea from Russel would change the txid, it would seem no
>> full client would reject this.
>>
>> Maybe its in a BIP, but I can’t find it in the code.
>>
>> On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote:
>> > It is a consensus rule
>> > https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
>> >
>> > On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
>> >
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
>> > >
>> > > wrote:
>> > >> Someone told me a while back that it would be more natural if we move
>> > >> the
>> > >>
>> > >> nHeight from the coinbase script to the coinbase locktime. Have you
>> > >> considered doing this?
>> > >
>> > > That change would not be a consensus change and thus free to make any
>> > > day.
>>
>>
>> --
>> Tom Zander
>> Blog: https://zander.github.io
>> Vlog: https://vimeo.com/channels/tomscryptochannel
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> 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/20170404/d77e03fd/attachment.html>

2023-06-07 17:34:48

- reply

📅 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>

2023-06-07 15:46:42

- reply

2023-06-07 15:44:11

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On Jul 29, 2015, at 8:41 PM, Ryan Butler via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Does an unlimited blocksize imply the lack of a fee market? Isn't every miner able to set their minimum accepted fee or transaction acceptance algorithm?
>
Yes, miners can set this, and giving them more fine grained control over this (with sane defaults) will have a far bigger impact on establishing a proper fee market than depending on capacity (that nobody has any control over).
Allowing miners to set up some sort of tiered offering that delays transactions and maybe even have their tiers tie into the exchange rate to keep the costs constant over time.
I'm sure something like this has probably already been discussed before and I'm curious what the objections are to such a thing?
jp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/cb662375/attachment.html>

2023-06-07 15:43:55

- reply

📅 Original date posted:2015-07-31
📝 Original message:Forgot to include the list.
> From: Jean-Paul Kogelman <jeanpaulkogelman at me.com>
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón <jtimon at jtimon.cc>
> Cc: milly at bitcoins.info
> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
>
>
> I wrote about this a earlier this month: http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00383.html
>
> You basically want 3 things:
>
> - A Minimum Specification of hardware: This is the lowest hardware configuration Bitcoin Core will run on at maximum capacity.
> - A theoretical model that takes into account all of the components in Bitcoin Core and how they affect Min Spec.
> - A benchmark tool to measure how changes affect Min Spec (and for users to see how their hardware measures up to Min Spec).
>
> jp
>
>> On Jul 31, 2015, at 02:31 PM, Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>
>> On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> These are the types of things I have been discussing in relation to a
>>> process:
>>>
>>> -A list of metrics
>>> -A Risk analysis of the baseline system. Bitcoin as it is now.
>>> -Mitigation strategies for each risk.
>>> -A set of goals.
>>> -A Road map for each goal that lists the changes or possible avenues to
>>> achieve that goal.
>>>
>>> Proposed changes would be measured against the same metrics and a risk
>>> analysis done so it can be compared with the baseline.
>>>
>>> For example, the block size debate would be discussed in the context of a
>>> road map related to a goal of increase scaling. One of the metrics would be
>>> a decentralization metric. (A framework for a decentralization metric is at
>>> http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
>>> Cost would be one aspect of the decentralization metric.
>>
>> All this sounds very reasonable and useful.
>> And if a formal organization owns this "process", that's fine as well.
>> I still think hardforks need to be uncontroversial (using the vague "I
>> will know it when I see it" defintion) and no individual or
>> organization can be an "ultimate decider" or otherwise Bitcoin losses
>> all it's p2p nature (and this seems the point where you, Milly, and I
>> disagree).
>> But metrics and data tend to help when it comes to "I will know it
>> when I see it" and "evidences".
>> So, yes, by all means, let's have an imperfect decentralization metric
>> rather than not having anything to compare proposals. Competing
>> decentralization metrics can appear later: we need a first one first.
>> I would add that we should have sets of simulations being used to
>> calculate some of those metrics, but maybe I'm just going too deep
>> into details.
>> _______________________________________________
>> 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/20150731/b2113cb4/attachment-0001.html>

2023-06-07 15:43:41

- reply

📅 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

2023-06-07 15:43:00

- reply

📅 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.

2023-06-07 15:42:59

- reply

📅 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
>

2023-06-07 15:42:58

- reply

📅 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-----
>

2023-06-07 15:42:58

- reply

📅 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
>

2023-06-07 15:42:57

- reply

📅 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.

2023-06-07 15:42:57

- reply

📅 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

2023-06-07 15:42:56

- reply

📅 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>

2023-06-07 15:41:31

- reply

📅 Original date posted:2015-07-03
📝 Original message:I get it. :) Being able to run Bitcoin Core on open hardware is a noble (and important) goal! I hope that once we’ve figured out what the current requirements are that we can adjust these requirements (if needed) to include certain open hardware platforms. But that’s the next step. Bitcoin Core is a project in flight. Let’s first see where we’re at.
What are the critical wall-time requirements? As discussed earlier, the block propagation times are very important to keep orphan rates low. This sounds like one of the inputs that can be used to model bandwidth and CPU requirements. Other inputs for this could be as simple as the minimum number of connected nodes (multiplier on outbound bandwidth, but not CPU), etc. It wouldn’t surprise me if many of the real world requirements will center around Bitcoin Core’s ability to talk to the outside world.
jp
> On Jul 2, 2015, at 10:33 PM, Jeremy Rubin <jeremy.l.rubin.travel at gmail.com> wrote:
>
> Jean-Paul,
>
> I think you're missing what I'm saying -- the point of my suggestion to make Rocket a min-spec is more along the lines of saying that the Rocket serves as a fixed point, Bitcoin Core performance must be acceptable on that platform, however it can be lower. Yes there are conversion factors and different architectures will perform differently. However, there still must be some baseline, a point at which we can say processors below it no longer are supported. I am saying that line should never be set so high as to exclude presently available open hardware.
>
> Ultimately, this ends up making an odd, but nice, goal for Bitcoin development. If Bitcoin Core needs more MIPS, the community must ensure the availability of open hardware that it can run on.
>
> Jeff,
>
> Moxie looks fantastic! The reason I thought RISC-V was a good selection is the very active development community which is pushing the performance of the ISA implementations forward. Can you speak to the health of Moxie development? Ultimately, ensuring support for many open architectures would be preferable. Are there other reasonable open-source processors that you are aware of?
>
> I would be willing to work on a design a Bitcoin specific open-hardware processor, up to the FPGA bound, if this would be useful for this goal.
>
> On Fri, Jul 3, 2015 at 12:19 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>> wrote:
> Ideally, the metrics that we settle on would be architecture agnostic and have some sort of conversion metric to map it onto any specific architecture. An Intel based architecture is going to perform vastly different from an ARM based one for example.
>
> Simple example: The PS3 PPE and Xbox 360 CPU are RISC processors that run at 3.2GHz, but their non-vector performance is rather poor. You’d be lucky to get about 33% effective utilization out of them (up to 50%, tops, but that’s really pushing it), so if you were to map this onto another architecture, you’d have at least a 3x conversion from this end alone (the other end could also have a scaling factor).
>
> Ultimately, how these values are expressed isn’t the important part. It’s the ability to measure the impact of a change that’s important. If some metric changes by, say, 5%, then it doesn’t really matter if it’s expressed in MIPS, INTOPS, MB or GB. The fact that it changed is what matters and what the effect is on the baseline (that ultimately could be expressed as a certain specific hardware configuration). It would probably be practical to have a number of comparable concrete min spec configurations and even more ideal would be if people in the community would have these systems up and running to do actual on-target performance benchmarks.
>
>
> jp
>
>
>> On Jul 2, 2015, at 8:13 PM, Jeremy Rubin <jeremy.l.rubin.travel at gmail.com <mailto:jeremy.l.rubin.travel at gmail.com>> wrote:
>>
>> Might I suggest that the min-spec, if developed, target the RISC-V Rocket architecture (running on FPGA, I suppose) as a reference point for performance? This may be much lower performance than desirable, however, it means that we don't lock people into using large-vendor chipsets which have unknown, or known to be bad, security properties such as Intel AMT.
>>
>> In general, targeting open hardware seems to me to be more critical than performance metrics for the long term health of Bitcoin, however, performance is still important.
>>
>> Does anyone know how the RISC-V FPGA performance stacks up to, say, a Raspberry Pi?
>>
>> On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <ogunden at phauna.org <mailto:ogunden at phauna.org>> wrote:
>> I'm also a user who runs a full node, and I also like this idea. I think Gavin has done some back-of-the-envelope calculations around this stuff, but nothing so clearly defined as what you propose.
>>
>> On 07/02/2015 08:33 AM, Mistr Bigs wrote:
>> I'm an end user running a full node on an aging laptop.
>> I think this is a great suggestion! I'd love to know what system
>> requirements are needed for running Bitcoin Core.
>>
>> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
>> <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com> <mailto:jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>>> wrote:
>>
>> I’m a game developer. I write time critical code for a living and
>> have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
>> These budgets are based on what we call a minimum specification (of
>> hardware); min spec for short. In most cases the min spec is based
>> on entry model machines that are available during launch, and will
>> give the user an enjoyable experience when playing our games.
>> Obviously, we can turn on a number of bells and whistles for people
>> with faster machines, but that’s not the point of this mail.
>>
>> The point is, can we define a min spec for Bitcoin Core? The number
>> one reason for this is: if you know how your changes affect your
>> available budgets, then the risk of breaking something due to
>> capacity problems is reduced to practically zero.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150702/e7e20133/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/20150702/e7e20133/attachment.sig>

2023-06-07 15:41:30

- reply

📅 Original date posted:2015-07-03
📝 Original message:Ideally, the metrics that we settle on would be architecture agnostic and have some sort of conversion metric to map it onto any specific architecture. An Intel based architecture is going to perform vastly different from an ARM based one for example.
Simple example: The PS3 PPE and Xbox 360 CPU are RISC processors that run at 3.2GHz, but their non-vector performance is rather poor. You’d be lucky to get about 33% effective utilization out of them (up to 50%, tops, but that’s really pushing it), so if you were to map this onto another architecture, you’d have at least a 3x conversion from this end alone (the other end could also have a scaling factor).
Ultimately, how these values are expressed isn’t the important part. It’s the ability to measure the impact of a change that’s important. If some metric changes by, say, 5%, then it doesn’t really matter if it’s expressed in MIPS, INTOPS, MB or GB. The fact that it changed is what matters and what the effect is on the baseline (that ultimately could be expressed as a certain specific hardware configuration). It would probably be practical to have a number of comparable concrete min spec configurations and even more ideal would be if people in the community would have these systems up and running to do actual on-target performance benchmarks.
jp
> On Jul 2, 2015, at 8:13 PM, Jeremy Rubin <jeremy.l.rubin.travel at gmail.com> wrote:
>
> Might I suggest that the min-spec, if developed, target the RISC-V Rocket architecture (running on FPGA, I suppose) as a reference point for performance? This may be much lower performance than desirable, however, it means that we don't lock people into using large-vendor chipsets which have unknown, or known to be bad, security properties such as Intel AMT.
>
> In general, targeting open hardware seems to me to be more critical than performance metrics for the long term health of Bitcoin, however, performance is still important.
>
> Does anyone know how the RISC-V FPGA performance stacks up to, say, a Raspberry Pi?
>
> On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <ogunden at phauna.org <mailto:ogunden at phauna.org>> wrote:
> I'm also a user who runs a full node, and I also like this idea. I think Gavin has done some back-of-the-envelope calculations around this stuff, but nothing so clearly defined as what you propose.
>
> On 07/02/2015 08:33 AM, Mistr Bigs wrote:
> I'm an end user running a full node on an aging laptop.
> I think this is a great suggestion! I'd love to know what system
> requirements are needed for running Bitcoin Core.
>
> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
> <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com> <mailto:jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>>> wrote:
>
> I’m a game developer. I write time critical code for a living and
> have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
> These budgets are based on what we call a minimum specification (of
> hardware); min spec for short. In most cases the min spec is based
> on entry model machines that are available during launch, and will
> give the user an enjoyable experience when playing our games.
> Obviously, we can turn on a number of bells and whistles for people
> with faster machines, but that’s not the point of this mail.
>
> The point is, can we define a min spec for Bitcoin Core? The number
> one reason for this is: if you know how your changes affect your
> available budgets, then the risk of breaking something due to
> capacity problems is reduced to practically zero.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
> _______________________________________________
> 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/20150702/348ca562/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/20150702/348ca562/attachment.sig>

2023-06-07 15:41:28

- reply

📅 Original date posted:2015-07-02
📝 Original message:In the case of Bitcoin Core, for a starting point, you basically have to work backwards from what we have right now. We know some of the bounds already. Block size already tells you a lot about your bandwidth requirements, and Pieter’s simulations gives you even more information when you take orphan rates into account. There’s also a hard cap on the number of SigOps if I recall correctly, so that’s probably a good starting point for a MIPS metric, etc.
Memory is probably the hardest to pin down since some memory structures like (from what I understand, correct me if I’m wrong) the UTXO database live fully in memory and are basically unbounded. Perhaps this can somehow be capped at a certain size and move all the really old UTXO’s that are unlikely to move to disk and just take the CPU / disk hit in the unlikely event that they are referenced by a new block. Has the address database been capped yet? Mempool? I realize that it’s probably debatable whether or not this behaviour should be independent of available memory since any bugs here could affect consensus (especially the UTXO db).
Ultimately, what comes out of it is a list of numbers. A Mbit network I/O, B MIPS, C MB memory, D Disk space, etc. At that point you can debate whether or not such a machine can be considered an entrypoint bitcoin full node. You round up the numbers that are not really available anymore in off the shelf hardware (like disk space) and you round down the numbers that seem too high. For all we know we’re already over budget on some of the metrics that we decide to track as min spec. Network I/O for example. At that point you can start focussed research into bringing Bitcoin Core back into budget on those metrics. Then the discussion moves from “it’s probably too high” to “we’re X% over budget”.
The most valuable thing that could come out of this is to get some kind of formulation how all the different levers in Bitcoin Core affect the min spec and ideally have a benchmark tool. For example, we could settle on a min spec that would exclude the Raspberry Pi 1 on MIPS, but when secp256k1 is enabled for validation, the MIPS requirement could drop significantly, allowing us to adjust the min spec downward to include the Raspberry Pi 1 again (again, just an example).
Ideally some people would have the actual min spec machine built and running. The cost of that shouldn’t be too high (it’s the min spec after all) and I’m sure people would be happy to chip in a couple bits for this.
Remember, the min spec should be able to handle Bitcoin Core running under full load; that’s maxed out blocks with maxed out SigOps, etc.
jp
> On Jul 2, 2015, at 12:18 AM, Henning Kopp <henning.kopp at uni-ulm.de> wrote:
>
> Hi Jean-Paul,
>
> that's a very interesting point of view and I have never thought about
> it this way, since I have a totally different background.
>
> How would you go on about defining a min spec? Is this done by testing
> the software on different hardware configurations or are you looking
> at the requirements a priori?
>
> Best regards
> Henning
>
>
> On Wed, Jul 01, 2015 at 09:04:19PM -0700, Jean-Paul Kogelman wrote:
>> Hi folks,
>>
>> I’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail.
>>
>> The point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero.
>>
>> One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
>>
>> So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
>>
>> For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
>>
>> Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
>>
>> Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
>>
>> Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
>>
>> What do you guys think?
>>
>>
>> jp
>
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
-------------- 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/20150702/25b86f6a/attachment.sig>

2023-06-07 15:41:27

- reply

📅 Original date posted:2015-07-02
📝 Original message:Hi folks,
I’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail.
The point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero.
One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
What do you guys think?
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/20150701/172ef784/attachment.sig>

2023-06-07 15:39:53

- reply

📅 Original date posted:2015-06-22
📝 Original message:On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
Since it's possible that block timestamps aren't chronological in order, what would happen if a block following a size increase trigger is back in the past before the size increase? Would that block have a lower size restriction again? Would using block height not be a more stable number to work with?
jp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/2b279abf/attachment.html>

2023-06-07 15:32:19

- reply

📅 Original date posted:2015-04-07
📝 Original message:Ok, false alarm. :)
Sorry for the spam.
On Apr 07, 2015, at 02:37 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
<jeanpaulkogelman at me.com> wrote:
https://eprint.iacr.org/2015/310.pdf
http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150407/40e2d52d/attachment.html>

2023-06-07 15:32:18

- reply

📅 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>

2023-06-07 15:27:32

- reply

📅 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>

2023-06-07 15:17:43

- reply

📅 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

2023-06-07 15:15:17

- reply

📅 Original date posted:2014-03-12
📝 Original message:On Mar 12, 2014, at 01:24 PM, Pavol Rusnak <stick at gk2.sk> wrote:
On 03/12/2014 09:10 PM, William Yager wrote:
implement this is to allow semi-trusted devices (like desktop PCs) to do
all the "heavy lifting". The way the spec is defined, it is easy to have a
more powerful device do all the tough key stretching work without
significantly compromising the security of the wallet.
By disclosing "preH" to compromised computer (between steps 4 and 5) you
make further steps 5-9 quite less important.
Agreed, this is a valid concern. This could possibly allow a 3rd party to crack the password, but then again, they would not gain access to any key material. So yes, you could expose your password, but your key would still be safe.
If people feel strongly about this vulnerability, we can revisit step 4 and adjust it to make password recovery more expensive.
jp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/d6e4f9ca/attachment.html>

2023-06-07 15:15:15

- reply

📅 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>

2023-06-07 15:15:14

- reply

📅 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>

2023-06-07 15:15:13

- reply

📅 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>

2023-06-07 15:15:12

- reply

📅 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>

2023-06-07 15:14:57

- reply

📅 Original date posted:2014-03-10
📝 Original message:Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less.
I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved.
jp
On Mar 10, 2014, at 9:04 AM, Mike Hearn <mike at plan99.net> wrote:
>> I just did my first contactless nfc payment with a MasterCard. It worked very well and was quite delightful - definitely want to be doing more of these in future.
>
> A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage.
>
> By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they:
>
> a) Reject cards entirely because the payment is too small
> b) Don't have the right hardware, or the hardware just mysteriously fails to work.
> c) Require a PIN because the payment is too large
>
> I'm sure Bitcoin can do better than this.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/936d80e9/attachment.html>

2023-06-07 15:14:41

- reply

📅 Original date posted:2014-03-05
📝 Original message:> On Mar 5, 2014, at 8:56 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
>> On Wed, Mar 5, 2014 at 1:49 PM, Mike Hearn <mike at plan99.net> wrote:
>> I am not currently aware of any efforts to make OpenSSL's secp256k1
>> implementation completely side channel free in all aspects. Also,
>> unfortunately many people have reimplemented ECDSA themselves and even if
>> OpenSSL gets fixed, the custom implementations probably won't.
>
> As far as I know, judging from the implementation, there is hardly any
> effort to try to prevent timing attacks.
>
Is it safe to assume that this is also true for your secp256k1 implementation?
jp
> --
> Pieter
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:11:13

- reply

📅 Original date posted:2013-12-29
📝 Original message:Hi all,
We've been having a heated discussion on HD wallet import strategies on bitcointalk and I was wondering what the people on bitcoin-dev had to say about the subject.
So I have a few questions and would love to hear your thoughts on them:
1) What information do you consider absolutely essential when importing an HD wallet root key?
2) If you already have an HD wallet import function, can you give a rough description of how it works?
3) Do you think it would be wise to set up some sort of guidelines to ensure that different HD wallet implementations will be able to import each others HD wallet root keys?
4) Anything else on the subject you consider important?
Thanks in advance,
Jean-Paul
-------------- 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/20131229/248a1049/attachment.sig>

2023-06-07 15:11:07

- reply

📅 Original date posted:2013-12-26
📝 Original message:Merry Christmas everyone!
I've updated the proposal.
I've changed the checksum to be a double SHA256 of the private key instead of the public address string and I've added support for 3rd party KDF computation.
The full proposal with updated test vectors lives here:
https://bitcointalk.org/index.php?topic=258678
Cheers,
Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131226/59f93b93/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/20131226/59f93b93/attachment.sig>

2023-06-07 15:09:45

- reply

📅 Original date posted:2013-11-16
📝 Original message:I've made no changes since the last time I've mentioned it here on the list (when the BIP procedures were being discussed).
The last changes are:
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.
The biggest difference between this proposal and BIP38 is that BIP38 allows a 3rd party to generate the encrypted private key + confirmation code from a passphrase code. Since this proposal is about encrypting a random value that's fed into HMAC-SHA512 and the presence of a partial hash of the root address, that's not possible.
>> https://bitcointalk.org/index.php?topic=258678
>
> Greetings. Any recent progress on this?
>
> Do we believe this proposal can replace BIP38? If not, what are the
> limitations that would prevent it from doing so?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131115/4376a583/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/20131115/4376a583/attachment.sig>

2023-06-07 15:09:36

- reply

📅 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>

2023-06-07 15:08:08

- reply

📅 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>

2023-06-07 15:07:44

- reply

📅 Original date posted:2013-10-22
📝 Original message:> I wanted to have a look at how the whole Bitcoin thing works recently.
> Being a distributed application, I've searched for the protocol spec.
> What I found were two wiki pages (Protocol & ProtocolRules) that looked
> more like notes someone wrote down while implementing the application.
>
> Have I missed something? Is there any effort underway trying to produce
> a decent spec? If not so, I am willing to help with that.
Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ?
-------------- 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/507d8f63/attachment.sig>

2023-06-07 15:07:42

- reply

📅 Original date posted:2013-10-21
📝 Original message:I have some more questions.
1) Should the protocol specification page also be codified into BIP(s)?
2) Should the current wiki pages be taken down / forwarded to the git repo or be auto updated from the git repo?
3) Even though the information in BIP 50 is valuable, should it really be considered a BIP?
On Oct 21, 2013, at 10:17 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
The goal is to improve the process, hash-seal our specs, and create an
easy way for anyone with at least an email address to participate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131021/da1da444/attachment.html>

2023-06-07 15:07:40

- reply

📅 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>

2023-06-07 15:07:40

- reply

📅 Original date posted:2013-10-21
📝 Original message:The list comes from BIP 1.
On 2013-10-21, at 12:03 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> On 21/10/13 08:52, Jean-Paul Kogelman wrote:
>> 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
>
> Have it been considered to do this via IETF? The process there is hardened by 40 years of experience and 7000+ RFCs. Probably better than anything you can devise yourself.
>
> Martin
-------------- 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/bce168ec/attachment.sig>

2023-06-07 15:07:39

- reply

📅 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>

2023-06-07 15:07:39

- reply

📅 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>

2023-06-07 15:07:37

- reply

📅 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>

2023-06-07 15:07:37

- reply

📅 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>

2023-06-07 15:07:36

- reply

📅 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>

2023-06-07 15:07:35

- reply

📅 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>

2023-06-07 15:07:34

- reply

📅 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>

2023-06-07 15:04:53

- reply

📅 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>

2023-06-07 15:04:53

- reply

📅 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".

2023-06-07 15:04:52

- reply

📅 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>

2023-06-07 15:04:52

- reply

📅 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>

2023-06-07 15:04:51

- reply

📅 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>