Unable to decode output address - Non Standard Transaction

[sebicas]

Just saw this today:
http://blockchain.info/tx-index/36310989/cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35

Any idea of that this may be??

{ txid: 'cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35',
  version: 1,
  locktime: 0,
  vin:
   [ { txid: '70c4e749f2b8b907875d1483ae43e8a6790b0c8397bbb33682e3602617f9a77a',
       vout: 0,
       scriptSig: [Object],
       sequence: 4294967295 },
     { txid: 'bdc1df19f8e5c581462119bb7c0cb044e36b9aacc424676d1564c2779d83e7bc',
       vout: 0,
       scriptSig: [Object],
       sequence: 4294967295 } ],
  vout: [ { value: 1, n: 0, scriptPubKey: [Object] } ] }
{ value: 1,
  n: 0,
  scriptPubKey: { asm: '1', hex: '51', type: 'nonstandard' } }

[1715566975]

1715566975

[1715566975]

1715566975

[1715566975]

1715566975

[1715566975]

1715566975

[pc]

I believe that it's just OP_TRUE, which may mean that anybody who can construct the right transaction can claim it. Either that, or it's a mistake somebody made and the coins are lost forever.

[pc]

I tried figuring out how to redeem them, but couldn't get any transactions to be accepted by sendrawtransaction or https://blockchain.info/pushtx even through decoderawtransaction made me think I was doing it right.

But somebody figured out how to take the coins: https://blockchain.info/tx-index/36395409?show_adv=true

[pc]

Somebody's playing an interesting game here… See a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b for another challenge somebody put in the chain to try to claim.

It can be claimed by anybody who can submit data that hashes to 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000, which just happens to be the genesis block hash, so the data is known. I figured out how to make the standard checks in the client just return true and recompiled, so that I could submit the transaction claiming it. Hopefully, my transaction gets to a miner that accepts nonstandard transactions somehow, but it showed up on blockchain.info so I'm hopeful.

I'd like to thank whomever put those bitcoins out there for the taking for inspiring me to learn more about the internal structures of transactions.

[Peter Todd]

Somebody's playing an interesting game here… See a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b for another challenge somebody put in the chain to try to claim.

It can be claimed by anybody who can submit data that hashes to 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000, which just happens to be the genesis block hash, so the data is known. I figured out how to make the standard checks in the client just return true and recompiled, so that I could submit the transaction claiming it. Hopefully, my transaction gets to a miner that accepts nonstandard transactions somehow, but it showed up on blockchain.info so I'm hopeful.

Looks like that person screwed up though, see tx af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d Same idea, but an earlier attempt with the wrong endian and hence unspendable.

The one with the correct endian has been spent by tx 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1 Curiously I'm seeing it as unconfirmed right now, which implies that either that Blockchain.info has a server ignoring the IsStandard check or it does in fact pass. For a scriptSig input, as opposed to a scriptPubKey output the actual check is AreInputsStandard, although looking at that code I don't see how it could have passed the test. The transaction also hasn't propagated to any of my Bitcoin nodes, which implies the former explanation.

EDIT: oops, didn't see you saying you sent that TX... you might also want to try re-sending it directly to Eligius, who accept non-standard TX's for mining. See the wiki page Free transaction relay policy. I think you can trigger that resend by re-running sendrawtransaction

That block has another interesting set of transactions; e1a1a0242d46fb515a3aaaef713104832384a0f30a4fcdfefb982d1c06e56860 is one example. p2pool includes a zero-valued output in every one of their coinbase transactions that just pushes the hash of the current share in the p2pool sharechain to the stack. While zero-valued those outputs are spendable as they are evaluated to true. Looks like this person has gone off and found every (?) such p2pool output and spent it. With pruning that's actually kind-of a public service by reducing the tx-out set...

I'd like to thank whomever put those bitcoins out there for the taking for inspiring me to learn more about the internal structures of transactions.

They'd also make good examples for the wiki.

[Peter Todd]

If you look at blockchain.info's network propagation page for that non-standard spend right now it shows %13 propagation (326 nodes) even though though the transaction has been on the network for over an hour. I tried connecting to some of the nodes myself:

Code:

{
    "addr" : "222.210.246.120:8333",
    "services" : "00000001",
    "lastsend" : 1355371064,
    "lastrecv" : 1355371063,
    "conntime" : 1355370970,
    "version" : 32400,
    "subver" : "", 
    "inbound" : false,
    "releasetime" : 0,
    "startingheight" : 212012,
    "banscore" : 0 
},
{
    "addr" : "188.178.214.14:8333",
    "services" : "00000001",
    "lastsend" : 1355371065,
    "lastrecv" : 1355371065,
    "conntime" : 1355370971,
    "version" : 40000,
    "subver" : "", 
    "inbound" : false,
    "releasetime" : 0,
    "startingheight" : 212012,
    "banscore" : 0 
},
{
    "addr" : "68.144.60.121:8333",
    "services" : "00000001",
    "lastsend" : 1355371067,
    "lastrecv" : 1355371068,
    "conntime" : 1355370971,
    "version" : 40000,
    "subver" : "", 
    "inbound" : false,
    "releasetime" : 0,
    "startingheight" : 212012,
    "banscore" : 0 
}

Looks like none of them are the standard Satoshi client, which sets subver to "/Satoshi:0.7.1/" or similar. Any idea what these nodes might be? There sure are a lot of them... there isn't anything special about the IP's, just the usual mix of various DSL/Cable providers and hosting companies.

[sebicas]

Interesting! So how exactly do you do to complete the transaction?

[Fjordbit]

The original transaction looks like someone had a problem with their JSON output code, putting [Object] instead of the value.

[Peter Todd]

Interesting! So how exactly do you do to complete the transaction?

As I said, get it to a miner who will mine it. According to the wiki Eligius will, so use -addnode=173.242.112.53 or post the raw hex for your transaction here and I'm sure someone will be able to forward it for you.

The original transaction looks like someone had a problem with their JSON output code, putting [Object] instead of the value.

Doesn't look like it. The scriptPubKey consists of a single OP_TRUE opcode, while the createrawtransaction command only allows you to specify outputs as valid addresses, or nothing at all. The latter would leave scriptPubKey totally empty.

[mskwik]

Interesting! So how exactly do you do to complete the transaction?

As I said, get it to a miner who will mine it. According to the wiki Eligius will, so use -addnode=173.242.112.53 or post the raw hex for your transaction here and I'm sure someone will be able to forward it for you.

Do be aware that the script signatures on the nonstandard transactions discussed so far are not based on signing the whole transaction however so posting a raw transaction without getting it on the network first could allow someone to replace your output address with their own before forwarding it.

[Peter Todd]

Interesting! So how exactly do you do to complete the transaction?

As I said, get it to a miner who will mine it. According to the wiki Eligius will, so use -addnode=173.242.112.53 or post the raw hex for your transaction here and I'm sure someone will be able to forward it for you.

Do be aware that the script signatures on the nonstandard transactions discussed so far are not based on signing the whole transaction however so posting a raw transaction without getting it on the network first could allow someone to replace your output address with their own before forwarding it.

Yeah, but in this case anyone can trivially replicate the transaction already anyway. It's just a race to see who gets it mined first. Heck, I'd do it myself, but sebicas was pretty clever for figuring it out so I think he deserves the BTC a lot more than I do.

[mskwik]

Yeah, but in this case anyone can trivially replicate the transaction already anyway. It's just a race to see who gets it mined first. Heck, I'd do it myself, but sebicas was pretty clever for figuring it out so I think he deserves the BTC a lot more than I do.

Fair enough, guess I'm just used to translating technical language for not quite as technical people and that was what jumped out at me as being what someone might not realize at first glance.

[Jan]

I saw this post yesterday just before going to bed and was going to claim it first thing in the morning (was dead tired), now it is taken. You snooze you loose 

[jgarzik]

Looks like none of them are the standard Satoshi client, which sets subver to "/Satoshi:0.7.1/" or similar. Any idea what these nodes might be?

Those are just old nodes, prior to the strSubVer convention.  Look at their numeric protocol version.

[Jan]

I know that output 0 of transaction cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35 was already claimed, but this post triggered me to experiment with manually constructing transactions.

Here is a piece of code that uses bitlib and bccapi to build the exact same transaction:
http://code.google.com/p/bccapi/source/browse/trunk/bccapi/src/com/bccapi/ng/example/CustomBuiltTransaction.java

Here is the gist:
   public static void main(String[] args) throws ScriptParsingException, MalformedURLException, ApiException {
      // Build transaction input
      Sha256Hash txHash = new Sha256Hash(
            HexUtils.toBytes("cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35"));
      OutPoint outPoint = new OutPoint(txHash, 0);
      ScriptInput si = ScriptInput.fromScriptBytes(new byte[] { 1, Script.OP_FALSE, Script.OP_DROP });
      TransactionInput ti = new TransactionInput(outPoint, si);

      // Build transaction output
      Address receiver = Address.fromString("1LqTjBzMRdXQqXpRQo1zDYRiUobAVS55Lo", NetworkParameters.productionNetwork);
      ScriptOutput so = new ScriptOutputStandard(receiver.getTypeSpecificBytes());
      TransactionOutput to = new TransactionOutput(99950000, so);

      // Build transaction
      Transaction tx = new Transaction(1, new TransactionInput[] { ti }, new TransactionOutput[] { to }, 0);
      System.out.println("Our transaction hash: " + tx.getHash().toString());

      // Broadcast transaction (here we depend on the BCCAPI server, you can use
      // whatever API you like for this)
      URL url = new URL("http://bqs1.bccapi.com:80");
      BitcoinClientApi api = new BitcoinClientApiImpl(url, NetworkParameters.productionNetwork);
      BroadcastTransactionResponse response = api.broadcastTransaction(new BroadcastTransactionRequest(tx));
      System.out.println("Broadcasted transaction with hash: " + response.hash.toString());
   }


Hope you find it useful.