Search content
Sort by
Showing 20 of 20 results by halftimepad
Bitcoin programming capabilities with script are interesting, but a bit limited. You can play with most on the testnet, but there are still disabled opcodes (usually for good reason):
https://en.bitcoin.it/wiki/Script
Is there any altcoin out there that has an extended set of opcodes in script to do different things that Bitcoin?
It could be anything from accepting some of the disabled opcodes to using new primitives.
https://en.bitcoin.it/wiki/Script
Is there any altcoin out there that has an extended set of opcodes in script to do different things that Bitcoin?
It could be anything from accepting some of the disabled opcodes to using new primitives.
The main-net puzzle has been solved https://blockchain.info/tx/f00f5da308a948aa019de92428c7fa1c89587414f56beee7074135d46dad793d
And there is a new puzzle
http://blockexplorer.com/testnet/tx/44b9f9ff28fbfc33d4824729b2ec6f2929588faef81717e194fd7fe2a6b5d384
And there is a new puzzle
http://blockexplorer.com/testnet/tx/44b9f9ff28fbfc33d4824729b2ec6f2929588faef81717e194fd7fe2a6b5d384
I don't think you can spend the second output of the transaction. The script is:
OP_HASH256 OP_HASH256 0 ffffffffffffffffffffffffffffffffffffffffffff OP_WITHIN
It seems the sender wanted a problem similar to mining: find a string with a low hash and get the reward.
But OP_WITHIN and all the arithmetic operators only work for inputs of up to 4 bytes. Quoting from
https://en.bitcoin.it/wiki/Script#Arithmetic
"If any input value for any of these commands is longer than 4 bytes, the script must abort and fail."
ffffffffffffffffffffffffffffffffffffffffffff has 22 bytes. OP_WITHIN will cause the script to fail, no matter what inputs you choose. These bitcoins are irredeemable.
Thanks! I couldn't find my way around the older versions.
The dates are strange. What happens if you start working on a branch and then make it a release? I guess you can create a fork, work on it and then that code becomes the new release. That would explain the commits before the release, but I'm not really familiar with the fine detail of github.
The dates are strange. What happens if you start working on a branch and then make it a release? I guess you can create a fork, work on it and then that code becomes the new release. That would explain the commits before the release, but I'm not really familiar with the fine detail of github.
I was curious and wanted to check how the disabled opcodes of script were implemented in the earlier versions of the bitcoin client.
In github I can only find versions back to bitcoin 0.8.
Is there any repository with the old code?
In github I can only find versions back to bitcoin 0.8.
Is there any repository with the old code?
Re: Getting tx data from tx hash, and getting all unconfirmd txs (mempool) from API?
If you use bitcoin-qt you can use the command line.
https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments
Most clients have a version. With the interface you can find the console under ->Help. You can also launch a server:
bitcoind -server
and then use bitcoin-cli
The commands you want are:
bitcoin-cli getrawtransaction HASH
(gets hexadecimal byte sequence in hexadecimal)
bitcoin-cli getrawtransaction HASH 1
(gets the JSON-parsed version)
bitcoin-cli getrawmempool
(gives the mempool at your local node)
If you access the console from bitcoin-qt, drop bitcoin-cli.
You can also find an online mempool explorer in:
http://webbtc.com/mempool
https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments
Most clients have a version. With the interface you can find the console under ->Help. You can also launch a server:
bitcoind -server
and then use bitcoin-cli
The commands you want are:
bitcoin-cli getrawtransaction HASH
(gets hexadecimal byte sequence in hexadecimal)
bitcoin-cli getrawtransaction HASH 1
(gets the JSON-parsed version)
bitcoin-cli getrawmempool
(gives the mempool at your local node)
If you access the console from bitcoin-qt, drop bitcoin-cli.
You can also find an online mempool explorer in:
http://webbtc.com/mempool
I believe core version 0.10.0+ uses deterministic k-value generation following the guidelines in RFC6979. The code for this is in the newly used libsecp256k1.
It you want to make random k-values, rollback to a version using openssl, or write your own code.
Note that if you generate R-values or S-values that are too high, the network will or may reject them (as detailed in BIP0062).
It you want to make random k-values, rollback to a version using openssl, or write your own code.
Note that if you generate R-values or S-values that are too high, the network will or may reject them (as detailed in BIP0062).
Thank you! That was interesting!
After reading the RFC I have seen the value of k changes with the message. With that, I could pull a low-effort solution to get different signatures with getrawtransaction by changing the fee by a small amount.
I'm signing raw transaction with signrawtransaction using bitcoin-cli (Bitcoin Core).
Even if you repeat the same transaction, each signature should be created with a different random value k which gives the first part of the signature (r).
I'm sure this is what happens once a transaction is sent (otherwise there would be massive theft), but in the command line, when I call signrawtransaction more than once for the same transaction I always get the same signature. I would like to generate different valid signatures for the same transaction.
So, when/how does the client decide it is time for a new value of k? Should I create some code to sign my transactions from scratch or is there a way to force a new k using signrawtransaction?
Even if you repeat the same transaction, each signature should be created with a different random value k which gives the first part of the signature (r).
I'm sure this is what happens once a transaction is sent (otherwise there would be massive theft), but in the command line, when I call signrawtransaction more than once for the same transaction I always get the same signature. I would like to generate different valid signatures for the same transaction.
So, when/how does the client decide it is time for a new value of k? Should I create some code to sign my transactions from scratch or is there a way to force a new k using signrawtransaction?
Is there any part of the Bitcoin protocol that establishes a limit on the maximum number of op_codes in a script?
Playing in the testnet I have recently hit the limit of script operations for the bitcoin core client. After digging a bit I found in line 276 of
https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp
So for non-standard transactions, there is a limit to 201 operations beside pushing a number from 0 to 16 to the stack (and similar limits inside other types of transactions).
I cannot find any discussion or explanation on why exactly 201 operations. The limit to multisign signatures to avoid attacks is more or less clear to me (and I have found a clear-cut limit https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size), but for lightweight operations (OP_ADD and the like) I cannot find any explanation on the limit and the exact 201 value.
More on that:
I tested two transactions:
94285d9867b0c008b03467164d89451e732fe8243890dd04164633c5e403777d with a long redeem condition and
4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdb that should fulfill it.
If I try to broadcast the second transaction with bitcoin-cli I get the message:
However, I was able to push it to the mempool of a Ruby client:
http://test.webbtc.com/mempool_tx/4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdb
It seems stuck there as no miners will accept it. Could this create a fork if the transaction is added to a block by a Ruby miner? I guess this is unlikely as you would need a large mining power on the alternative client. In that case, would my first transaction really be irredeemable in the current network or get stuck in an orphaned block?
Am I missing anything?
Playing in the testnet I have recently hit the limit of script operations for the bitcoin core client. After digging a bit I found in line 276 of
https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp
Quote
if (opcode > OP_16 && ++nOpCount > 201)
return set_error(serror, SCRIPT_ERR_OP_COUNT);
return set_error(serror, SCRIPT_ERR_OP_COUNT);
So for non-standard transactions, there is a limit to 201 operations beside pushing a number from 0 to 16 to the stack (and similar limits inside other types of transactions).
I cannot find any discussion or explanation on why exactly 201 operations. The limit to multisign signatures to avoid attacks is more or less clear to me (and I have found a clear-cut limit https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size), but for lightweight operations (OP_ADD and the like) I cannot find any explanation on the limit and the exact 201 value.
More on that:
I tested two transactions:
94285d9867b0c008b03467164d89451e732fe8243890dd04164633c5e403777d with a long redeem condition and
4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdb that should fulfill it.
If I try to broadcast the second transaction with bitcoin-cli I get the message:
Quote
error: {"code":-26,"message":"16: mandatory-script-verify-flag-failed (Operation limit exceeded)"}
However, I was able to push it to the mempool of a Ruby client:
http://test.webbtc.com/mempool_tx/4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdb
It seems stuck there as no miners will accept it. Could this create a fork if the transaction is added to a block by a Ruby miner? I guess this is unlikely as you would need a large mining power on the alternative client. In that case, would my first transaction really be irredeemable in the current network or get stuck in an orphaned block?
Am I missing anything?
My bad. That isn't strictly necessary. I just wanted to know if there was a way to make some information public and send the coins to the discoverer.
Sure. Just have them be searching for the private key that controls the funds. There have been a couple contests similar to that on these boards, though I don't have the time to dig them all up right now.That's an option, but I wanted that no one could get the coins without making the solution public. But then we get back to the problem of the nodes capturing the transmission. I see there would be double-spend-like conflicts unless you add some protection...
Script is probably too limited to express a program that can check solutions to interesting computational problems, but you may be interested in this:
https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state
That's a nice addition. My original idea was minimizing trust in anything that is not the Bitcoin network, but, for certain things, access to an external arbiter might be necessary.
Your scripts look like you're trying to require both a private key and a password.
My bad. That isn't strictly necessary. I just wanted to know if there was a way to make some information public and send the coins to the discoverer.
Even without the race condition issues (you could give it directly to a trusted miner), such transactions have the problem that if anyone guesses it's a password protected output they can try to brute force it. Many users would select weak passwords that were too short to withstand brute forcing and lose their money. It's not a good idea to encourage such usage patterns.
In some scenarios I had in mind, as long as the correct answer is given, it wouldn't be so important to have brute force attacks. The coins would not be supposed to be for someone in particular, but for anyone who could give the answer and made it public. Anyway, to prevent dictionary attacks I thought you could add some salt, like in password checking in computers.
Take for instance a "computational race" similar to mining. You could give a prize to whomever found first a string with a hash between two values (a given header, like in mining). With script, it seems you could do it.
I was also thinking in solutions to problems that are hard to compute, but also easy to check (like NP problems). You could offer a reward for a solution which checks right. You wouldn't mind brute force attacks, in fact you would encourage them.
Anyway, if nonstandard script is used, I guess you need trusted miners anyway. I was just curious if you could do this kind of thing with minimal trust, using the regular network.
Using script you could, in principle, use password-based transactions, where only someone who knows a password can spend the coins. A hash would mask the password in the input transaction.
I expect a code like:
would be enough. I asked if this was possible (http://bitcoin.stackexchange.com/questions/5510/password-based-bitcoin-transactions) and was pointed out that it is not so secure. An intermediate relaying node that sees the transaction could try to outrun the legitimate spender and spend the coins.
Does anyone know how risky this is or if there are any ways to improve the system? My original idea was having a simple "contract" that transfers the coins only if certain information is made public (think for instance about an on-line contest). So the alternative should preserve the public part.
I have recently found a similar problem when discussing quantum computers, or, more generally, what happens if there appears an algorithm that can deduce the private key from the public key of a user.
https://bitcointalk.org/index.php?topic=133425.0
If you use addresses, the hashing will reduce the attacks to the equivalent of the password transaction I mention and is also relevant to the robustness of the Bitcoin system as a whole.
I expect a code like:
Code:
scriptPubKey: OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptSig:
scriptSig:
would be enough. I asked if this was possible (http://bitcoin.stackexchange.com/questions/5510/password-based-bitcoin-transactions) and was pointed out that it is not so secure. An intermediate relaying node that sees the transaction could try to outrun the legitimate spender and spend the coins.
Does anyone know how risky this is or if there are any ways to improve the system? My original idea was having a simple "contract" that transfers the coins only if certain information is made public (think for instance about an on-line contest). So the alternative should preserve the public part.
I have recently found a similar problem when discussing quantum computers, or, more generally, what happens if there appears an algorithm that can deduce the private key from the public key of a user.
https://bitcointalk.org/index.php?topic=133425.0
If you use addresses, the hashing will reduce the attacks to the equivalent of the password transaction I mention and is also relevant to the robustness of the Bitcoin system as a whole.
I finally did it!
Testnet3 transaction: 33924d240e571f633ee2ea64ffd917d0c6a9a995b670740e54c5bc954f6f33bd
Thank you all for the help. The standard client shows it alright and works as expected.
Testnet3 transaction: 33924d240e571f633ee2ea64ffd917d0c6a9a995b670740e54c5bc954f6f33bd
Thank you all for the help. The standard client shows it alright and works as expected.
Forgive me if I'm wrong, but in a world where quantum computing becomes actually prevalent, as opposed to just plainly possible in a laboratory setting, there is nothing to stop Bitcoin from leveraging QC for it's encryption. This would kind of ruins the argument of ever more sophisticated QC cracking current cryptography; the new cryptographic possibilities that QC could achieve will eventually be available to the Bitcoin dev team, as well as the general public.
I'm not so sure about that. In Bitcoin you need a public key cryptosystem. In elliptic curve cryptography, the trick is that the direct problem (computing the public key or the signature) is easy if you know the private key. However, if you have the public key there is no known efficient method to deduce the private key (with a classical computer).
If everyone had quantum computers, both problems would become easy. You cannot simply scale the numbers as you would with hashing. You need asymmetry.
There are a few alternatives under study:
http://en.wikipedia.org/wiki/Post-quantum_cryptography
The important point is that, as opposed to symmetric systems, where you can just scale everything, you need some asymmetric problem. With quantum computers there are less available problems like that.
Speaking of, here is an exercise for you: why must the locktime be an absolute number? Why can't it be a relative number?
Uhm... I would think it is because you can never be sure which block will carry your transaction. I guess an absolute number gives you an approximate date. Roughly, you can imagine a block will appear each ten minutes and the transaction will be accepted around the time you include in the timestamp.
Quote
The reason why you were able to spend that tx is because of this. What you've done is made a transaction that can't be spent in any block before block #3, which was over four years ago.
What did you expect to happen?
What did you expect to happen?
Quote
obviously you misunderstand the meaning of nlocktime. The value refers to the absolute block height, a relative one. Your example means "locked after block height = 3", not "locked 3 blocks later"
Ouch! How embarrassing!
Thank you, that's it!
There are two parts in the security of Bitcoin which could be affected by quantum computers.
One is the security of the elliptic curve cryptography system used when signing transactions. A quantum computer could deduce the private key (and take the funds) if it knows the public key. The private key can be computed solving the discrete logarithm problem, which is efficient in a quantum computer. It would just need a variation of Shor's factoring algorithm:
http://www.math.uwaterloo.ca/~amchilds/teaching/w08/l03.pdf
But, as Etotheipi says, if you only use your address except for spending, the public key is only used once, when you use the funds. The hashing will mask your public key and protect the secret one. There might be a problem if some node see your public key and tries to outrun you and send other transactions and the public keys already in the blockchain would be vulnerable, but I doubt a quantum computer will appear overnight. The system would have time to change to something else.
The second thing is the hash. Grover's algorithm could be used, with some problems, but it is not necessarily the best you can do. There are bounds you can apply directly to collision finding (finding two sequences which hash to the same value). Collision finding (necessary to replace blocks) is not efficient in quantum computers:
http://arxiv.org/abs/quant-ph/0111102
You could reduce difficulty, but not so much (at most is like having one fifth of the bits). The impact for a long chain seems small. The model is not completely general, but gives a good taste of what to expect. As far as I know, hash collisions have been studied a lot and this is the best result.
In any case, I think it would be easier to pull a 51% attack amassing a lot of computer power than building a scalable quantum computer, at least in the short/medium term.
Notice that, anyway, the discrete logarithm problem and finding collisions for SHA256 are only SUPPOSED to be hard for classical computers. There is no guarantee that there isn't algorithm that could break elliptic curve cryptography, factor large numbers or find collisions (there could be trapdoor in SHA256). Of course, a lot of people have been trying without success and I think they are probably safe.
One is the security of the elliptic curve cryptography system used when signing transactions. A quantum computer could deduce the private key (and take the funds) if it knows the public key. The private key can be computed solving the discrete logarithm problem, which is efficient in a quantum computer. It would just need a variation of Shor's factoring algorithm:
http://www.math.uwaterloo.ca/~amchilds/teaching/w08/l03.pdf
But, as Etotheipi says, if you only use your address except for spending, the public key is only used once, when you use the funds. The hashing will mask your public key and protect the secret one. There might be a problem if some node see your public key and tries to outrun you and send other transactions and the public keys already in the blockchain would be vulnerable, but I doubt a quantum computer will appear overnight. The system would have time to change to something else.
The second thing is the hash. Grover's algorithm could be used, with some problems, but it is not necessarily the best you can do. There are bounds you can apply directly to collision finding (finding two sequences which hash to the same value). Collision finding (necessary to replace blocks) is not efficient in quantum computers:
http://arxiv.org/abs/quant-ph/0111102
You could reduce difficulty, but not so much (at most is like having one fifth of the bits). The impact for a long chain seems small. The model is not completely general, but gives a good taste of what to expect. As far as I know, hash collisions have been studied a lot and this is the best result.
In any case, I think it would be easier to pull a 51% attack amassing a lot of computer power than building a scalable quantum computer, at least in the short/medium term.
Notice that, anyway, the discrete logarithm problem and finding collisions for SHA256 are only SUPPOSED to be hard for classical computers. There is no guarantee that there isn't algorithm that could break elliptic curve cryptography, factor large numbers or find collisions (there could be trapdoor in SHA256). Of course, a lot of people have been trying without success and I think they are probably safe.
Thank you all for the explanations!
I have already been playing with raw transactions in the testnet with bitcoind. After a few false starts (I still have some trouble with the change and I forgot about the sequence number) I think I have managed to send some transactions with a lock time.
I'm still a bit confused, because right after sending them, I could spend the coins in another transaction. Here is an example transaction:
The sequence number is a bit strange because I just replaced an f by a 0 in the hex transaction, but I think it is OK.
I will continue playing and post the results. I might be doing something else wrong.
I have already been playing with raw transactions in the testnet with bitcoind. After a few false starts (I still have some trouble with the change and I forgot about the sequence number) I think I have managed to send some transactions with a lock time.
I'm still a bit confused, because right after sending them, I could spend the coins in another transaction. Here is an example transaction:
Code:
{
"hex" : "0100000001b110f593f3f4b0a9f93fd625d5e455c82b7ec0a5fe491198ac0bdf042bc837c8000000006b48304502207501c32e46cfba0ac5aae64849a34107c2a30291448604d0c207ae7c0a05c65d022100f914d06a0f64331d0b6ba931d62db2257293c199d4541bbb02266cf0fa1272f50121035ecd174d977eecdda204fd52be159469b77399f8f19894a70b72216197525782fff0ffff0100d2496b000000001976a914be42ebf8ab45f191de4703213a093510b825959188ac03000000",
"txid" : "251a368ff8a663f8d1ce55ce1f3dbd49ce2fbd9f1a270dc4ef9decf3c4a3461e",
"version" : 1,
"locktime" : 3,
"vin" : [
{
"txid" : "c837c82b04df0bac981149fea5c07e2bc855e4d525d63ff9a9b0f4f393f510b1",
"vout" : 0,
"scriptSig" : {
"asm" : "304502207501c32e46cfba0ac5aae64849a34107c2a30291448604d0c207ae7c0a05c65d022100f914d06a0f64331d0b6ba931d62db2257293c199d4541bbb02266cf0fa1272f501 035ecd174d977eecdda204fd52be159469b77399f8f19894a70b72216197525782",
"hex" : "48304502207501c32e46cfba0ac5aae64849a34107c2a30291448604d0c207ae7c0a05c65d022100f914d06a0f64331d0b6ba931d62db2257293c199d4541bbb02266cf0fa1272f50121035ecd174d977eecdda204fd52be159469b77399f8f19894a70b72216197525782"
},
"sequence" : 4294963455
}
],
"vout" : [
{
"value" : 18.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 be42ebf8ab45f191de4703213a093510b8259591 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914be42ebf8ab45f191de4703213a093510b825959188ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mxrxrJnR2XP889vMz2ewVZ97dvgso6DfF6"
]
}
}
],
"blockhash" : "000000000b5ac111cc15c3b47cc46e877e5b93f250a927a14dddcddf013bfee5",
"confirmations" : 2493,
"time" : 1356543924,
"blocktime" : 1356543924
}
"hex" : "0100000001b110f593f3f4b0a9f93fd625d5e455c82b7ec0a5fe491198ac0bdf042bc837c8000000006b48304502207501c32e46cfba0ac5aae64849a34107c2a30291448604d0c207ae7c0a05c65d022100f914d06a0f64331d0b6ba931d62db2257293c199d4541bbb02266cf0fa1272f50121035ecd174d977eecdda204fd52be159469b77399f8f19894a70b72216197525782fff0ffff0100d2496b000000001976a914be42ebf8ab45f191de4703213a093510b825959188ac03000000",
"txid" : "251a368ff8a663f8d1ce55ce1f3dbd49ce2fbd9f1a270dc4ef9decf3c4a3461e",
"version" : 1,
"locktime" : 3,
"vin" : [
{
"txid" : "c837c82b04df0bac981149fea5c07e2bc855e4d525d63ff9a9b0f4f393f510b1",
"vout" : 0,
"scriptSig" : {
"asm" : "304502207501c32e46cfba0ac5aae64849a34107c2a30291448604d0c207ae7c0a05c65d022100f914d06a0f64331d0b6ba931d62db2257293c199d4541bbb02266cf0fa1272f501 035ecd174d977eecdda204fd52be159469b77399f8f19894a70b72216197525782",
"hex" : "48304502207501c32e46cfba0ac5aae64849a34107c2a30291448604d0c207ae7c0a05c65d022100f914d06a0f64331d0b6ba931d62db2257293c199d4541bbb02266cf0fa1272f50121035ecd174d977eecdda204fd52be159469b77399f8f19894a70b72216197525782"
},
"sequence" : 4294963455
}
],
"vout" : [
{
"value" : 18.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 be42ebf8ab45f191de4703213a093510b8259591 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914be42ebf8ab45f191de4703213a093510b825959188ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mxrxrJnR2XP889vMz2ewVZ97dvgso6DfF6"
]
}
}
],
"blockhash" : "000000000b5ac111cc15c3b47cc46e877e5b93f250a927a14dddcddf013bfee5",
"confirmations" : 2493,
"time" : 1356543924,
"blocktime" : 1356543924
}
The sequence number is a bit strange because I just replaced an f by a 0 in the hex transaction, but I think it is OK.
I will continue playing and post the results. I might be doing something else wrong.
⭐ Merited by ETFbitcoin (1)
Hello all. I'm new in the Bitcoin community and I have a particular interest in contracts, Script and all the new possibilities that usual currencies don't have.
I have been looking into some features like the ability to delay payments. In principle, transactions have a lock time that can be used to delay transactions.
https://en.bitcoin.it/wiki/Protocol_specification#tx
There are some interesting uses in contracts in transaction replacement, but this ability seems to be disabled at the moment http://bitcoin.stackexchange.com/questions/861/why-isnt-transaction-replacement-supported.
I have made a small block explorer based on bitcointools (https://github.com/gavinandresen/bitcointools) to find transactions with a lock_time value different from 0 and have found five transactions that do have a wait time. They are in blocks:
000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c
000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05
00000000000005f229df518de50c53616f4f2f895deca078dce1d74d5b79e39c
000000000000026e8536f6ffe741feeb30d7123e6435b3ad7db141833969b5bf
00000000000001d985839442aac0179713fc7f6e5b109d524a272d3d55600d7a
The transactions are:
http://blockexplorer.com/rawblock/000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c
{
"hash":"13e100dd08b6da0a7426ea520b0bb3ae54cef79dd045e2e4f7116023df3a5c95",
"ver":1,
"vin_sz":1,
"vout_sz":1,
"lock_time":198370,
"size":191,
"in":[
{
"prev_out":{
"hash":"8af03f89f3e774ba64890b6f491f43b30de5f8c5e1d92fcad1e3355c566fd21d",
"n":1
},
"scriptSig":"304402204427e4bcb2bd48bf5d25dc3c7fde90df5b6e8ad39f62ddf1ad2bf82c33bb7f170220494ac767bbbe269eb8c352c8698ed24f2be09ee5d4e5f6a5d7cf69e709c28f1201 021669049d34ea3a8e364710151de215f15a74947ab87b8952ab062ed106c37bf6"
}
],
"out":[
{
"value":"0.01500000",
"scriptPubKey":"OP_DUP OP_HASH160 46186d1c563e4507b102aa0e5e3b9ef0a9077de3 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05
{
"hash":"34df83aea6d6a68bab10b01e4ec4043850855406d45589b907dea565c8439976",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":199000,
"size":341,
"in":[
{
"prev_out":{
"hash":"69d771de96b5e0b7e66bc47f13eeedb96c45636bb3853637852b536b8959026a",
"n":0
},
"scriptSig":"3046022100ea4a9a35edbfa63327a68ef33b151da6a824ba86119c2fb2e69ccfa676cbf55d022100d8071b560b35585bee1249ba27e4cd9b61229c4bad6a5e2482982ea98e59215f01 024931bfb3b26c333c180a9dce4892035f58468cb1bd0b5e2159f5834101672a40"
},
{
"prev_out":{
"hash":"69d771de96b5e0b7e66bc47f13eeedb96c45636bb3853637852b536b8959026a",
"n":1
},
"scriptSig":"304502207674f68e100d65b0f29316b0d643d3e6c9410da056102ab305d4ea8f229f5c56022100ddbd064ae427f4db44fc8cefd45e837e35264b276ed8007fbf293301b22bd82901 025145729dd299d26dd21244e04df616a6083e80e2604153d1ec9b20dc79d1f4e2"
}
],
"out":[
{
"value":"0.01450000",
"scriptPubKey":"OP_DUP OP_HASH160 1bec313498b523aadb2964ab6d95608a911f4eeb OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/00000000000005f229df518de50c53616f4f2f895deca078dce1d74d5b79e39c
{
"hash":"b0fa60f601d5fe6fb1501aa614503b9af688492f68bcf8268d7cdb30f3534079",
"ver":1,
"vin_sz":1,
"vout_sz":1,
"lock_time":199000,
"size":192,
"in":[
{
"prev_out":{
"hash":"4ac2fd4616a400ea29ad5eaff723d18ca05e4c22e4c9a190b8ab7b09d8964f99",
"n":0
},
"scriptSig":"3045022006f942260b9587f8976fc31de7c238e4998e6f0afbf026568c41f732de672473022100f30f27305dc27b3435b5803fe72d0dacf8c845b402959d192d27de96f5fcd90601 03e71226d01c0186a3995446089d41ce90d08cf384f5a1c906239e540221efc683",
"sequence":4278190335
}
],
"out":[
{
"value":"0.01350000",
"scriptPubKey":"OP_DUP OP_HASH160 87965d6172fcc30cbbdfd1b674d66d567e64bb53 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/000000000000026e8536f6ffe741feeb30d7123e6435b3ad7db141833969b5bf
{
"hash":"c466c6f8ee76ac77495f703aa5646926d67730ea7a8ede45debf3be37c9ffe7b",
"ver":1,
"vin_sz":2,
"vout_sz":2,
"lock_time":207150,
"size":373,
"in":[
{
"prev_out":{
"hash":"a8f8a86ebc2c9eb8989a6e988238cfa37ffc5634bd8a216a19a63ae7bb84e352",
"n":0
},
"scriptSig":"304502206bbfb4f4c700b25d7e7c6627a43c6b6ef5c2e449c8c3cf0e729a08fd6b8e4d3f022100de614f17b6f2ddcf0c9cb5c9259ccbcf38fc7bc529c261166651072eee8de3a901 0372517b2117c312844838b6cb79959ab6dfb3357e7c7e8ead94e438091039f72d",
"sequence":0
},
{
"prev_out":{
"hash":"a8f8a86ebc2c9eb8989a6e988238cfa37ffc5634bd8a216a19a63ae7bb84e352",
"n":1
},
"scriptSig":"304402207dd414f7c962b67378bf659c7f38fd96a32e9c6d245479ce9f37595f6673e51f02202ea6355791b2b945694916baec0139ba6a807c35cc72b6e96ccaee21bb00409001 0346559defaa3a93fe93eb38af8f10ac060a39b2f5b1b18a932aaba39746e9f36f",
"sequence":0
}
],
"out":[
{
"value":"0.00050000",
"scriptPubKey":"OP_DUP OP_HASH160 f1ddb423647b717589222293108b3a71f6c9c479 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value":"0.00022074",
"scriptPubKey":"OP_DUP OP_HASH160 0c7d886ae9a809429e962458f8b86ecb7ae2b730 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/00000000000001d985839442aac0179713fc7f6e5b109d524a272d3d55600d7a
{
"hash":"d1ef46055a84fd02ee82580d691064780def18614d98646371c3448ca20019ac",
"ver":1,
"vin_sz":1,
"vout_sz":2,
"lock_time":207167,
"size":226,
"in":[
{
"prev_out":{
"hash":"18a3db0f83fd7407f1a286af161703e19f5ea800944e9c273c02f3d2cd106a33",
"n":1
},
"scriptSig":"3045022016dfc9cd05189641188b7f8ca8336d30c6dd4750766060437f16c384c4e9756a022100cbc2906d947e131bdf5e8a685df7ae869d3a92fdc7d0198cd7756ecf7f3fecef01 0372517b2117c312844838b6cb79959ab6dfb3357e7c7e8ead94e438091039f72d",
"sequence":0
}
],
"out":[
{
"value":"0.00050000",
"scriptPubKey":"OP_DUP OP_HASH160 2aacd8e8e3607cadd993eaf20047b3ba051049b5 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value":"0.00900000",
"scriptPubKey":"OP_DUP OP_HASH160 71b13ab7f1f5b1e7ed1b3df8c2b57eef083cf3fb OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
It seems none of them will be able to be redeemed for a long time.
I have a few questions:
- This ability looks like a feature to me, but it seems clients shouldn't allow this kind of transaction and some people treat this as a bug:
http://bitcoin.stackexchange.com/questions/5783/transactions-with-a-wait-time-using-nlocktime/5833#5833
https://github.com/bitcoin/bitcoin/issues/1820
Are locked transactions supposed to be supported or not?
- If not, what will happen to the already existing locked transactions?
- Can you easily introduce a locked transaction using the standard client? If not, how?
Thanks!
I have been looking into some features like the ability to delay payments. In principle, transactions have a lock time that can be used to delay transactions.
https://en.bitcoin.it/wiki/Protocol_specification#tx
There are some interesting uses in contracts in transaction replacement, but this ability seems to be disabled at the moment http://bitcoin.stackexchange.com/questions/861/why-isnt-transaction-replacement-supported.
I have made a small block explorer based on bitcointools (https://github.com/gavinandresen/bitcointools) to find transactions with a lock_time value different from 0 and have found five transactions that do have a wait time. They are in blocks:
000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c
000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05
00000000000005f229df518de50c53616f4f2f895deca078dce1d74d5b79e39c
000000000000026e8536f6ffe741feeb30d7123e6435b3ad7db141833969b5bf
00000000000001d985839442aac0179713fc7f6e5b109d524a272d3d55600d7a
The transactions are:
Code:
http://blockexplorer.com/rawblock/000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c
{
"hash":"13e100dd08b6da0a7426ea520b0bb3ae54cef79dd045e2e4f7116023df3a5c95",
"ver":1,
"vin_sz":1,
"vout_sz":1,
"lock_time":198370,
"size":191,
"in":[
{
"prev_out":{
"hash":"8af03f89f3e774ba64890b6f491f43b30de5f8c5e1d92fcad1e3355c566fd21d",
"n":1
},
"scriptSig":"304402204427e4bcb2bd48bf5d25dc3c7fde90df5b6e8ad39f62ddf1ad2bf82c33bb7f170220494ac767bbbe269eb8c352c8698ed24f2be09ee5d4e5f6a5d7cf69e709c28f1201 021669049d34ea3a8e364710151de215f15a74947ab87b8952ab062ed106c37bf6"
}
],
"out":[
{
"value":"0.01500000",
"scriptPubKey":"OP_DUP OP_HASH160 46186d1c563e4507b102aa0e5e3b9ef0a9077de3 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05
{
"hash":"34df83aea6d6a68bab10b01e4ec4043850855406d45589b907dea565c8439976",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":199000,
"size":341,
"in":[
{
"prev_out":{
"hash":"69d771de96b5e0b7e66bc47f13eeedb96c45636bb3853637852b536b8959026a",
"n":0
},
"scriptSig":"3046022100ea4a9a35edbfa63327a68ef33b151da6a824ba86119c2fb2e69ccfa676cbf55d022100d8071b560b35585bee1249ba27e4cd9b61229c4bad6a5e2482982ea98e59215f01 024931bfb3b26c333c180a9dce4892035f58468cb1bd0b5e2159f5834101672a40"
},
{
"prev_out":{
"hash":"69d771de96b5e0b7e66bc47f13eeedb96c45636bb3853637852b536b8959026a",
"n":1
},
"scriptSig":"304502207674f68e100d65b0f29316b0d643d3e6c9410da056102ab305d4ea8f229f5c56022100ddbd064ae427f4db44fc8cefd45e837e35264b276ed8007fbf293301b22bd82901 025145729dd299d26dd21244e04df616a6083e80e2604153d1ec9b20dc79d1f4e2"
}
],
"out":[
{
"value":"0.01450000",
"scriptPubKey":"OP_DUP OP_HASH160 1bec313498b523aadb2964ab6d95608a911f4eeb OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/00000000000005f229df518de50c53616f4f2f895deca078dce1d74d5b79e39c
{
"hash":"b0fa60f601d5fe6fb1501aa614503b9af688492f68bcf8268d7cdb30f3534079",
"ver":1,
"vin_sz":1,
"vout_sz":1,
"lock_time":199000,
"size":192,
"in":[
{
"prev_out":{
"hash":"4ac2fd4616a400ea29ad5eaff723d18ca05e4c22e4c9a190b8ab7b09d8964f99",
"n":0
},
"scriptSig":"3045022006f942260b9587f8976fc31de7c238e4998e6f0afbf026568c41f732de672473022100f30f27305dc27b3435b5803fe72d0dacf8c845b402959d192d27de96f5fcd90601 03e71226d01c0186a3995446089d41ce90d08cf384f5a1c906239e540221efc683",
"sequence":4278190335
}
],
"out":[
{
"value":"0.01350000",
"scriptPubKey":"OP_DUP OP_HASH160 87965d6172fcc30cbbdfd1b674d66d567e64bb53 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/000000000000026e8536f6ffe741feeb30d7123e6435b3ad7db141833969b5bf
{
"hash":"c466c6f8ee76ac77495f703aa5646926d67730ea7a8ede45debf3be37c9ffe7b",
"ver":1,
"vin_sz":2,
"vout_sz":2,
"lock_time":207150,
"size":373,
"in":[
{
"prev_out":{
"hash":"a8f8a86ebc2c9eb8989a6e988238cfa37ffc5634bd8a216a19a63ae7bb84e352",
"n":0
},
"scriptSig":"304502206bbfb4f4c700b25d7e7c6627a43c6b6ef5c2e449c8c3cf0e729a08fd6b8e4d3f022100de614f17b6f2ddcf0c9cb5c9259ccbcf38fc7bc529c261166651072eee8de3a901 0372517b2117c312844838b6cb79959ab6dfb3357e7c7e8ead94e438091039f72d",
"sequence":0
},
{
"prev_out":{
"hash":"a8f8a86ebc2c9eb8989a6e988238cfa37ffc5634bd8a216a19a63ae7bb84e352",
"n":1
},
"scriptSig":"304402207dd414f7c962b67378bf659c7f38fd96a32e9c6d245479ce9f37595f6673e51f02202ea6355791b2b945694916baec0139ba6a807c35cc72b6e96ccaee21bb00409001 0346559defaa3a93fe93eb38af8f10ac060a39b2f5b1b18a932aaba39746e9f36f",
"sequence":0
}
],
"out":[
{
"value":"0.00050000",
"scriptPubKey":"OP_DUP OP_HASH160 f1ddb423647b717589222293108b3a71f6c9c479 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value":"0.00022074",
"scriptPubKey":"OP_DUP OP_HASH160 0c7d886ae9a809429e962458f8b86ecb7ae2b730 OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
http://blockexplorer.com/rawblock/00000000000001d985839442aac0179713fc7f6e5b109d524a272d3d55600d7a
{
"hash":"d1ef46055a84fd02ee82580d691064780def18614d98646371c3448ca20019ac",
"ver":1,
"vin_sz":1,
"vout_sz":2,
"lock_time":207167,
"size":226,
"in":[
{
"prev_out":{
"hash":"18a3db0f83fd7407f1a286af161703e19f5ea800944e9c273c02f3d2cd106a33",
"n":1
},
"scriptSig":"3045022016dfc9cd05189641188b7f8ca8336d30c6dd4750766060437f16c384c4e9756a022100cbc2906d947e131bdf5e8a685df7ae869d3a92fdc7d0198cd7756ecf7f3fecef01 0372517b2117c312844838b6cb79959ab6dfb3357e7c7e8ead94e438091039f72d",
"sequence":0
}
],
"out":[
{
"value":"0.00050000",
"scriptPubKey":"OP_DUP OP_HASH160 2aacd8e8e3607cadd993eaf20047b3ba051049b5 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value":"0.00900000",
"scriptPubKey":"OP_DUP OP_HASH160 71b13ab7f1f5b1e7ed1b3df8c2b57eef083cf3fb OP_EQUALVERIFY OP_CHECKSIG"
}
]
},
It seems none of them will be able to be redeemed for a long time.
I have a few questions:
- This ability looks like a feature to me, but it seems clients shouldn't allow this kind of transaction and some people treat this as a bug:
http://bitcoin.stackexchange.com/questions/5783/transactions-with-a-wait-time-using-nlocktime/5833#5833
https://github.com/bitcoin/bitcoin/issues/1820
Are locked transactions supposed to be supported or not?
- If not, what will happen to the already existing locked transactions?
- Can you easily introduce a locked transaction using the standard client? If not, how?
Thanks!