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 pos
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 hi
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr 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 authentication and
non-
On Sat, Oct 26, 2013 at 1:31 PM, Gregory Maxwell 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 think a tiny n
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 hid
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 t
On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman
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 will be rare and are n
Would it make sense to use either fixed length strings or maybe even enums?On Oct 25, 2013, at 05:34 PM, Gavin Andresen 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" denial-of-service mitigati
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 t
On Fri, Oct 25, 2013 at 5:51 PM, Jeremy Spilman 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 the best plac
On Fri, Oct 25, 2013 at 12:51:22AM -0700, Jeremy Spilman wrote:
> Gavin, can you confirm the best place to read up on the discuss
> fee estimation changes for v0.9?
>
> I think fee estimation at its core is about providing a data point,
> or even call it an API, which can be used however you see
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 t
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 I
On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell
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
> I’m hoping for your hel
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 inc
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 w
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 mempool.
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
> 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
-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 Peterss
> 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
> coming soon if that's your thinking.
If there is a situation where wallets
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
Gavin, can you confirm the best place to read up on the discuss fee estimation changes for v0.9?I think fee estimation at its core is about providing a data point, or even call it an API, which can be used however you see fit.What parameters do I want to see in a 'fee estimation' API? - 30 minut
On Fri, Oct 25, 2013 at 06:39:34AM +1000, Gavin Andresen wrote:
> Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
> the answer is "a small percentage."
>
> So: there are multiple layers of reasons why OOB fee payments will not
> screw up the fee estimation code:
I've re
24 matches
Mail list logo
