On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine vois...@gmail.com 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
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
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 an
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 is
what
On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd p...@petertodd.org 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 vois...@gmail.com
wrote:
It could be done by agreeing on a data format and encoding it in an
op_return
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
On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine vois...@gmail.com 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
On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine vois...@gmail.com 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
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
10 matches
Mail list logo
