On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine wrote:
> > A Header-PoW-verifying client could still be given all transactions in
> a recent block, from which it can see the in-band fees directly.
>
> You don't know the fees paid by any given transaction unless you also have
> all it's inputs. Tr
One possible solution that wallets could adopt when blocks fill up, would
be to abandon the p2p network for transaction propagation altogether, and
instead work directly with a handful of the largest miners and pools to get
transactions into blocks. The miners could auction off space in their
block
> A Header-PoW-verifying client could still be given all transactions in a
recent block, from which it can see the in-band fees directly.
You don't know the fees paid by any given transaction unless you also have
all it's inputs. Transaction inputs do not include an amount. You could
however get t
On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd wrote:
> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine
> wrote:
> >
> > > It could be done by agreeing on a data format and encoding it in an
> > > op_return output in the coinbase tra
On Thu, Jun 11, 2015 at 7:10 AM, Peter Todd wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> > The other complication is that this will tend to be a lagging indicator
> > based on network congestion from the last time you connected. If we
> assume
> > that transactions ar
>
> > Re: "dropped in an unpredictable way" - transactions would be dropped
> > lowest fee/KB first, a completely predictable way.
>
> Quite agreed.
No, Aaron is correct. It's unpredictable from the perspective of the user
sending the transaction, and as they are the ones picking the fees, that i
On 6/11/2015 6:10 AM, Peter Todd wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
>> The other complication is that this will tend to be a lagging indicator
>> based on network congestion from the last time you connected. If we assume
>> that transactions are being dropped in
Peter Todd wrote:
> Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.
It would be 'completely predictable' for whoever knew the state and
policies of a miner's mempool, but from an end user's perspective that
wouldn't matte
On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> The other complication is that this will tend to be a lagging indicator
> based on network congestion from the last time you connected. If we assume
> that transactions are being dropped in an unpredictable way when blocks are
> full,
>
> If we assume that transactions are being dropped in an unpredictable way
> when blocks are full, knowing the network congestion *right now* is
> critical, and even then you just have to hope that someone who wants that
> space more than you do doesn't show up after you disconnect.
>
Yeah, my p
The other complication is that this will tend to be a lagging indicator
based on network congestion from the last time you connected. If we assume
that transactions are being dropped in an unpredictable way when blocks are
full, knowing the network congestion *right now* is critical, and even then
> Sounds plausible, except SPV protocols would need to include this
coinbase txn if it's going to help SPV clients.
Yes you'd either need a way to add those transactions to the bloom filter,
or add/modify a p2p message to request it specifically.
> when you mention Sybil attack, I don't quite fol
I described an alternative way for SPV wallets to learn about fees some
time ago. It requires a new transaction version that embeds output values
into the signed data. Then an upgrade to the P2P protocol to send UTXO data
along with transactions when they are relayed.
The idea is that the wallet s
On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine wrote:
>
> > It could be done by agreeing on a data format and encoding it in an
> > op_return output in the coinbase transaction. If it catches on it could
> > later be enforced with a
On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine wrote:
> It could be done by agreeing on a data format and encoding it in an
> op_return output in the coinbase transaction. If it catches on it could
> later be enforced with a soft fork.
>
>
Sounds plausible, except SPV protocols would need to incl
It could be done by agreeing on a data format and encoding it in an
op_return output in the coinbase transaction. If it catches on it could
later be enforced with a soft fork.
For real up-to-the-minute fee calculations you're also going to want to
look at the current mempool, how many transactions
16 matches
Mail list logo
