Search content
Sort by
Showing 7 of 7 results by kfreds
Hello all!
Is TXID predictable before transaction broadcast to peers?
Or in other words,can someone choose a certain txid he want when broadcast a transaction?
Is TXID predictable before transaction broadcast to peers?
Or in other words,can someone choose a certain txid he want when broadcast a transaction?
Hi!
Yes, it's a hash based on the content of the transaction. See the bitcoin wiki or this question:
http://bitcoin.stackexchange.com/questions/2859/how-are-transaction-hashes-calculated
The answer to the second question is no. Furthermore that would be an undesirable feature of a hash function. See "preimage attack".
scrubadub, as long as out-of-band communication is ok, you can get the behavior of #2 by using a chain of transactions. No need for a hard fork.
1. Create a transaction Tx1 that spends the amount to an output requiring two pubkeys (sender and receiver). Broadcast.
2. Create a transaction Tx2 that spends the output of Tx1 to an address controlled by the receiver. Add preferred nLockTime, and set the sequence number to < UINT_MAX to not make it final. Sign and send to the receiver.
The receiver waits until Tx1 is in a block, and so the possibility of a Finney attack is gone. The sender has no control over the coins anymore. The coins are spendable to the receiver after nLockTime by first broadcasting Tx2.
A similar one to this and other fun constructs can be found in the article Contracts on the wiki
Mike, isn't this what you meant? Why do you say the risk of a Finney is reduced, and not gone?
// Fredrik
1. Create a transaction Tx1 that spends the amount to an output requiring two pubkeys (sender and receiver). Broadcast.
2. Create a transaction Tx2 that spends the output of Tx1 to an address controlled by the receiver. Add preferred nLockTime, and set the sequence number to < UINT_MAX to not make it final. Sign and send to the receiver.
The receiver waits until Tx1 is in a block, and so the possibility of a Finney attack is gone. The sender has no control over the coins anymore. The coins are spendable to the receiver after nLockTime by first broadcasting Tx2.
A similar one to this and other fun constructs can be found in the article Contracts on the wiki
Mike, isn't this what you meant? Why do you say the risk of a Finney is reduced, and not gone?
// Fredrik
Is this a full-time position? Meaning, he quit red hat and now working on bitpay 100%?
Sure sounds like it.
Quote
The job at BitPay will allow him to work full-time on Bitcoin, BitPay, and related open-source projects to benefit the Bitcoin community.
Re: 2013-05-14 HuffPo: Bitcoins: A Positive Step Towards Truly Frictionless Commerce
He gets it.
Good and fairly short article. Just one thing though:
Try 10% or more in some cases. That's the reality of small credit card payments
Good and fairly short article. Just one thing though:
Quote
Still more significant is the ongoing transactional cost -- up to 6%,
Try 10% or more in some cases. That's the reality of small credit card payments
I hope this is enough to authenticate me as past the newbie stage:
Bitcoin is a distributed timestamp server for contracts. It uses a programming language similar to Forth to describe the conditions under which bitcoin in a transaction can be spent (used by another transaction).
Now please get me out of here so I can reply to threads in the technical forum
Bitcoin is a distributed timestamp server for contracts. It uses a programming language similar to Forth to describe the conditions under which bitcoin in a transaction can be spent (used by another transaction).
Now please get me out of here so I can reply to threads in the technical forum