edmundedgar (OP)
|
|
November 11, 2014, 02:25:43 AM |
|
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#nonstandardI'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=1Can 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?
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
November 11, 2014, 06:51:02 AM |
|
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.comThis is a pool which mines non-standard p2sh-inputs Unfortunately this pool has very little hash power
|
|
|
|
|
|
dabura667
|
|
November 12, 2014, 03:40:40 PM |
|
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
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
November 12, 2014, 03:49:48 PM |
|
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
|
|
November 12, 2014, 04:00:16 PM |
|
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: 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.
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
November 12, 2014, 04:23:46 PM |
|
A PM would be fine if you don't want it public. I won't tell anyone. Everything is written in scriptSig 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
|
|
November 13, 2014, 12:06:00 AM |
|
A PM would be fine if you don't want it public. I won't tell anyone. Everything is written in scriptSig 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.
|
My Tip Address: 1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
|
|
|
edmundedgar (OP)
|
|
November 13, 2014, 01:14:14 AM |
|
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
|
|
November 13, 2014, 01:35:09 AM |
|
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.
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
edmundedgar (OP)
|
|
November 13, 2014, 03:51:02 AM |
|
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.
|
|
|
|
|