Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-25 Thread Thomas Voegtlin
slush wrote : Two years ago I proposed exactly this and you refused to add extra information to mnemonic, because it isn't necessary and it makes it longer to mnemonization. What changed since then? I was wrong, and I fully acknowledge it. My concern was that adding extra information would

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There's no reason the signing can't be done all at once. The wallet app would create and sign three transactions, paying avg-std.D, avg, and avg+std.D fee. It just waits to broadcast the latter two until it has to. On 10/25/13 5:02 AM, Andreas

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Andreas Petersson
There's no reason the signing can't be done all at once. The wallet app would create and sign three transactions, paying avg-std.D, avg, and avg+std.D fee. It just waits to broadcast the latter two until it has to. i see several reasons why this is problematic. So how would that work in a

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Peter Todd
On Fri, Oct 25, 2013 at 02:02:35PM +0200, Andreas Petersson wrote: Worth thinking about the whole ecosystem of wallets involved; they all have to handle double-spends gracefully to make tx replacement of any kind user friendly. We should try to give people a heads up that this is

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Tamas Blummer
Two thoughts: 1. Please keep it simple, miner will override it either. 2. If block construction algorithm compares alternate chains and not individual transactions, then receiver can bump up the fee by spending the unconfirmed output again with higher fee, no need for replacement in the

[Bitcoin-development] BIP 38

2013-10-25 Thread Mike Caldwell
Hey everyone, I have noticed that there was a recent change to BIP 0038 (Password-Protected Private Key) on the Wiki, which is a proposal I wrote in late 2012. Gregory, it looks to me as though you have made this change, and I'm hoping for your help here. The change suggests that the number

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Jeremy Spilman
Do you think we're at the point where wallets have to be able to actively bid the fee using replacement due to block contention? I think a fee estimation API is just a data point. Depending on the properties of the estimator, and how that's presented in the UI, it could serve to either

Re: [Bitcoin-development] BIP 38

2013-10-25 Thread Gregory Maxwell
On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell mcaldw...@swipeclock.com wrote: I have noticed that there was a recent change to BIP 0038 (Password-Protected Private Key) on the Wiki, which is a proposal I wrote in late 2012. Gregory, it looks to me as though you have made this change, and

Re: [Bitcoin-development] BIP 38

2013-10-25 Thread Mike Caldwell
Gregory, No problem, thanks for providing the IRC recap, and glad I've finally made radio contact with the list. Perhaps there can be some long overdue discussion on the topic. I see Kogelman's improvements to my proposal as being of merit and may very well be sufficient to supersede what

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Peter Todd
On Fri, Oct 25, 2013 at 12:35:34PM -0700, Jeremy Spilman wrote: Do you think we're at the point where wallets have to be able to actively bid the fee using replacement due to block contention? If Bitcoin continues to grow we probably will be at some as-yet-unknown point in the future. I think

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Gavin Andresen
On Fri, Oct 25, 2013 at 5:51 PM, Jeremy Spilman jer...@taplink.co wrote: ** Gavin, can you confirm the best place to read up on the discuss fee estimation changes for v0.9? The blog post is the best place for high-level overview. The (closed for now, but it will come back) pull request is

[Bitcoin-development] Feedback requested: reject p2p message

2013-10-25 Thread Gavin Andresen
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

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

2013-10-25 Thread 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 gavinandre...@gmail.com 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"

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

2013-10-25 Thread Gavin
On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: Would it make sense to use either fixed length strings or maybe even enums? No. Enums or fixed length strings just make it harder to extend, for no benefit (bandwidth of 'reject' messages doesn't matter, they

[Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Gregory Maxwell
One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. A tor hidden service (onion site) is controlled by an RSA key. It would be trivial

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Luke-Jr
On Saturday, October 26, 2013 3:31:05 AM Gregory Maxwell wrote: One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. A tor hidden

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Gavin Andresen
On Sat, Oct 26, 2013 at 1:31 PM, Gregory Maxwell gmaxw...@gmail.com wrote: This would give us an fully supported option which is completely CA free... it would only work for tor sites, but the people concerned about CA trechery are likely to want to use tor in any case. Thoughts? I

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Gregory Maxwell
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote: Is there any point to additional encryption over tor (which afaik is already encrypted end-to-end)? Is there a safe way to make this work through tor entry nodes/gateways? The x.509 in the payment protocol itself is for

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Peter Todd
On Fri, Oct 25, 2013 at 08:31:05PM -0700, Gregory Maxwell wrote: One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. A tor hidden

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

2013-10-25 Thread kjj
The HTTP status code system seems to work well enough, and seems to give the best of both worlds. A 3 digit numeric code that is machine-readable, and a freeform text note for humans. The clever part about that system was in realizing that the numeric codes didn't need to account for every