[Bitcoin-development] Version 0.9 goals

[Bitcoin-development] Version 0.9 goals

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1946 bytes --]

Re: [Bitcoin-development] Version 0.9 goals

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

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 <gavinandresen@gmail.com>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?

[-- Attachment #2: Type: text/html, Size: 1817 bytes --]

Re: [Bitcoin-development] Version 0.9 goals

[slush]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 1041 bytes --]

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

Re: [Bitcoin-development] Version 0.9 goals

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

On Thu, Aug 15, 2013 at 10:22 AM, slush <slush@centrum.cz> 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?

[-- Attachment #2: Type: text/html, Size: 737 bytes --]

Re: [Bitcoin-development] Version 0.9 goals

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

On 15 August 2013 02:29, Gavin Andresen <gavinandresen@gmail.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3604 bytes --]

Re: [Bitcoin-development] Version 0.9 goals

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

On Thu, Aug 15, 2013 at 2:29 AM, Gavin Andresen <gavinandresen@gmail.com>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

[-- Attachment #2: Type: text/html, Size: 2624 bytes --]

Re: [Bitcoin-development] Version 0.9 goals

[Pieter Wuille]

On Thu, Aug 15, 2013 at 12:49 PM, Wladimir <laanwj@gmail.com> 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

Re: [Bitcoin-development] Version 0.9 goals

[slush]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn <mike@plan99.net> wrote:

> On Thu, Aug 15, 2013 at 10:22 AM, slush <slush@centrum.cz> 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

[-- Attachment #2: Type: text/html, Size: 1601 bytes --]

Re: [Bitcoin-development] Version 0.9 goals

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1422 bytes --]

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.