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
Summary
---
The BIP66 soft-fork recently passed the 75% support threshold. This
means that 75% of the hashing power has upgraded to support BIP66; 25%
of the hashing power has not. Once 95% of the hashing power has
upgraded, blocks created by the 5% who have not upgraded will be
rejected.
If
> 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
On Wed, Jun 10, 2015 at 09:36:23PM +0300, s7r wrote:
> The mail list is public, so it's not like the data on it is somehow
> sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
> the message and sort/order them as you want, etc.
>
> Why would you want to move to a paid solutio
11 matches
Mail list logo
