Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Melvin Carvalho]

On 16 August 2013 03:00, Gavin Andresen  wrote:

> Mike asked what non-0.9 code I'm working on; the three things on the top
> of my list are:
>
> 1) Smarter fee handling on the client side, instead of hard-coded fees. I
> was busy today generating scatter-plots and histograms of transaction fees
> versus priorities to get some insight into what miner policies look like
> right now.
>

+1


>
> 2) "First double-spend" relaying and alerting, to better support low-value
> in-person transactions.  Related:
> *Have *a *Snack*, Pay with 
> *Bitcoins*
>
>

+1


>
> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
> block size limit, how we can do it safely, and go through all of the
> arguments that have been made against it and explain why they're wrong.
>

What block size do you think is ideal?


>
> --
> --
> Gavin Andresen
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP 32.5

[Gregory Maxwell]

I am wondering if we shouldn't have a BIP32 addendum which makes the
following signing related recommendations:

(1) Recommend a specific deterministic DSA derandomization procedure
(a deterministic way to generate the DSA nonce), presumably one based
on HMAC-SHA512 (since BIP32 uses that construct) or SHA256 in the
style of RFC 6979.

DSA systems being compromised due to poor randomness at runtime is not
new. It effected other systems before it effected Bitcoin systems,
it's not a new problem and it's not going away.  It's difficult to
tell if an implementation is correct or not.

Use of a fully deterministic signature  would allow for complete test
vectors in signing and complete confidence that there is no random
number related weakness in a signing implementation.

In particular, with relevance to our ecosystem a maliciously modified
difficult to audit hardware wallet could be leaking its keys material
via its signatures. Even without producing insecure K values it could
use the choice of K to leak a couple bits of an encrypted root key
with every signature, and allow the malicious party to recover the
keys by simply observing the network. Making the signatures
deterministic would make this kind of misbehavior practically
discoverable.

We wouldn't be alone in making this change, in general industry is
moving in this direction because it has become clear that DSA is a
hazard otherwise.

The primary arguments in most spaces against derandomizing DSA are
FIPS conformance (irrelevant for us) and reasonable concerns about the
risks of using a (less) reviewed cryptographic construct. With
widespread motion towards derandomized DSA this latter concern is less
of an issue.

Libcrypt has also implemented derandomized DSA in git. The ed25519
signature system of DJB, et. al. also uses a similar derandomization.

An alternative is implementing a still random construct where K is
some H(message||key||random) which should remain secure even where the
randomness is poor, but this loses the advantage of being able to
externally verify that an implementation is not leaking information.
OpenSSL development has implemented a form of this recently.

See also: http://tools.ietf.org/rfc/rfc6979.txt

(2) Recommends a procedure for using only even S values in signatures,
eliminating this source of mutability in transactions.

This can be accomplished via post-processing of existing signatures,
but since it requires bignum math it is usually preferable to
implement it along with signing.  I believe someday this will become a
network requirement for Bitcoin, but regardless it makes sense to
implement it as a best practice sooner rather than later.

Thoughts?

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Gavin's post-0.9 TODO list...

[Gavin Andresen]

Mike asked what non-0.9 code I'm working on; the three things on the top of
my list are:

1) Smarter fee handling on the client side, instead of hard-coded fees. I
was busy today generating scatter-plots and histograms of transaction fees
versus priorities to get some insight into what miner policies look like
right now.

2) "First double-spend" relaying and alerting, to better support low-value
in-person transactions.  Related:
*Have *a *Snack*, Pay with
*Bitcoins*


3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
block size limit, how we can do it safely, and go through all of the
arguments that have been made against it and explain why they're wrong.

-- 
--
Gavin Andresen
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Wendell]

Mike,

If bitcoinj will be ready and you will help us, we are willing to implement it 
right away in Hive as well. We will also keep BitcoinKit.framework updated with 
the new bitcoind and bitcoinj implementations.

BitPay taking the lead here would be tremendous. Hopefully cool sites like 
Bitcoin Store will also be game to hit the ground running. I'll ask them.

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Aug 15, 2013, at 10:09 AM, Mike Hearn wrote:

> Pieter, Matt and I also agreed that for maximum impact we should really try 
> to ship payment protocol support in at least two clients simultaneously and 
> ideally with a big merchant signed up too - to send a powerful message that 
> we really mean it. Someone volunteered last week to do it for bitcoinj and if 
> he doesn't pull through, I have some old code from EOY 2012 that I could 
> update to the latest spec and ship at least some basic support. I'd hope that 
> we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty 
> fast.
> 
> Also, Jeff said that BitPay want to be a leader in support for the protocol. 
> So let's try and co-ordinate release dates so we can make a bit of a splash 
> and grab the ecosystems attention.


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[slush]

On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn  wrote:

> On Thu, Aug 15, 2013 at 10:22 AM, slush  wrote:
>
>> We're planning to support payment protocol in Trezor as well, if it
>> counts. I think it's a missing piece in absolute security of hardware
>> wallets.
>>
>
> Yup, that's always been the plan :-)
>
> Any idea how much work it is, and would it be a v1 feature of the Trezor
> or added later via firmware update?
>

Our plan is to add support for that into v1 firmware, but it also depends
on readiness of surrounding infrastructure; mainly if there'll be support
for payment protocol in multibit in the time of v1 release (I suppose that
the Multibit will be the first wallet  compatible with Trezor AND
supporting payment protocol).

slush
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Mike Hearn]

> Our plan is to add support for that into v1 firmware, but it also depends
> on readiness of surrounding infrastructure; mainly if there'll be support
> for payment protocol in multibit in the time of v1 release (I suppose that
> the Multibit will be the first wallet  compatible with Trezor AND
> supporting payment protocol).
>

Yeah, OK. Let's see how much progress Gary makes. Supporting HD wallets is
the trickiest part and I don't know how much time I will have - the Android
RNG issue and getting bcj 0.10 released have sucked up a lot of my time
lately and I need to refocus on other things for a bit. But between the guy
who volunteered to do payment protocol, and Gary doing TrezorJ, and Matija
already having done the core algorithms, I'm hoping the only parts I'll
have to do are integrating the HD code with the core wallet code. Possibly
if we're running out of time I can do a real basic HD wallet implementation
that only iterates a key once and doesn't generate new keys for each
transaction, as that's really the trickiest part (because of the need for
lookahead/behind and memory bloat on phones).
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Pieter Wuille]

On Thu, Aug 15, 2013 at 12:49 PM, Wladimir  wrote:
> Fully agreed about payment protocol, autotools and Qt5 build.
>
> I'm still not very excited about coin control (and last time I looked at the
> code, it has an issue that it introduced statefulness into the wallet model
> - a bane for concurrency. But that may be resolved?) . Anyway, many people
> seem to want that so it's fine with me, given that the issues are fixed.

As far as I can see, that state is gone, and is now passed in a
separate object to the transaction-creation methods.

I'd like to see it go in, as I believe it can be helpful in
understanding the difference between the high-level abstraction
(wallet) and the underlying implementation (individual coins) -
something that many people are confused about. I think that's even a
more important advantage than the ability for micro-management it
offers. Multiwallet would be more appropriate for avoiding linkage
between identities, but it seems there's little progress on that front
now.

-- 
Pieter

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Wladimir]

On Thu, Aug 15, 2013 at 2:29 AM, Gavin Andresen wrote:

> It feels to me like we're close to a 0.9 "feature freeze" / start of
> release cycle; I'd like to talk a little bit about what we'd like to see in
> the final 0.9 release.
>
> Payment Protocol support is ready to be pulled (
> https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major
> objections, I will pull it tomorrow (it has already gone through two rounds
> of bounty-driven QA testing, so I'm convinced it is ready).
>

No objections from me, I've already looked at the code a few times and did
some testing here and there, looks good for merging.


> I'd love for 0.9 to contain sipa's "headers first" initial block download
> optimization; I think it is a big enough improvement to justify making the
> 0.9 test/release cycle longer.
>

Yep, that'd be great.


> Coin control (https://github.com/bitcoin/bitcoin/pull/2343).
>
> The autotools work (https://github.com/bitcoin/bitcoin/pull/2805).
>
> Gitian-build with the latest openssl and Qt5. Perhaps update the version
> of Debian VMs that we gitian-build with.
>

Fully agreed about payment protocol, autotools and Qt5 build.

I'm still not very excited about coin control (and last time I looked at
the code, it has an issue that it introduced statefulness into the wallet
model - a bane for concurrency. But that may be resolved?) . Anyway, many
people seem to want that so it's fine with me, given that the issues are
fixed.

Wladimir
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Melvin Carvalho]

On 15 August 2013 02:29, Gavin Andresen  wrote:

> It feels to me like we're close to a 0.9 "feature freeze" / start of
> release cycle; I'd like to talk a little bit about what we'd like to see in
> the final 0.9 release.
>
> My list:
>
> Bug:  I'd really like to see the leveldb corruption issue (mostly on OSX,
> it seems) fixed. This is hard because it can't be reliably reproduced, and,
> at least on my machine, takes weeks to occur. Help needed to reproduce/fix,
> see https://github.com/bitcoin/bitcoin/issues/2770 for what we know about
> the problem.
>
> Payment Protocol support is ready to be pulled (
> https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major
> objections, I will pull it tomorrow (it has already gone through two rounds
> of bounty-driven QA testing, so I'm convinced it is ready).
>
> I'd love for 0.9 to contain sipa's "headers first" initial block download
> optimization; I think it is a big enough improvement to justify making the
> 0.9 test/release cycle longer.
>
> Coin control (https://github.com/bitcoin/bitcoin/pull/2343).
>
> The autotools work (https://github.com/bitcoin/bitcoin/pull/2805).
>
> Gitian-build with the latest openssl and Qt5. Perhaps update the version
> of Debian VMs that we gitian-build with.
>
> I plan on spending about half my time on code review and helping get pull
> requests tested, and the other half of my time working on code that
> probably won't make it into the 0.9 release.
>

+1

Sounds great!


>
> --
> --
> Gavin Andresen
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[slush]

> Pieter, Matt and I also agreed that for maximum impact we should really
> try to ship payment protocol support in at least two clients simultaneously
> and ideally with a big merchant signed up too - to send a powerful message
> that we really mean it. Someone volunteered last week to do it for bitcoinj
> and if he doesn't pull through, I have some old code from EOY 2012 that I
> could update to the latest spec and ship at least some basic support. I'd
> hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has
> support pretty fast.
>

We're planning to support payment protocol in Trezor as well, if it counts.
I think it's a missing piece in absolute security of hardware wallets.

slush
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Mike Hearn]

On Thu, Aug 15, 2013 at 10:22 AM, slush  wrote:

> We're planning to support payment protocol in Trezor as well, if it
> counts. I think it's a missing piece in absolute security of hardware
> wallets.
>

Yup, that's always been the plan :-)

Any idea how much work it is, and would it be a v1 feature of the Trezor or
added later via firmware update?
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Pieter Wuille]

On Thu, Aug 15, 2013 at 10:09:48AM +0200, Mike Hearn wrote:
> Sounds awesome!
> 
> Pieter told me at lunch that headers first cut sync time to 45 minutes for
> him, which is another amazing improvement from the master of optimisations.

Just to make sure nobody expects a magic bullet: this was on a hexacore Xeon
CPU, with several GB of -dbcache, libsecp256k1 for verification, and a very good
network connection. It is repeatable and from random network peers, though. The
code is here:

  https://github.com/sipa/bitcoin/commits/headersfirst

It's usable and seems to be stable (including reindexing, which needs support 
for
block files with out-of-order blocks now), but I still want to clean some
things up before pullreq'in. There are probably some heuristic tweaks
possible as well - Gregory found that performance is reduced for the first
part of the chain on high-latency networks.

> Pieter, Matt and I also agreed that for maximum impact we should really try
> to ship payment protocol support in at least two clients simultaneously and
> ideally with a big merchant signed up too - to send a powerful message that
> we really mean it. Someone volunteered last week to do it for bitcoinj and
> if he doesn't pull through, I have some old code from EOY 2012 that I could
> update to the latest spec and ship at least some basic support. I'd hope
> that we can get Bitcoin Wallet or MultiBit updates out once bcj has support
> pretty fast.
> 
> Also, Jeff said that BitPay want to be a leader in support for the
> protocol. So let's try and co-ordinate release dates so we can make a bit
> of a splash and grab the ecosystems attention.

I believe we do need some wider support than just Bitcoin-Qt, indeed, as
the number of people actually using the reference client as a wallet is
quite low now. Ideally, several clients and merchants start support for it
in a short timeframe...

-- 
Pieter

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Mike Hearn]

Sounds awesome!

Pieter told me at lunch that headers first cut sync time to 45 minutes for
him, which is another amazing improvement from the master of optimisations.

Pieter, Matt and I also agreed that for maximum impact we should really try
to ship payment protocol support in at least two clients simultaneously and
ideally with a big merchant signed up too - to send a powerful message that
we really mean it. Someone volunteered last week to do it for bitcoinj and
if he doesn't pull through, I have some old code from EOY 2012 that I could
update to the latest spec and ship at least some basic support. I'd hope
that we can get Bitcoin Wallet or MultiBit updates out once bcj has support
pretty fast.

Also, Jeff said that BitPay want to be a leader in support for the
protocol. So let's try and co-ordinate release dates so we can make a bit
of a splash and grab the ecosystems attention.

On Thu, Aug 15, 2013 at 2:29 AM, Gavin Andresen wrote:

> I plan on spending about half my time on code review and helping get pull
> requests tested, and the other half of my time working on code that
> probably won't make it into the 0.9 release.
>

Sounds brilliant. It'll be nice to see the pull request queue drain. Any
ideas what the non-0.9 code will be? Fee rework? DoS work?
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development