Eligius relays my non-standard txes but won't mine them? And who's mining them?

[edmundedgar]

So I'm tinkering around with some transactions that are currently non-standard, but should become standard in the next bitcoind release.

The transactions I'm using follow the pattern here:
https://www.realitykeys.com/developers/resources#nonstandard

I'd been expecting these to get mined by Eligius, and basically nobody else. But it seems like Eligius will accept them via its web form but never actually mines them, and there are a bunch of random IP addresses out there that _do_ mine them for me.

Here are a bunch of transactions:
https://blockchain.info/address/391ByYRP3ZGtizQt3XKc96T8xxLvzWj5Ec?filter=1

Can anyone shed any light on what's going on here? Am I tripping over some other Eligius check? (Key reuse? Some malleability thing?) Or are those random IPs really Eligius? If not who are my mysterious non-standard-tx-mining benefactors?

[1714032909]

1714032909

[1714032909]

1714032909

[amaclin]

and there are a bunch of random IP addresses out there that _do_ mine them for me.

Do not look to the field "Relayed By" on bc.i
Just look to the coinbase transaction.
You will see that all your non-standard transactions were mined by mining.bitcoinaffiliatenetwork.com
This is a pool which mines non-standard p2sh-inputs
Unfortunately this pool has very little hash power

[edmundedgar]

Ah, thanks, Amaclin.

These guys seem to be averaging about 1 block per day, which is quite a useful thing to have around.
https://mining.bitcoinaffiliatenetwork.com/index.php?page=statistics&action=blocks

I wonder why I'm not getting any love from Eligius... guess I'll try some more high-rolling transactions and some bigger fees and see if that helps...

[edmundedgar]

OK, so Eligius mined this one:
https://blockchain.info/tx/fbd6be67bb26e107e553377d3f217c29386d19b8a15b85c2602b0648d6ac3fa0

I guess my transactions were too small and piddling and smelled of dust, or my transaction fee was too mean.

Edit to add:

Yup, they took this one, too - 0.4 mBTC with a 0.1 mBTC fee.
https://blockchain.info/tx/0c82fa329f510b205bf982c95695d3bf0ca8008cc46e3a2c9698261ca07db208

I guess a 0.2 mBTC tx (0.1 mBTC + 0.1 mBTC fee) just looks too much like dust to them.

[dabura667]

Slightly OT, but using OP_0 and OP_1 to trigger the redeemscripts IF/ELSEs seems to be something any service's users would be able to alter on their own if they knew the service's inner workings well enough.

I haven't looked into your site much, but would you mind explaining why you decided embedded IF/ELSEs with an OP_0 and/or OP_1 combination before the redeemscript was necessary?

It bugs me in that it seems to scream "inefficiency" at me...

Maybe I'm just crazy... who knows 

[amaclin]

I haven't looked into your site much, but would you mind explaining why you decided embedded IF/ELSEs with an OP_0 and/or OP_1 combination before the redeemscript was necessary?

As far as I can see this is non-standard multisig output 2-of-4 ( or something similar )
it can be spent by
Alice + Bob
Bob + Charley
Charley + David
Alice + David

[Alice + Charley] or [Bob + David] can not spend this output

[dabura667]

I haven't looked into your site much, but would you mind explaining why you decided embedded IF/ELSEs with an OP_0 and/or OP_1 combination before the redeemscript was necessary?

As far as I can see this is non-standard multisig output 2-of-4 ( or something similar )
it can be spent by
Alice + Bob
Bob + Charley
Charley + David
Alice + David

[Alice + Charley] or [Bob + David] can not spend this output

Actually. The ScriptSig was this:

Code:

00   #OP_0
493046022100f3e419061d5ad9acfc5f17e113dad8683690378b20530b853f2e0f238925d08d022100aa3981e95bb612023be4a1425286b81ff78c0a597537361e047f0f87bfbf1ee601 #SIG
483045022100d428174f7629ae25ae1bff217ea4f66a84dec87d1b165b3bdcce563dcb9304d8022007d3b49b5fa09ced820cc06c93358ae654df8db76c4336bfb6c91c0e96569b2301 #SIG

00  #OP_0
51  #OP_1
4cdb #PUSHDATA (This is pushing the rest of the ScriptSig on the stack (aka it's the redeemscript)

63 #OP_IF
63 #OP_IF
522103b1e8aba06d96273de138cb8f672ef93b3bdefd9dc18d6c038e4eb8a766778ad32103d93547f38370b35471a8ee463b4245d6b1282a0feccce8e149c4ada76d32df1a52ae #MULTISIG 2 of 2
67 #OP_ELSE
52210247e6c3a88d76ab7505c147e5a9bcf0011226f7690081dd728042831f90a391ed210389688a084ff6f83c9ed3c91236e0f46d060cef32da23dfc6fc147fde6af9ca1052ae #MULTISIG 2 of 2
68 #OP_ENDIF
67 #OP_ELSE
522103b1e8aba06d96273de138cb8f672ef93b3bdefd9dc18d6c038e4eb8a766778ad3210247e6c3a88d76ab7505c147e5a9bcf0011226f7690081dd728042831f90a391ed52ae #MULTISIG 2 of 2
68 #OP_ENDIF

So BEFORE the redeemscript, he places any combination of 0 and 1. in the tx he used 0 then 1, meaning the first IF would trigger and the second IF would not (and the proceeding ELSE would)...

OP_0 would give the 3rd multisig, OP_1 OP_0 gives the 2nd multisig and OP_1 OP_1 would give the 1st multisig.

Rather than using IF/ELSE embedding (which is hard to negative test effectively) there seems like there would be a better way of doing what he's trying to accomplish... maybe this is the best way... but I won't know unless he tells me what he's trying to accomplish.

OP>
A PM would be fine if you don't want it public. I won't tell anyone.

[amaclin]

A PM would be fine if you don't want it public. I won't tell anyone.

Everything is written in scriptSig

Code:

if ( popStack ( ) )
  if ( popStack ( ) )
     checkMsig_2of2 ( "03b1e8...", "03d935..." );  // Alice + Bob
  else
     checkMsig_2of2 ( "0247e6...", "038968..." );  // Charley + David
else
  checkMsig_2of2 ( "03b1e8...", "0247e6..." ); // Alice + Charley

[dabura667]

A PM would be fine if you don't want it public. I won't tell anyone.

Everything is written in scriptSig

Code:

if ( popStack ( ) )
  if ( popStack ( ) )
     checkMsig_2of2 ( "03b1e8...", "03d935..." );  // Alice + Bob
  else
     checkMsig_2of2 ( "0247e6...", "038968..." );  // Charley + David
else
  checkMsig_2of2 ( "03b1e8...", "0247e6..." ); // Alice + Charley

You are making the assumption that his goal is a 1-of-3 groups of 2-of-2 multisig.

Seeing as his site is not just a simple escrow site, there is a high possibility that each key does not represent one user. One or more of those keys could be a special key used as a case trigger.

By leaving the decision of which multisig to use OUTSIDE the redeemscript, there's a lot of room for attack vectors.

If I knew exactly what the purpose of the contract was for, I could suggest more efficient ways to perform the same task.

I can read Script just fine, thanks. The Script tells me nothing about its goals, just its results.

[edmundedgar]

For people who are wondering, the goal here is:

Alice and Bob make a transction based on some real-world event. Alice gets paid if it happens, Bob gets paid if it doesn't. An oracle (my service, Reality Keys) will judge whether the event happened or not. The oracle will not be party to, or sign, the actual transaction between Alice and Bob. Although they haven't done so here, Alice and Bob would be able to conceal their transaction so that neither the oracle nor anyone else would know about it. However the oracle's verdicts about the outcome of the event should be public so that anyone can check up on it. Alice and Bob should also be able to withdraw their funds by mutual agreement, without the help of the oracle.

To achieve this, Reality Keys  issues two public keys, one representing "Yes, it happened" and one representing "No, it didn't happen". At the agreed date it will release a private key for the appropriate public key corresponding to its verdict, and throw the other one away.

The aim of the script redeemed in this transaction is to make the funds spendable by any combination of:
Alice + Yes
Bob +  No
Alice + Bob

We use the if flags to indicate which of those combinations you're trying to use to claim the funds with the signatures you're supplying. Another approach would be to duplicate the signatures and test each combination in turn. I don't have a strong opinion about which is better, although I find this one easy to understand and it avoids making nodes waste time checking signatures that are definitely going to fail.

Any comments and suggestions welcome, especially if somebody can think of a reason my tx doesn't do what I think it does...

PS There's also an approach using ECC maths to combine keys and make a standard 1/3 tx, but it has at least one nasty trap for the unwary, and maybe more that I'm not aware of... More on my resources page linked in my original post.

[mmeijeri]

The aim of the script redeemed in this transaction is to make the funds spendable by any combination of:
Alice + Yes
Bob +  No
Alice + Bob

Maybe using BIP-65 to also allow (Alice or Bob) after a deadline sufficiently far in the future would also be nice.

[edmundedgar]

The aim of the script redeemed in this transaction is to make the funds spendable by any combination of:
Alice + Yes
Bob +  No
Alice + Bob

Maybe using BIP-65 to also allow (Alice or Bob) after a deadline sufficiently far in the future would also be nice.

Yup, that would be good when we get OP_CHECKLOCKTIMEVERIFY. In the meantime Alice and Bob might want to use the Alice+Bob branch when they set up the original funding tx to sign transactions to each other using a traditional nTimeLock to protect against both Reality Keys and their counterparty disappearing.

PS while we wait for BIP-65 you can fake it for other purposes with a tautological Reality Key like "1 Bitcoin to be worth at least 1 Bitcoin on [date]". If people want this I might add a less kludgey "release on date" or "release on block number" key type.