The merchant wants to include a fee to ensure the transaction is
confirmed which is dependent on the fee per kilobyte, but they don't
want to pay unexpectedly high fees. So what about including a
min_fee_per_kilobyte and a max_fee in PaymentDetails describing what
fees the merchant will pay.
I don't think choosing the block with the lowest hash is the best
option. The good and bad miners have an equal probability of finding a
lower hash. But after Alice finds a block she can easily determine the
probability that someone else will find a lower hash value that meets
the difficulty
On 11/05/2013 08:03 PM, Drak wrote:
On 5 November 2013 22:07, Quinn Harris btc...@quinnharris.me
mailto:btc...@quinnharris.me wrote:
I don't think choosing the block with the lowest hash is the best
option. The good and bad miners have an equal probability of
finding a
lower
them too many times before.
On 21 May 2013 10:45, Quinn Harris btc...@quinnharris.me
mailto:btc...@quinnharris.me wrote:
The current BitCoin implementation is subject to relatively easy
double
spend attack for 0 confirmation payments. Yet 0 confirmation payments
are needed
4 matches
Mail list logo
