[Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

[Jean-Paul Kogelman]

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 



Kind regards,

Jean-Paul--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] PAPER: New algorithm for the discrete logarithm problem on elliptic curves

[Jean-Paul Kogelman]

FYI,

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

jp
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Re: PAPER: New algorithm for the discrete logarithm problem on elliptic curves

[Jean-Paul Kogelman]

Ok, false alarm. :)

Sorry for the spam.

On Apr 07, 2015, at 02:37 PM, Gregory Maxwell  wrote:

On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
 wrote:
https://eprint.iacr.org/2015/310.pdf

http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

I do, but it's currently not in shippable form. Would the encoding / decoding functions suffice?jpOn Jul 19, 2013, at 10:54 AM, "Andreas M. Antonopoulos"  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 <jeanpaulkogel...@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 encryptionAuthor: Jean-Paul KogelmanStatus: DraftType: InformationalCreated: 17-07-2013...--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

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).jpOn Jul 19, 2013, at 11:09 AM, Jeremy Spilman  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,--JeremyOn Fri, 19 Jul 2013 10:46:44 -0700, Jean-Paul Kogelman  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 encryptionAuthor: Jean-Paul KogelmanStatus: DraftType: InformationalCreated: 17-07-2013AbstractThis 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.MotivationThe 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. CopyrightThis proposal is hereby placed in the public domain.RationaleUser 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. SpecificationThis 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.PrefixIt 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

[Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

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 encryptionAuthor: Jean-Paul KogelmanStatus: DraftType: InformationalCreated: 17-07-2013AbstractThis 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.MotivationThe 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. CopyrightThis proposal is hereby placed in the public domain.RationaleUser 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. SpecificationThis 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.PrefixIt 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 specificationThere 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 bytesPrefix 0x1E68: Clear 32 byte master seed, total length: 38 bytesPrefix 0x665A: Clear 64 byte master seed, total length: 70 bytesPrefix 0x1EE4: 2-factor 16 byte master seed, total length: 22 bytesPrefix 0x38AE: 2-factor 32 byte master seed, total length: 38 bytesPrefix 0xBECB: 2-factor 64 byte master seed, total length: 70 bytesThese are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

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

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

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=258678Cheers,jpOn Jul 22, 2013, at 06:14 AM, Mike Hearn  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".
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

On 2013-10-19, at 1:40 PM, Gregory Maxwell  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

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

 
On 2013-10-19, at 3:29 PM, Luke-Jr  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

On 2013-10-19, at 4:21 PM, Jean-Paul Kogelman  wrote:

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

That would be 2013. sorry.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

On 2013-10-19, at 4:20 PM, Gregory Maxwell  wrote:

> On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

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




signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

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  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  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
> 000245a735ccc14b98552e152f773c07efa2e89dd7f0463f61cf



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

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  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
> 00099eaa116fac83a2b0e097cae3391c794990e128c8e162d91a



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

The list comes from BIP 1.

On 2013-10-21, at 12:03 AM, Martin Sustrik  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

On 2013-10-21, at 2:44 AM, Arto Bendiken  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.


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

[Jean-Paul Kogelman]

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  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.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

[Jean-Paul Kogelman]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

[Jean-Paul Kogelman]

Would it make sense to use either fixed length strings or maybe even enums?On Oct 25, 2013, at 05:34 PM, Gavin Andresen  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.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] moving the default display to mbtc

[Jean-Paul Kogelman]

On Nov 15, 2013, at 05:10 PM, Luke-Jr  wrote:On Saturday, November 16, 2013 12:41:56 AM Drak wrote:So "a payment clears after one confirmation, but you might want to waituntil the payment has been confirmed n times".Then at least you are not using the same word for two different meaningsand 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.--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

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?



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption

[Jean-Paul Kogelman]

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


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] HD wallet import strategies

[Jean-Paul Kogelman]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

[Jean-Paul Kogelman]

> On Mar 5, 2014, at 8:56 PM, Pieter Wuille  wrote:
> 
>> On Wed, Mar 5, 2014 at 1:49 PM, Mike Hearn  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Instant / contactless payments

[Jean-Paul Kogelman]

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  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

[Jean-Paul Kogelman]

On Mar 12, 2014, at 6:11 AM, Pavol Rusnak  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

[Jean-Paul Kogelman]

On Mar 12, 2014, at 08:55 AM, Pavol Rusnak  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--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

[Jean-Paul Kogelman]

On Mar 12, 2014, at 09:49 AM, Gary Rowe  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? --
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

[Jean-Paul Kogelman]

On Mar 12, 2014, at 01:24 PM, Pavol Rusnak  wrote:On 03/12/2014 09:10 PM, William Yager wrote:implement this is to allow semi-trusted devices (like desktop PCs) to doall the "heavy lifting". The way the spec is defined, it is easy to have amore powerful device do all the tough key stretching work withoutsignificantly 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--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Jean-Paul Kogelman]

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  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  wrote:
>>> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer  
>>> 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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development