-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
wrote:
> I feel like there is a lot of "in the weeds" discussion here about
> theoretical, what-if-this-and-that-happens-in-the-future scenarios.
>
> I would just like to point out (again) that this i
On Sat, Oct 26, 2013 at 10:25:06AM +1000, Gavin Andresen wrote:
> RE: lots of other comments:
>
> I feel like there is a lot of "in the weeds" discussion here about
> theoretical, what-if-this-and-that-happens-in-the-future scenarios.
Um... yeah. Note how I said on your original pull-req that I'd
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
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
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
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
On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd wrote:
> Eligius has contracts to do transaction mining, and it's currently 10%
> of the hashing power.
>
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
On Thu, Oct 24, 2013 at 04:46:41PM +0200, Mike Hearn wrote:
> Well, miners are all supposed to be more or less equivalent - modulo
> differences in tx acceptance policies - so I'd hope that having out of bad
> fee mechanisms yet still broadcasting the TX isn't that common. If it was
> broadcasted,
Well, miners are all supposed to be more or less equivalent - modulo
differences in tx acceptance policies - so I'd hope that having out of bad
fee mechanisms yet still broadcasting the TX isn't that common. If it was
broadcasted, it should get mined in short order, otherwise things are going
wrong
On Thu, Oct 24, 2013 at 04:38:16PM +0200, Mike Hearn wrote:
> On Thu, Oct 24, 2013 at 4:30 PM, Peter Todd wrote:
>
> > Quick thought on how to make blockchain-based fee estimates work better
> > in the context of out-of-band mining contracts: have miners advertise in
> > their coinbase's what fee
On Thu, Oct 24, 2013 at 4:30 PM, Peter Todd wrote:
> Quick thought on how to make blockchain-based fee estimates work better
> in the context of out-of-band mining contracts: have miners advertise in
> their coinbase's what fees were actually paid, as opposed to appear to
> have been paid.
This
Quick thought on how to make blockchain-based fee estimates work better
in the context of out-of-band mining contracts: have miners advertise in
their coinbase's what fees were actually paid, as opposed to appear to
have been paid.
The logic is very simple: we assume miners aren't an effective car
19 matches
Mail list logo
