1 2017-04-04 04:04:59	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #10146: Better error handling for submitblock (06master...06better_error_submitblock) 02https://github.com/bitcoin/bitcoin/pull/10146
  2 2017-04-04 04:50:45	0|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.
  3 2017-04-04 04:51:00	0|kallewoof|Wrong channel.
  4 2017-04-04 05:34:36	0|jeremyrubin|:q
  5 2017-04-04 05:34:59	0|jeremyrubin|crap this isn't vim... reflexes...
  6 2017-04-04 07:00:54	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/471ed00fcd3b...72bc7e1303d5
  7 2017-04-04 07:00:55	0|bitcoin-git|13bitcoin/06master 144f15ea1 15Gregory Maxwell: Check transaction count early in submitblock....
  8 2017-04-04 07:00:55	0|bitcoin-git|13bitcoin/06master 14ada0caa 15Gregory Maxwell: Make GetWitnessCommitmentIndex callable on blocks without a coinbase txn....
  9 2017-04-04 07:00:56	0|bitcoin-git|13bitcoin/06master 1430f30c0 15Gregory Maxwell: Add braces to submitblock per current style.
 10 2017-04-04 07:01:15	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10146: Better error handling for submitblock (06master...06better_error_submitblock) 02https://github.com/bitcoin/bitcoin/pull/10146
 11 2017-04-04 09:34:54	0|da2ce7|I have updated both my Bitcoin Knots and Bitcoin Core 0.14 patches for BIP 148
 12 2017-04-04 09:34:57	0|da2ce7|https://github.com/da2ce7/bitcoin/tree/bitcoin0.14_bip148
 13 2017-04-04 09:35:05	0|da2ce7|https://github.com/da2ce7/bitcoin/tree/knotsbip148
 14 2017-04-04 09:35:34	0|da2ce7|Core Review would be most appreciated.
 15 2017-04-04 09:42:06	0|da2ce7|In particular this pull request need code-review: https://github.com/bitcoin/bips/pull/512
 16 2017-04-04 09:42:17	0|da2ce7|luke-jr: ^
 17 2017-04-04 09:51:06	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10148: Use non-atomic flushing with block replay (06master...06non_atomic_flush) 02https://github.com/bitcoin/bitcoin/pull/10148
 18 2017-04-04 09:51:51	0|gmaxwell|\O/
 19 2017-04-04 18:09:52	0|bsm117532|Does P2SH entirely eliminate scriptSig malleability?
 20 2017-04-04 18:11:38	0|luke-jr|? it's not intended to
 21 2017-04-04 18:12:48	0|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
 22 2017-04-04 18:13:54	0|bsm117532|s/scriptSig/scriptPubKey/
 23 2017-04-04 18:16:24	0|bsm117532|and if non-pushdata in the scriptSig were consensus-enforced.
 24 2017-04-04 18:17:03	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10150: [rpc Add logging rpc (06master...06logging_rpc) 02https://github.com/bitcoin/bitcoin/pull/10150
 25 2017-04-04 18:25:20	0|sipa|bsm117532: the scriptSig still needs to contain the inputs to the redeemscript (ecdsa signatures etc)
 26 2017-04-04 18:25:52	0|bsm117532|sipa of course, but I *think* that leaves low-S malleation as the only malleation for P2SH transactions?
 27 2017-04-04 18:26:04	0|sipa|read bip62
 28 2017-04-04 18:26:10	0|bsm117532|I am...
 29 2017-04-04 18:26:18	0|sipa|it lists 9 sources of malleability :)
 30 2017-04-04 18:26:35	0|bsm117532|My question is: does bitcoin consensus-enforce the statements in BIP16 about disallowing non-pushdata?
 31 2017-04-04 18:27:05	0|sipa|i believe so
 32 2017-04-04 18:27:19	0|bsm117532|Because it seems to me that would disallow all non-low-S-malleation types of malleability.
 33 2017-04-04 18:28:16	0|sipa|what if your redeemscript contains a silly OP_DROP?
 34 2017-04-04 18:29:04	0|bsm117532|That's fine but it was committed to in the P2SH hash...
 35 2017-04-04 18:29:10	0|sipa|no
 36 2017-04-04 18:29:15	0|bsm117532|So you're saying I can create a stupid script which allows malleability...
 37 2017-04-04 18:29:20	0|sipa|the redeemscript is committed to
 38 2017-04-04 18:29:24	0|sipa|its inputs are not
 39 2017-04-04 18:29:28	0|bsm117532|exactly
 40 2017-04-04 18:29:41	0|sipa|you can have redeemscripts that ignore inputs
 41 2017-04-04 18:29:53	0|bsm117532|Ok, I can handle that by not writing script containing OP_DROP ;-)
 42 2017-04-04 18:29:54	0|sipa|or allow multiple variants at least
 43 2017-04-04 18:30:13	0|sipa|i can't force everyone sending me transactions to not use such scripts
 44 2017-04-04 18:30:27	0|bsm117532|Of course not, but within my software stack I'm not going to do things like that.. ;-)
 45 2017-04-04 18:30:57	0|bsm117532|That's a good attack to consider though...
 46 2017-04-04 18:34:27	0|sipa|also, if there is a multisig involved, one of the parties can just create a new ecdsa signature
 47 2017-04-04 18:34:42	0|sipa|that is an issue for many contracts
 48 2017-04-04 18:35:04	0|sipa|and not something that simple requirements of a canonical form can ever fix
 49 2017-04-04 18:35:12	0|sipa|(but segwit does)
 50 2017-04-04 18:35:25	0|bsm117532|Is there no enforcement of deterministic signatures?
 51 2017-04-04 18:35:35	0|sipa|ecdsa signatures are not deterministic
 52 2017-04-04 18:35:38	0|adiabat|it's not possible to enforce
 53 2017-04-04 18:35:53	0|sipa|and requiring them to be requires revealing the private key
 54 2017-04-04 18:36:04	0|bsm117532|gotcha
 55 2017-04-04 18:36:17	0|bsm117532|ah yeah the determinism algorithm hashes the privkey...
 56 2017-04-04 18:36:30	0|sipa|you may want BLS :p
 57 2017-04-04 18:36:49	0|adiabat|half the size too :)
 58 2017-04-04 18:36:58	0|bsm117532|I'll have to wrap my brain around BLS later.  Gotta work around malleability instead. :-(
 59 2017-04-04 18:37:49	0|sipa|you want segwit </jeditrick>
 60 2017-04-04 18:38:12	0|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.
 61 2017-04-04 18:38:25	0|bsm117532|sipa: Did I mention I already wrote this for segwit?  It works great on my regtest!
 62 2017-04-04 18:39:11	0|adiabat|bsm117532: the problem is op_drops can show up in the sigscript, which is not covered by the p2sh script hash
 63 2017-04-04 18:39:40	0|bsm117532|adiabat: as I understand it, an OP_DROP in a P2SH scriptSig would be disallowed by consensus rules.
 64 2017-04-04 18:39:53	0|bsm117532|(because it has to be only data pushes)
 65 2017-04-04 18:40:20	0|sipa|in the scriptSig it is disallowed
 66 2017-04-04 18:40:26	0|sipa|in the redeemscript it isn't
 67 2017-04-04 18:40:57	0|bsm117532|Yes.  So I'd only have malleability if I create a redeemscript that allows for a malleable scriptSig.
 68 2017-04-04 18:41:15	0|bsm117532|(and I can control the redeemscript as long as someone doesn't hack my software)
 69 2017-04-04 18:41:21	0|sipa|which every multisig check does
 70 2017-04-04 18:41:46	0|bsm117532|sipa: how?
 71 2017-04-04 18:42:03	0|sipa|as OP_CHECKMULTISIG pops one element off the stack without looking at it
 72 2017-04-04 18:42:15	0|bsm117532|oh balls you're right
 73 2017-04-04 18:42:31	0|sipa|and your cosigners can always malleate, as i've explained
 74 2017-04-04 18:42:41	0|bsm117532|Then I can't use a multisig script...not a problem actually.
 75 2017-04-04 18:43:28	0|bsm117532|I'll just use a P2SH where the redeemscript is a P2PKH script...
 76 2017-04-04 18:43:29	0|adiabat|It's very hard to prevent different txids; dealing with it in a way that nobody loses money is oftern easier
 77 2017-04-04 18:45:37	0|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...
 78 2017-04-04 18:47:59	0|sipa|there is no proof that there are no other forms of ecdsa malleabillity, bte
 79 2017-04-04 18:48:02	0|sipa|w
 80 2017-04-04 18:48:20	0|sipa|(though it seems very unlikely)
 81 2017-04-04 18:48:21	0|adiabat|detecting it could be as simple as detecting that the same utxos are being spent
 82 2017-04-04 18:49:18	0|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.
 83 2017-04-04 18:50:40	0|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
 84 2017-04-04 18:50:52	0|bsm117532|yep yep
 85 2017-04-04 18:51:14	0|adiabat|and you'll have to write that code anyway I think, as you can't really prevent if 100%
 86 2017-04-04 18:51:33	0|bsm117532|Segwit does :-P
 87 2017-04-04 19:03:08	0|bsm117532|Heh this is an interesting script: <Pubkey> OP_SWAP OP_CHECKSIG
 88 2017-04-04 19:03:22	0|bsm117532|Then the scriptSig is only the signature (no pubkey)
 89 2017-04-04 19:05:15	0|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
 90 2017-04-04 19:06:22	0|sdaftuar|you don't need the OP_SWAP?
 91 2017-04-04 19:06:45	0|bsm117532|I was wondering that...
 92 2017-04-04 19:08:19	0|bsm117532|But if I'm reading this right, my stack will be <pubkey> <sig>... and it needs to be the opposite?
 93 2017-04-04 19:13:24	0|sdaftuar|no, does not need to be the opposite (trace what happens in a P2PKH spend).
 94 2017-04-04 19:13:47	0|bsm117532|sdaftuar: thanks
 95 2017-04-04 19:23:56	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10151: [logging] initialize flag variable to 0 (and continue if GetLogCategory() fails) (06master...06logging_initialization) 02https://github.com/bitcoin/bitcoin/pull/10151
 96 2017-04-04 21:44:42	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10152: [trivial] remove unused line in Travis config (06master...06travis_cleanup) 02https://github.com/bitcoin/bitcoin/pull/10152
 97 2017-04-04 22:25:49	0|bitcoin-git|13bitcoin/06master 1416791c5 15John Newbery: [trivial] remove unused line in Travis config
 98 2017-04-04 22:25:49	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/72bc7e1303d5...080d7c700fc3
 99 2017-04-04 22:25:50	0|bitcoin-git|13bitcoin/06master 14080d7c7 15MarcoFalke: Merge #10152: [trivial] remove unused line in Travis config...
100 2017-04-04 22:26:11	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10152: [trivial] remove unused line in Travis config (06master...06travis_cleanup) 02https://github.com/bitcoin/bitcoin/pull/10152
101 2017-04-04 22:49:15	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #10153: logging: Fix off-by-one for shrinkdebugfile default (06master...06Mf1704-offbyoneDebug) 02https://github.com/bitcoin/bitcoin/pull/10153
102 2017-04-04 23:10:51	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #10154: init: Remove redundant logging code (06master...06Mf1704-lognodebug) 02https://github.com/bitcoin/bitcoin/pull/10154