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.
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 solution?
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.
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
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
It could be done by agreeing on a data format and encoding it in an
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
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
Mail list logo