Andrew Miller | 2 Mar 17:48 2015
Picon

New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies

We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten,
Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have
written a “systemization” paper about Bitcoin-related research. It’s
going to appear in the Oakland security conference later this year
(IEEE Security and Privacy) but we wanted to announce a draft to this
community ahead of time.

http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf

One of the main goals of our work is to build a bridge between the
computer science research community and the cryptocurrency community.
Many of the most interesting ideas and proposals for Bitcoin come from
this mailing list and forums/wikis/irc channels, where many academic
researchers simply don’t know to look! In fact, we started out by
scraping all the interesting posts/articles we could find and trying
to figure out how we could organize them. We hope our paper helps some
of the best ideas and research questions from the Bitcoin community
bubble up and inspires researchers to build on them.

We didn’t limit our scope to Bitcoin, but we also decided not to
provide a complete survey of altcoins and other next-generation
cryptocurrency designs. Instead, we tried to explain all the
dimensions along which these designs differ from Bitcoin.

This effort has roughly been in progress over two years, though it
stopped and restarted several times along the way.

If anyone has comments or suggestions, we still have a week before the
final version is due, and regardless we plan to continue updating our
online version for the forseeable future.
(Continue reading)

Thomas Voegtlin | 1 Mar 16:23 2015

Electrum 2.0 has been tagged


Dear Bitcoin devs,

I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0

The electrum.org website will be updated later today. The release
notes are a bit dense, due to the large amount of changes and new
features in this release. In the coming weeks we will be adding more
detailed documentation to the wiki and to the website.

There has been a very long hiatus in Electrum releases, because it
took me a lot of time to decide about the new seed derivation method
and wallet structure. Now that this part is done, I hope that we will
resume to a faster release pace.

I would like to thank all the people who contributed to this release,
developers, beta testers, but also people from this list who provided
useful feedback.

Cheers,

Thomas

_____________________________

RELEASE-NOTES

# Release 2.0

(Continue reading)

Oleg Andreev | 26 Feb 12:14 2015
Picon

Re: Providing Payment Request within URI


> Base43 is the same as any BaseX standard, but using a different alphabet
> (43 characters). It's meant to be used for efficiently storing binary
> data into QR codes. The alphabet is picked to match the 'Alphanumeric'
> input mode of QR codes as closely as possible, but at the same time be
> allowed in URIs.

Does it mean Base58 or Base64 take more space in QR code than Base43? Do you have an estimate of the gains? 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
Gregory Maxwell | 25 Feb 19:47 2015
Picon

BCF 2012 Miner vote

It would appear that the Bitcoin Foundation has decided that their
next two seats would be decided by miners.   (More information
available at: https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453
)

Unfortunately, they seem to have not provided the software needed to
participate.

I've taken Luke DashJr's somewhat notorious IsNotorious patch, which
he's used previously to block things like the Horse Stapler Battery
dust-spam attacks and re-purposed it so miners can avoid casting votes
in the election that they don't intend to cast.

Not really an ideal fit, but the code has the benefit of having been
run in production for some time; a necessity for deployment on short
notice.

A patch (against git master, but should apply to 0.10 cleanly at least
and probably other versions) is available at:

https://people.xiph.org/~greg/bcf2012.patch

Let me know if you have any trouble applying it, I'll be glad to do my
civic duty and do what I can to help people participate with the
system was clearly intended by the design.

[Please note that I am relying on some claims from reddit for some of
the candidate addresses (
http://www.reddit.com/r/Bitcoin/comments/2x3ffk/bitcoin_foundation_runoff_voting_live_stats_2015/
) because the official voting software is more or less completely
(Continue reading)

Eric Voskuil | 25 Feb 10:20 2015

Re: Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

The list appears dead, this is a test.

e

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Oleg Andreev | 24 Feb 16:58 2015
Picon

Providing Payment Request within URI

Hi,

I wonder if there is a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The
goal is to allow device to generate a multi-output payment request on its own, without relying on the
server and x509 certificates. When scanned via QR code from, say, POS, it's pretty secure, so no
additional authentication needed.

I'd like something like this: 

bitcoin:?r=data://<base64url-encoded-payment-request>

If there's no standard for that, would it be a good idea to extend BIP72 this way?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
Mem Wallet | 23 Feb 23:56 2015
Picon

BIP proposal -- wallet extensions


Working on a proposal for extensions based on bip44 conventions.

Most interesting is: Fully Deterministic GPG keys.

https://github.com/taelfrinn/bip44extention

Would welcome any comments or interest



------------------------------------------------------------------------------
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=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Chris Page | 23 Feb 20:27 2015
Picon

Request for comments on hybrid PoW/PoS enhancement for Bitcoin


I'm soliciting feedback on an idea to will improve security, increase the number of full nodes, and provide more avenues for bitcoin distribution.   The idea is still in its infancy, but I need constructive feedback before I take this further, or decide to abandon the idea.

In particular, my ego is in check and I'm ready to be made a fool, but in turn, I'll be that much better educated, so fair trade!

Here is the high-level overview:

1) A new block B0 is mined and broadcast as usual

2) Full nodes verify block B0. A subset of these nodes broadcast a new "endorsement" message endorsing the block as valid, and preferred.

3) Miners, now assembling and beginning mining a new block (B1), add endorsements of B0 to B1's coinbase transaction, sharing the block reward with endorsers of B0.

As proposed, the idea of Block Endorsement requires a new message, but fits into current structures.

Here some details about each of the steps above, and what it buys us:

1) The mining of block B0: No changes to current process or format.  Blocks are mined and broadcast as they are today.

2)  Only a subset of nodes are eligible to endorse a block, and hence, only a subset are eligible for an endorsement reward.  We restrict to avoid a flood of endorsement messages by every node following the announcement of each new block.  An endorsement message needs to identify exactly one block at a specific height that it is endorsing.  It needs to include a payout address that meets certain validation criteria relative to the block it is endorsing.  A valid payout address will include some proof of stake (PoS), whether that be that it has a 1+ bitcoin balance, some age weighted balance, or something else is TBD.  The reason for PoS is that it should not be the case that a subversive miner could easily fabricate a valid endorsement payout address.  The other requirement is that the tail bits of a valid endorsement payout address, when masked (size of mask TBD) need to match the trailing bits of the hash of the block it is validating.   This directly ties endorsements to a specific block, and makes it computationally inexpensive to verify/relay, or drop invalid endorsement messages. The combination of PoS and mask will restrict the number of valid addresses.  There are no restrictions on which endorsements a miner can include, as long as they are valid.  As part of new block validation, full nodes would need to do all that they do now, but they would also need to validate endorsements included in the coinbase transaction.

3) Miners consider whether to include endorsement payouts as part of their coinbase transaction.  They need not do so, but by including endorsements, they significantly increase the likelihood that their block will be selected.

CHANGE TO BEST CHAIN SELECTION

Block Endorsement requires a change to the best chain selection algorithm to encourage miners to include endorsement payouts.  Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. 

For the purpose of best chain selection, a block should get a significant bonus to its work (10%) for each valid endorsement payout included in a block's valid coinbase transaction.  How many endorsements should be permitted is a design parameter which is in play, but let's assume that up to 10 endorsements are permitted.   For the purpose of block selection, a block's work, with 10 endorsements, is be effectively doubled.

EFFECT ON 51% ATTACK

With Block Endorsement, because of the extra weight given to a block that has endorsements, a sustained 51% attack becomes more expensive.  Valid blocks with full endorsements would win out over the attack blocks unless the attacker was able to not only control 51% of the compute power, but to also control sufficient endorsements to overcome the rest of the network.  To prevent an attacker from just using suitable addresses as endorsers from the blockchain, a full node would have to maintain a list of recently broadcast endorsement messages for TBD (100) blocks to prove the validity of the endorsements.  Quite possibly we might need to provide a way for a booting node to request lists of endorsers.

CHANGE TO BLOCK REWARD

Miners would share block rewards with endorsers using a defined formula which is TBD.  Endorsement rewards would be as much as 20% (design parameter) of the block reward, and shared evenly between all endorsers included in the coinbase.

CHANGE TO MINING STRATEGIES

When a new block is broadcast, miners will begin assembling yet another block.  Meanwhile, full nodes would validate the new block, and endorsements would propagate quickly thereafter to all miners.  This should not take long as it is easy to identify whether or not an address is a valid endorser.  I would expect shortly after assembling a block, there would be a number of potential endorsers to include in the coinbase tx, and if 10 were not available, a miner could decide to wait, or begin mining it.  I suspect the time to collect 10 valid endorsers would be low, as endorsers should reply quickly in hopes of being included. Therefore, this additional wait time, if any, would not have a appreciable impact on the level of difficulty required to mine a block.

I have thoughts on how to provide additional incentives to miners to include multiple endorsers - for example, reducing the total endorsement fee down to 10% if endorsed by a full complement of endorsers.  We could also start with a lower reward and ramp up to some target over time to not burden the business plans of current mining operations.  But these and other ideas are added complexity that I don't know offers much return.  It is easy to add complexity.  The challenge is to keep it as simple as possible. 

CONCLUSION

By implementing Block Endorsement, we increase security of the blockchain by giving more weight to blocks that have been broadcast and endorsed by multiple full nodes.  By providing a reward to these endorsers, we provide an incentive for more full nodes.  With proof of state mining on top of existing proof of work, we provide a low barrier to entry, while not sacrificing the benefits provided by PoW.  With a lower barrier to entry, we provide a more accessible avenue for mining, and in turn, encourage bitcoin adoption.

This is just the beginnings of an idea.  Assuming there isn't a fundamental flaw(s), there are many knobs to tweak, and no doubt, it would benefit greatly by the technical expertise and creativity of others.  I do feel as if there are still some gaps and that it hasn't yet been full explored yet even as a thought experiment.  For instance, what new attack vectors might be introduced?  Would a person controlling many potential endorsement addresses be able to launch an attack by endorsing a set of blocks, essentially launching a 51% attack but by using endorsements as a PoW multiplier?  Or is that not practical?  The answer is probably a function of the endorsement criteria.  There are many different angles that require thought and scrutiny.  I'm sure there are many that I've yet to even consider. 

And as I read discussions about double-spends and zero-confirmation transactions I can't help but wonder if maybe there is a way for endorsers to play a role in identifying possible double-spends.  Negative endorsements?

I'm new to the development process and the code base.  Assuming the feedback isn't derailing, would the next step be to proceed with implementation, or would a new BIP be recommended? 

Well, I thought this would be only a few paragraphs.  It is easy to carry on when you are excited about something.  That's also the time when a person is most likely to miss some short-comings, so I am anxious for feedback.  Thanks for reading, and I'd be most appreciative of constructive comments and questions.

Thanks
Chris Page
------------------------------------------------------------------------------
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=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Jan Vornberger | 22 Feb 20:08 2015
Picon

Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

Hi everyone,

I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which
displays QR codes, but also provides payment requests via NFC. It can optionally
receive the sender's transaction via Bluetooth, so if the sender wallet
supports it, the sender can be completely offline. Only the terminal needs an
internet connection.

Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch
in the future) on the NFC pad, confirms the transaction on their phone
(or smartwatch) and the transaction completes via Bluetooth and/or the phone's
internet connection.

You can see a prototype in action here:

  https://www.youtube.com/watch?v=P7vKHMoapr8

The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
works as shown today. However, some parts - especially the Bluetooth stuff - are
custom extensions of Schildbach's wallet which are not yet standard.

I'm writing this post to document my experience implementing NFC and offline
payments and hope to move the discussion forward around standardizing some of
this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are
relevant here as well.

## NFC vs Bluetooth vs NFC+Bluetooth ##

Before I get into the implementation details, a few words for why I decided to
go with the combination of NFC and Bluetooth:

Doing everything via NFC is an interesting option to keep things simple, but the
issue is, that one usually can't maintain the connection while the user confirms
the transaction (as they take the device back to press a button or maybe enter a
PIN). So there are three options:

1. Do a "double tap": User taps, takes the device back, confirms, then taps
again to transmit the transaction. (I think Google Wallet does something like
this.)

2. Confirm beforehand: User confirms, then taps and everything can happen in one
go. The disadvantage is, that you confirm the transaction before you have seen
the details. (I believe Google Wallet can also work this way.)

3. Tap the phone, then establish a Bluetooth connection which allows you to do
all necessary communication even if the user takes the device back.

I feel that option 3 is the nicest UX, so that is what I am focusing on right
now, but there are pros and cons to all options. One disadvantage of option 3 in
practice is, that many users - in my experience - have Bluetooth turned off, so
it can result in additional UI dialogs popping up, asking the user to turn on
Bluetooth.

Regarding doing everything via Bluetooth or maybe BLE: I have been following the
work that Airbitz has done around that, but personally I prefer the NFC
interaction of "I touch what I want to pay" rather than "a payment request comes
to me through the air and I figure out whether it is meant for me/is legitimate".

## NFC data formats ##

A bit of background for those who are not that familiar with NFC: Most Bitcoin
wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I
am aware (with CoinBlesk being an exception, which uses host-based card
emulation, if I understand it correctly). NDEF defines a number of record types,
among them 'URI' and 'Mime Type'.

A common way of using NFC with Bitcoin is to create a URI record that contains a
Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support
the mime type record, which is then set to 'application/bitcoin-paymentrequest'
and the rest of the NFC data is a complete BIP70 payment request.

## Implementation ##

To structure the discussion a little bit, I have listed a number of scenarios to
consider below. Not every possible combination is listed, but it should cover a
bit of everything.

Scenarios:

1) Scan QR code, transmit transaction via Bitcoin network
   Example QR code: bitcoin:1asdf...?amount=42

2) Touch NFC pad, transmit transaction via Bitcoin network
   Example NFC URI: bitcoin:1asdf...?amount=42

3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
   Example QR code: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest

4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
   Example NFC URI: bitcoin:1asdf...?amount=42&r=https://example.org/bip70paymentrequest

5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP
   Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment request

6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
   Example QR code: bitcoin:1asdf...?amount=42&bt=1234567890AB
   Payment request has 'payment_url' set to 'bt:1234567890AB'

7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via Bluetooth
   Example NFC URI: bitcoin:1asdf...?amount=42&bt=1234567890AB
   Payment request has 'payment_url' set to 'bt:1234567890AB'

Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just
listing them here for comparison. Scenario 3 is what is often in use now, for
example when using a checkout screen by BitPay or Coinbase.

I played around with both scenarios 4 and 5, trying to decide whether I should
use an NFC URI record or already provide the complete BIP70 payment request via
NFC.

My experience here has been, that the latter was fairly fragile in my setup
(Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy). I tried
with signed payment requests that were around 4k to 5k and the transfer would
often not complete if I didn't hold the phone perfectly in place. So I quickly
switched to using the NFC URI record instead and have the phone fetch the BIP70
payment request via Bluetooth afterwards. Using this approach the amount of data
is small enough that it's usually 'all or nothing' and that seems more robust to
me.

That said, I continue to have problems with the NFC stack that I'm using, so it
might just be my NFC setup that is causing these problems. I will probably give
the NXP NFC library a try next (which I believe is also the stack that is used
by Android). Maybe I have more luck with that approach and could then switch to
scenario 5.

Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' parameter is
the non-standard extension of Andreas' wallet that I was mentioning. TBIP75
proposes to change 'bt' into 'r1' as part of a more generic approach of
numbering different sources for the BIP70 payment request. I think that is a
good idea and would express my vote for this proposal. So the QR code or NFC URI
would then look something like this:

  bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource

In addition the payment request would need to list additional 'payment_url's. My
proposal would be to do something like this:

    message PaymentDetails {
        ...
        optional string payment_url = 6;
        optional bytes merchant_data = 7;
        repeated string additional_payment_urls = 8;
          // ^-- new; to hold things like 'bt:1234567890AB'
    }

TBIP75 proposes to just change 'optional string payment_url' into 'repeated
string payment_url'. If this isn't causing any problems (and hopefully not too
much confusion?) I guess that would be fine too.

In my opinion a wallet should then actually attempt all or multiple of the
provided mechanisms in parallel (e.g. try to fetch the BIP70 payment request via
both HTTP and Bluetooth) and go with whatever completes first. But that is of
course up to each wallet to decide how to handle.

TBIP75 furthermore proposes to include an additional 'h' parameter which would
be a hash of the BIP70 payment request, preventing a MITM attack on the
Bluetooth channel even if the BIP70 payment request isn't signed. This would
have also been my suggestion, although I know that Mike Hearn has raised
concerns about this approach. One being, that one needs to finalize the BIP70
payment request at the time the QR code and NFC URI is generated.

## Questions ##

My questions to the list:

1) Do you prefer changing 'optional string payment_url' into 'repeated string
payment_url' or would you rather introduce a new field 'additional_payment_urls'?

2)  <at> Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?

3) Are there other comments regarding 'h' parameter as per TBIP75?

4) General comments, advice, feedback?

I appreciate your input! :-)

Cheers,
Jan

[1] http://andyschroder.com/BitcoinFluidDispenser/
[2] https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
[3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
[4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki

------------------------------------------------------------------------------
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=190641631&iu=/4140/ostg.clktrk
Adam Back | 22 Feb 09:02 2015

alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

I agree with Mike & Jeff.  Blowing up 0-confirm transactions is vandalism.

bitcoin transactions are all probabilistic.  there is a small chance
1-confirm transactions can be reversed, and a different but also
usable chance that 0-confirm transactions can be reversed.  I know
0-confirm is implemented in policy and not consensus, but it provides
fast transactions and a lot of the current ecosystem is using it for
low value transactions.  why would anyone want to vandalise that.

to echo Mike bitcoin itself kind of depends on some honest majority,
we can otherwise get to situations soon enough where its more
profitable to double-spend than mine honestly as subsidy drops and
transaction values increase even without 0-confirm transactions.
subsidy doesnt last forever (though it lasts a really long time) and
even right now if you involve values that dwarf subsidy you could make
a "criminally rational" behaviour that was more profitable.  we even
saw 0-confirm odds-attacks against satoshi dice clones.  but if we
assume the "criminal rational" model, its a is a race to the bottom
logic, and bitcoin is already broken if we have someone who wants to
go for it with high values.  that'd be scorched earth also.

(I read the rest of the arguments, i understood them, I disagree, no
need to repeat in reply.)

So how about instead, to be constructive, whether you agree with the
anti-arson view or not, lets talk about solutions.  Here's one idea:

We introduce a new signature type that marks itself as can be spent by
miners if a double-spend is seen (before 1-confirm.)  We'd define a
double-spend as a spend that excludes outputs to avoid affecting valid
double-spend scenarios.  And we add behaviour to relay those
double-spends (at priority).  We may even want the double-spend to be
serialisation incomplete but verifiable to deter back-channel payments
to pretend not to receive one, in collusion with the double-spending
party.

Now the risk to the sender is if they accidentally double-spend.  How
could they do that?  By having a hardware or software crash where they
sent a tx but crashed before writing a record of having sent it.  The
correct thing to do would be to transactionally write the transaction
before sending it.  Still you can get a fail if the hardware
irrecoverably fails, and you have to resume from backup.  Or if you
run multiple non-synced wallets on the same coins.

Typically if you recover from backup the 1-confirmation window will
have passed so the risk is limited.

The feature is opt-in so you dont have to put high value coins at risk
of failure.

(Its related to the idea of a one-use signature, where two signatures
reveals a simultaneous equation that can recover the private key;
except here the miner is allowed to take the coins without needing the
private key).

Its soft-forkable because its a new transaction type.

ps I agree with Greg also that longer-term more scalable solutions are
interesting, but I'd like to see the core network work as a stepping
stone.  As Justus observed: the scalable solutions so far have had
non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain
0-confirm.

Adam

On 22 February 2015 at 04:06, Jeff Garzik <jgarzik <at> bitpay.com> wrote:
> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon <at> jtimon.cc> wrote:
>> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik <at> bitpay.com> wrote:
>>> This isn't some theoretical exercise.  Like it or not many use
>>> insecure 0-conf transactions for rapid payments.  Deploying something
>>> that makes 0-conf transactions unusable would have a wide, negative
>>> impact on present day bitcoin payments, thus "scorched earth"
>
>> And maybe by maintaining first seen policies we're harming the system
>> in the long term by encouraging people to widely deploy systems based
>> on extremely weak assumptions.
>
> Lacking a coded, reviewed alternative, that's only a platitude.
> Widely used 0-conf payments are where we're at today.  Simply ceasing
> the "maintaining [of] first seen policies" alone is simply not a
> realistic option.  The negative impact to today's userbase would be
> huge.
>
> Instant payments need a security upgrade, yes.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------
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=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
木ノ下じょな | 21 Feb 15:05 2015
Picon

Re: Request for a new BIP number (and discussion): Improved HD wallet generation.

Hello Bob,

> And compromise of that longer key still compromises the entire wallet. 

No, in fact I could give you any node (derived extended private key) or key (derived normal bitcoin address private key) AND any node's extended public key above them, and as long as the keys are generated within my specifications, you can not derive the associated extended private key to the ancestor extended public key.

If you think it still compromises the entire wallet, please show me in pseudo code / explanation.

> Under what circumstances would anyone ever be passing around private keys without your a,b?

I just added a Motivation section showing one example called Reality Keys. They send bitcoins to Yes/No bet addresses and the result of the bet's private key is revealed to award the winners via special P2SH scripts.
So they would need to give out "smaller" keys (aka normal private keys) and it would be better to manage them hierarchically instead of just generating millions of keys ahead of time and storing them on USBs or something.

Thanks,
Jona

2015-02-21 22:57 GMT+09:00 Bob Mcelrath <bob <at> mcelrath.org>:
But this just makes the private HD key longer, effectively. And compromise of that longer key still compromises the entire wallet.

Under what circumstances would anyone ever be passing around private keys without your a,b? The longer privkey is a wallet backup and has a reason to be copied. I can't think of a scenario where anyone would use or compromise the shorter privkey.

On February 21, 2015 8:32:30 AM EST, "木ノ下じょな" <kinoshitajona <at> gmail.com> wrote:
Yes.

That is similar to an idea at FC15 (http://fc15.ifca.ai/preproceedings/paper_15.pdf) but instead of increasing the number of keys needed up to m, and protecting against m-1 leaks. (so if you have to give keys out to 10 departments you must store 11 keys, or 363 bytes, I have decided to leave it at 2 keys protecting 1 leak, and then using convention to prevent calculating the master private key by requiring all private keys AND all extended private keys (aka "nodes" in my proposal) to be derived alone under their respective parents.

In theory this will prevent leakage of private keys from destroying the entire HD wallet entirely.

Services like "Reality Keys" could be a perfect use case (he must release private keys relating to the outcome, so he has decided against using BIP32 to generate addresses for! the bets.

Any Cryptographers that would like to take a look at the math and see if it's sound, I think I am properly breaking any linear relationships between keys... but I would like a second opinion.

Thank you for your reply,
Jona

2015-02-21 22:23 GMT+09:00 Adam Back <adam <at> cypherspace.org>:
Whats the objective?  Is it to require accidental disclosure of two
private keys to compute the master private key?

Adam

On 21 February 2015 at 13:20, 木ノ下じょな <kinoshitajona <at> gmail.com> wrote:
> Hello All,
>
> I have put together a proposal for a new generation methodology of HD
> wallets.
>
> The method is a modification of BIP32, so if something is unclear or not
> explicit, please assume it follows BIP32.
>
> I am looking forward to any and all criticism and help with writing / making
> the BIP more secure.
>
> If some of my pseudo code / English is off I apologize, I am not good with
> words.
>
> If this is deemed worthy enough to be drafted into a BIP, I would appreciate
> if someone could tell me what the overall step by step flow would be.
>
> Thank you, I will paste the link to the proposal below.
> Jona
>
> https://gist.github.com/dabura667/875bb2c159b219c18885
>
> --
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Comment: http://openpgpjs.org
>
> xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
> x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
> iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
> bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
> EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
> 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
> AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
> CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
> B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
> Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
> WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
> 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
> hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
> qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
> Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
> W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
> vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
> vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
> flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
> LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
> AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
> 0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
> 0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
> n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
> kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
> XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
> Spe3vsHZr6CqFg==
> =/vUJ
> -----END PGP PUBLIC KEY BLOCK-----
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



--
-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ! 9EBCACu
Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
Spe3vsHZr6CqFg==
=/vUJ
-----END PGP PUBLIC KEY BLOCK-----
!DSPAM:54e88938261511932039196!


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=190641631&iu=/4140/ostg.clktrk

!DSPAM:54e88938261511932039196!


Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


!DSPAM:54e88938261511932039196!

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



--
-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
Spe3vsHZr6CqFg==
=/vUJ
-----END PGP PUBLIC KEY BLOCK-----
------------------------------------------------------------------------------
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=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Gmane