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
-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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
20 matches
Mail list logo
