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
>
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
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 polici
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
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 pl
> 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
>
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 concurrenc
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
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 (
> 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 b
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 featu
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
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 clien
13 matches
Mail list logo
