< bitcoin-git> [bitcoin] gmaxwell opened pull request #10146: Better error handling for submitblock (master...better_error_submitblock) https://github.com/bitcoin/bitcoin/pull/10146
< kallewoof> It struck me that nodes can delegate challenges they receive to other nodes, if they are formed properly. For example, challenge X lets node A connect to node B. A gives X to C saying C may use bloom filters if solves. C solves and gives to A, A gives to B, and B verifies and opens for A. That lets A know the solution was right so A now gives C reward.
< kallewoof> Wrong channel.
< jeremyrubin> :q
< jeremyrubin> crap this isn't vim... reflexes...
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/471ed00fcd3b...72bc7e1303d5
< bitcoin-git> bitcoin/master ada0caa Gregory Maxwell: Make GetWitnessCommitmentIndex callable on blocks without a coinbase txn....
< bitcoin-git> bitcoin/master 4f15ea1 Gregory Maxwell: Check transaction count early in submitblock....
< bitcoin-git> bitcoin/master 30f30c0 Gregory Maxwell: Add braces to submitblock per current style.
< bitcoin-git> [bitcoin] laanwj closed pull request #10146: Better error handling for submitblock (master...better_error_submitblock) https://github.com/bitcoin/bitcoin/pull/10146
< da2ce7> I have updated both my Bitcoin Knots and Bitcoin Core 0.14 patches for BIP 148
< da2ce7> Core Review would be most appreciated.
< da2ce7> In particular this pull request need code-review: https://github.com/bitcoin/bips/pull/512
< da2ce7> luke-jr: ^
< bitcoin-git> [bitcoin] sipa opened pull request #10148: Use non-atomic flushing with block replay (master...non_atomic_flush) https://github.com/bitcoin/bitcoin/pull/10148
< gmaxwell> \O/
< bsm117532> Does P2SH entirely eliminate scriptSig malleability?
< luke-jr> ? it's not intended to
< bsm117532> I know, but it seems to me it could, if the scriptSig was required to be: OP_HASH160 [20-byte-hash-value] OP_EQUAL
< bsm117532> s/scriptSig/scriptPubKey/
< bsm117532> and if non-pushdata in the scriptSig were consensus-enforced.
< bitcoin-git> [bitcoin] jnewbery opened pull request #10150: [rpc Add logging rpc (master...logging_rpc) https://github.com/bitcoin/bitcoin/pull/10150
< sipa> bsm117532: the scriptSig still needs to contain the inputs to the redeemscript (ecdsa signatures etc)
< bsm117532> sipa of course, but I *think* that leaves low-S malleation as the only malleation for P2SH transactions?
< sipa> read bip62
< bsm117532> I am...
< sipa> it lists 9 sources of malleability :)
< bsm117532> My question is: does bitcoin consensus-enforce the statements in BIP16 about disallowing non-pushdata?
< sipa> i believe so
< bsm117532> Because it seems to me that would disallow all non-low-S-malleation types of malleability.
< sipa> what if your redeemscript contains a silly OP_DROP?
< bsm117532> That's fine but it was committed to in the P2SH hash...
< sipa> no
< bsm117532> So you're saying I can create a stupid script which allows malleability...
< sipa> the redeemscript is committed to
< sipa> its inputs are not
< bsm117532> exactly
< sipa> you can have redeemscripts that ignore inputs
< bsm117532> Ok, I can handle that by not writing script containing OP_DROP ;-)
< sipa> or allow multiple variants at least
< sipa> i can't force everyone sending me transactions to not use such scripts
< bsm117532> Of course not, but within my software stack I'm not going to do things like that.. ;-)
< bsm117532> That's a good attack to consider though...
< * bsm117532> ponders...
< * bsm117532> has already written a segwit implementation...I wish I could just use that...
< sipa> also, if there is a multisig involved, one of the parties can just create a new ecdsa signature
< sipa> that is an issue for many contracts
< sipa> and not something that simple requirements of a canonical form can ever fix
< sipa> (but segwit does)
< bsm117532> Is there no enforcement of deterministic signatures?
< sipa> ecdsa signatures are not deterministic
< adiabat> it's not possible to enforce
< sipa> and requiring them to be requires revealing the private key
< bsm117532> gotcha
< bsm117532> ah yeah the determinism algorithm hashes the privkey...
< sipa> you may want BLS :p
< adiabat> half the size too :)
< bsm117532> I'll have to wrap my brain around BLS later. Gotta work around malleability instead. :-(
< sipa> you want segwit </jeditrick>
< bsm117532> So to work around existing malleability, I'm going to use P2SH transactions (with no OP_DROPs), and try to detect low-S-malleations.
< bsm117532> sipa: Did I mention I already wrote this for segwit? It works great on my regtest!
< adiabat> bsm117532: the problem is op_drops can show up in the sigscript, which is not covered by the p2sh script hash
< bsm117532> adiabat: as I understand it, an OP_DROP in a P2SH scriptSig would be disallowed by consensus rules.
< bsm117532> (because it has to be only data pushes)
< sipa> in the scriptSig it is disallowed
< sipa> in the redeemscript it isn't
< bsm117532> Yes. So I'd only have malleability if I create a redeemscript that allows for a malleable scriptSig.
< bsm117532> (and I can control the redeemscript as long as someone doesn't hack my software)
< sipa> which every multisig check does
< bsm117532> sipa: how?
< sipa> as OP_CHECKMULTISIG pops one element off the stack without looking at it
< bsm117532> oh balls you're right
< sipa> and your cosigners can always malleate, as i've explained
< bsm117532> Then I can't use a multisig script...not a problem actually.
< bsm117532> I'll just use a P2SH where the redeemscript is a P2PKH script...
< adiabat> It's very hard to prevent different txids; dealing with it in a way that nobody loses money is oftern easier
< bsm117532> adiabat: for me that requires detecting malleation and in some cases writing new transactions (I have pre-signed, off-chain transactions). Hence why I'm trying to determine all the forms of malleation I might see...
< sipa> there is no proof that there are no other forms of ecdsa malleabillity, bte
< sipa> w
< sipa> (though it seems very unlikely)
< adiabat> detecting it could be as simple as detecting that the same utxos are being spent
< bsm117532> adiabat: yes, I'll do that. Detection is fine but I'm also trying to figure out how to write transactions to minimize the possibility.
< adiabat> if it's just 1 signer, and that signer is you, then it's often not too bad if the txid changes. you can deal with it
< bsm117532> yep yep
< adiabat> and you'll have to write that code anyway I think, as you can't really prevent if 100%
< bsm117532> Segwit does :-P
< bsm117532> Heh this is an interesting script: <Pubkey> OP_SWAP OP_CHECKSIG
< bsm117532> Then the scriptSig is only the signature (no pubkey)
< bsm117532> I was thinking of using a P2PKH script as the script for a P2SH, but the one above would be smaller by ~20 bytes
< sdaftuar> you don't need the OP_SWAP?
< bsm117532> I was wondering that...
< bsm117532> But if I'm reading this right, my stack will be <pubkey> <sig>... and it needs to be the opposite?
< sdaftuar> no, does not need to be the opposite (trace what happens in a P2PKH spend).
< bsm117532> sdaftuar: thanks
< bitcoin-git> [bitcoin] jnewbery opened pull request #10151: [logging] initialize flag variable to 0 (and continue if GetLogCategory() fails) (master...logging_initialization) https://github.com/bitcoin/bitcoin/pull/10151
< bitcoin-git> [bitcoin] jnewbery opened pull request #10152: [trivial] remove unused line in Travis config (master...travis_cleanup) https://github.com/bitcoin/bitcoin/pull/10152
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72bc7e1303d5...080d7c700fc3
< bitcoin-git> bitcoin/master 16791c5 John Newbery: [trivial] remove unused line in Travis config
< bitcoin-git> bitcoin/master 080d7c7 MarcoFalke: Merge #10152: [trivial] remove unused line in Travis config...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10152: [trivial] remove unused line in Travis config (master...travis_cleanup) https://github.com/bitcoin/bitcoin/pull/10152
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10153: logging: Fix off-by-one for shrinkdebugfile default (master...Mf1704-offbyoneDebug) https://github.com/bitcoin/bitcoin/pull/10153
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10154: init: Remove redundant logging code (master...Mf1704-lognodebug) https://github.com/bitcoin/bitcoin/pull/10154