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. T
On 11/05/2013 08:03 PM, Drak wrote:
On 5 November 2013 22:07, Quinn Harris <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 ha
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
What if a transaction is tagged as eligible for replace by fee possibly
using the lock_time (0xFFFE) so the parties involved can decide
which approach works best for them. If the receiving side doesn't see
the type of transaction they want they consider it invalid. The payment
protocol ca
long as we haven't heard them too many times before.
On 21 May 2013 10:45, Quinn Harris <mailto:btc...@quinnharris.me>> wrote:
The current BitCoin implementation is subject to relatively easy
double
spend attack for 0 confirmation payments. Yet 0 confirmation paymen
The current BitCoin implementation is subject to relatively easy double
spend attack for 0 confirmation payments. Yet 0 confirmation payments
are needed for typical in person transactions like most purchases at a
local business.
Notably, it is easy to transmit two transactions from the same ou
Could this modularization effort lead to a special compiled bitcoind
simulator that runs many virtual instances of a node on the same system
(possibly same process)? The simulator would cache crypto computation
results (ECDSA, SSH-256) to significantly speed up processing
transactions and block
7 matches
Mail list logo
