1 2016-03-28 07:13:53 <runeks> back in return.
 2 2016-03-28 07:13:53 <runeks> How difficult would it be to add a "dry run" option to the sendrawtransaction RPC command? This would allow checking whether a given transaction would be accepted by Bitcoin Core, without actually broadcasting anything. This is especially useful for payment channel servers, who need to be absolutely sure that they have received value before sending something
 3 2016-03-28 07:13:57 <runeks> This feature, used with multi-sig transactions that require a signature from the party who checks the transaction, basically means that the checker can know whether the un-broadcast transaction is as good as a transaction in the blockchain (until the locktime expires).
 4 2016-03-28 07:16:21 <arubi> isn't this what signrawtransaction does?  also there's '-walletbroadcast'
 5 2016-03-28 07:32:30 <runeks> arubi: I just looked it up. It appears this function requires private keys, in order to sign the transaction in question. I'd really rather not have any private keys leave my server. I guess it's useful, but it seems unnecessary if all we want to know is whether a given, final transaction would be accepted.
 6 2016-03-28 07:35:02 <runeks> What I really want is to use Bitcoin Core as a library, rather than a wallet. The RPC interface is very useful for that.
 7 2016-03-28 08:03:04 <arubi> runeks, I'm not 100% sure, and I can't check at the moment, but I /think/ signrawtransaction, when given both prevtxs and privatekeys as null will tell you if the transaction is complete or not, and if it's validity
 8 2016-03-28 08:06:35 <wumpus> runeks: see my verifyrawtransactions pull
 9 2016-03-28 08:06:53 <wumpus> https://github.com/bitcoin/bitcoin/pull/7552
10 2016-03-28 08:07:42 <wumpus> it's basically sendrawtransaction, but without sending the transaction, and allowing verifying multiple, even a chain of transactions at once
11 2016-03-28 08:10:12 <arubi> ooh cool ^
12 2016-03-28 08:10:39 <jeremias> good feature
13 2016-03-28 09:05:53 <runeks> wumpus: Awesome! Looks like just what I need.
14 2016-03-28 09:08:34 <runeks> But, as others in the pull request have mentioned, we better be damn sure that its return result is *always* the same as that of sendrawtransaction.
15 2016-03-28 09:09:06 <runeks> Looking at the code, to me it doesn't seem trivial achieve this.
16 2016-03-28 09:11:41 <runeks> Implementation-wise, it would seem a lot more robust to use the same code path as sendrawtransaction, but abort before the transaction is committed, and just return "valid".
17 2016-03-28 09:23:45 <wumpus> that would be a non-trivial impact to the current transaction handling code
18 2016-03-28 09:24:12 <wumpus> not a good idea with all the softforks etc going on
19 2016-03-28 09:24:38 <wumpus> anyhow, closing it then, feel free to implement it in a way you think is better
20 2016-03-28 09:26:08 <wumpus> I thought this was a god way to get the API merged, it could always be improved later
21 2016-03-28 09:26:23 <wumpus> good*
22 2016-03-28 09:27:06 <wumpus> also the 'verify multiple transactions' part would be more difficult to implement if you want to bolt this onto main.cpp
23 2016-03-28 13:57:18 <Chris_Stewart_5> Does NULLDUMMY just require the extra operation on OP_CHECKMULTISIG to be an OP_0