1 2016-10-20 15:18:57 <roconnor> Is there some reason why the script commitment isn't also segregated in segwit?
 2 2016-10-20 15:19:38 <arubi> you mean for witness scripts nested in p2sh?
 3 2016-10-20 15:19:55 <arubi> (because bare witness scripts do have everything in the witness)
 4 2016-10-20 15:25:18 <roconnor> I was thinking of the P2WSH case.  We could even segregate the 32-byte- scriptPubKey.
 5 2016-10-20 15:25:35 <arubi> that is in the witness
 6 2016-10-20 15:26:40 <roconnor> I mean segregate the 32-byte hash of the scriptPubKey, which would shrink the offical transaction size by a further 32 bytes.
 7 2016-10-20 15:27:01 <roconnor> But now I realise that segwit is compatable with the existing addressing systems.
 8 2016-10-20 15:27:15 <arubi> that's only segwit scripts nested in p2sh
 9 2016-10-20 15:27:42 <roconnor> Hmm, I'm not being very clear.
10 2016-10-20 15:27:49 <arubi> roconnor, the only case were you'd see the 32 byte hash in the non segregated scriptsig is when redeeming a p2sh(p2wsh\p2wpkh)
11 2016-10-20 15:28:22 <arubi> it's there because of p2sh which is being redeemed (the 32 byte hash was paid to by a hash160 of itself -- p2sh)
12 2016-10-20 15:28:51 <arubi> so it's pushed to scriptsig, old nodes are happy that it matches, and there it stays.  redeem a bare p2wsh and the redeemscript is already segregated
13 2016-10-20 15:29:15 <arubi> and you don't need to push the 32 byte hash anywhere, just like you don't need to push the hash160 of p2sh
14 2016-10-20 15:30:45 <roconnor> So in the P2WSH example, the scriptPubKey in a transaction is 0 <32-byte-hash>
15 2016-10-20 15:31:14 <roconnor> But we could, in principle, make it just OP_1
16 2016-10-20 15:31:22 <roconnor> and hide the 32-byte-hash in the coinbase.
17 2016-10-20 15:32:28 <arubi> you mean put the scriptpubkey, from the paying transaction in the previous block's coinbase?
18 2016-10-20 15:33:07 <roconnor> put the scriptpubkey from the paying transction into the coinbase of the block it is commited into.
19 2016-10-20 15:34:11 <arubi> so: ... [tx0|block0] ... -> [tx1|block1]  ,  that would be tx0's scriptpubkey and block0's coinbase, am I getting it correctly now?
20 2016-10-20 15:35:51 <roconnor> I don't quite follow your notation.
21 2016-10-20 15:36:23 <arubi> tx0 is paying to p2wsh, has a '0 0x20 ...' scriptpubkey in its output
22 2016-10-20 15:36:28 <arubi> and is mined in block0
23 2016-10-20 15:36:51 <arubi> so, that scriptpubkey will be committed to in block0's coinbase?
24 2016-10-20 15:37:55 <roconnor> tx0 would have a 'OP_1' scriptPubKey.  The 0x20... would instead be committed block0's coinbase.
25 2016-10-20 15:38:10 <arubi> right, sorry.  okay
26 2016-10-20 15:38:53 <arubi> well, it's interesting..  I think it might break current signing of mixed "pay to segwit" and "pay to non segwit" scripts tough
27 2016-10-20 15:39:06 <roconnor> yes.
28 2016-10-20 15:39:48 <roconnor> and the more I think about it, the more issues I see.  The TXID doesn't commit the ouptuts, so doesn't make a useful id for accounting purposes.
29 2016-10-20 15:41:12 <roconnor> I think something could be built to support a further transaction boost around this, but maybe it is too complicated.
30 2016-10-20 15:42:02 <arubi> I never considered "aggregating" outputs like that really.. cool idea.
31 2016-10-20 15:44:00 <roconnor> Yeah,  it's not quite as nice as I originally imagined, but maybe something to think about.
32 2016-10-20 15:46:42 <roconnor> I was thinking about the maximum tx rate we could get if we removed both scriptSigs (segwit) and scriptPubKeys (this idea).
33 2016-10-20 15:47:43 <roconnor> Now that I'm talking abou it, we could probably also combine all transactions into a single transaction per block.
34 2016-10-20 15:48:04 <arubi> yea, that's already pretty easy with segwit if folks play along with each other
35 2016-10-20 15:48:26 <arubi> simply sign everything as anyonecanpay|single and you can combine all inputs and outputs to one transaction
36 2016-10-20 15:48:28 <roconnor> And again, store the data on how to actually carve up inputs and ouptuts into the original transactions inside the coinbase.
37 2016-10-20 15:49:16 <roconnor> arubi: once you have empty scriptSigs and only an OP_1 for the scriptPubKey, you don't even need to sign things as anyonecanpay|single to combine inputs and outputs.
38 2016-10-20 15:49:46 <roconnor> you just mash everything together and describe how to restore it inside the coinbase.
39 2016-10-20 15:50:28 <roconnor> as I trivial example you could mash all the inputs, and the store the original transactions in a merkle tree in the coinbase.
40 2016-10-20 15:50:41 <roconnor> but you'd probably want to do something a bit smarter.
41 2016-10-20 15:53:06 <arubi> I see what you mean about not having to sign in a special way.  how large do you think the data would be for the reconstruction of the original transactions?
42 2016-10-20 15:54:14 <arubi> or is it something that a node can figure out for themselves locally from the coinbase only?
43 2016-10-20 15:54:43 <arubi> (locally once they get the mined block)
44 2016-10-20 15:55:32 <roconnor> to reconstruct the orginal transactions, I'm thinking you specify the inputs as a range from the mashed inputs and the outputs as a range from the mashed outputs.
45 2016-10-20 15:55:48 <roconnor> So you need 2 ranges, let's say we can specify a range in 4 bytes.
46 2016-10-20 15:55:59 <roconnor> So 8 bytes per original transaction.
47 2016-10-20 15:56:29 <roconnor> Of course this would be all hashed up into one 32-byte number for "offical" accounting purposes in the coinbase.
48 2016-10-20 15:57:32 <roconnor> But as far as bandwidth, we'd need those 8 bytes per transaction.
49 2016-10-20 15:58:44 <roconnor> Here I'm assuming there are less than 2^16 inputs and outputs per block.
50 2016-10-20 15:59:01 <roconnor> I haven't counted the maximum number of inputs and outputs per block there really are.
51 2016-10-20 16:01:33 <arubi> I haven't gotten the chance to really dive into range proofs yet unfortunately, so I can't validate or contradict what you suggested, the most I've now with segwit is getting close to 10k (outputs at least), so not close but not so far either..  are the 8 bytes supposed to be a unique ID for a transaction while it's still unconfirmed?
52 2016-10-20 16:01:59 <arubi> most I've seen (re. outputs/inputs #s)
53 2016-10-20 16:03:47 <arubi> or was it 10k transactions?  it was only a couple days ago..  too bad I can't remember
54 2016-10-20 16:04:31 <roconnor> I don't mean range proof in the cryptographic sense.
55 2016-10-20 16:04:47 <roconnor> Actually, the data needed is even simpler.
56 2016-10-20 16:05:05 <roconnor> Think about the original set of transactions.
57 2016-10-20 16:05:47 <roconnor> we combine them by just concatenating all the inputs and all the outputs in sequence.
58 2016-10-20 16:06:15 <roconnor> into one large transaction (this doesn't work if one transaction spends an output made in the same block, but lets ignore that for now).
59 2016-10-20 16:06:52 <roconnor> To recover the original dividing lines we just need a list of the indexs of the inputs and outputs where they were merged.
60 2016-10-20 16:07:31 <roconnor> That is about two indexes per transaction, on for the input side and one for the output side.
61 2016-10-20 16:07:51 <roconnor> if each index fits in 2 bytes, that's only 4 bytes per transaction.
62 2016-10-20 16:08:51 <roconnor> arubi: 10k transactions is probably right.  Though you can probably make a super large transaction with one output and even more inputs.
63 2016-10-20 16:09:07 <roconnor> so maybe you could have a transaction with 20k inputs and one output?
64 2016-10-20 16:09:24 <roconnor> so maybe we need a few more bytes in some cases.
65 2016-10-20 16:09:26 <arubi> I think that's just over the sigops limit, but maybe :)
66 2016-10-20 16:10:12 <roconnor> meh, people can make transaction without using OP_CHECKSIG.  I mean, they will lose their money, but it can be done.
67 2016-10-20 16:10:53 <arubi> oh sure, I guess they could.  a miner might claim it all as fee though
68 2016-10-20 16:10:59 <arubi> (not that it matters here)
69 2016-10-20 16:11:10 <arubi> I see about the indexes, thanks for explaining it
70 2016-10-20 16:11:10 <roconnor> right, I'm just trying to compute some upper bounds here.
71 2016-10-20 16:11:30 <roconnor> arubi: thanks.  It'd be easier to explain with a whiteboard.
72 2016-10-20 16:12:24 <roconnor> anyhow, I see now that there are many problems with this idea.
73 2016-10-20 16:12:56 <arubi> heh, being in a uni setting again will be nice.  the idea is very
74 2016-10-20 16:13:15 <arubi> * very original, really would like to think about it more
75 2016-10-20 22:58:13 <xmlnewbi> im trying to test multi-sig on testnet, I need to importAddress the final address to watch. On mainnet it works. but on testnet its saying invalid address. Even though Im making a multi-sig testnet address with 3 hd keys with all the right version bits
76 2016-10-20 22:58:28 <xmlnewbi> is there a flag or something I need to do to test multi-sig testnet?