Topic: Eligius relays my non-standard txes but won't mine them? And who's mining them? (Read 1766 times)

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.

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

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.

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.

Everything is written in scriptSig

Actually. The ScriptSig was this:


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.

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

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 

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.

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...

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

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?