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