1 2015-12-20 03:32:30 <maaku> "Capacity increases for the Bitcoin system" is a plan I can fully support. It is my understanding that a number of other bitcoin core contributors have privately also concured with this plan as a short- to medium-term proposal.
  2 2015-12-20 03:32:31 <maaku> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
  3 2015-12-20 03:33:16 <maaku> Are there others besides me who would like to publicly sign on to this proposal so we can stop bikeshedding, start implementing, and move forward?
  4 2015-12-20 03:34:56 <harding> I'm not a developer, but I'm happy to fully support that plan with documentation and anything else I can do to help.
  5 2015-12-20 03:36:23 <sipa> maaku: ack
  6 2015-12-20 03:46:59 <aj> maaku: (it would be good to have some sort of timeline on the "Finally--at some point the capacity increases from the above may not be enough" that's more than just "at some point")
  7 2015-12-20 03:47:44 <aj> maaku: (or, if not a timeline, some sort of metrics that could indicate when "some point" is approaching and action needs to be taken)
  8 2015-12-20 03:48:15 <maaku> aj: "at some point" follows deployment of some or all of the above technologies (segwit, IBLT, weak blocks, payment channels, etc.)
  9 2015-12-20 03:48:44 <aj> maaku: sure. but does it follow immediately? in a year? in five years?
 10 2015-12-20 03:48:47 <maaku> aj: the point very much is we don't know now when the appropriate time would be or what the approapriate change would be
 11 2015-12-20 03:49:00 <maaku> but we have a plan to move forward in the near term
 12 2015-12-20 03:49:08 <maaku> we are not creating five year or 10 year plans here
 13 2015-12-20 03:50:12 <aj> maaku: personally (and i don't think my vote counts for anything), i'm totally on board for proceeding with everything else (iblt, segwit, etc) immediately, but i think more clarity is needed on when an increase to ~2MB is warranted as well
 14 2015-12-20 03:51:05 <aj> maaku: "we are not creating 5/10 year plans" -- so does that mean "at some point" is definitely less than five years away?
 15 2015-12-20 03:53:09 <maaku> aj: who knows? the point is we don't have clarity on that until we get some preliminary stuff done
 16 2015-12-20 03:54:12 <maaku> so let's stop arguing in circles about stuff that none of us have any really solid idea about, and move forward on what we know needs to get done, and what we know will provide a little bit more capacity
 17 2015-12-20 03:56:34 <aj> maaku: i don't get "who knows?" and "none of us have any solid idea about" -- surely this stuff should be known by now, or at least it should be possible to say exactly what questions need to be answered to come up with a conclusion (which would let you provide metrics now)...
 18 2015-12-20 03:57:19 <aj> maaku: not entirely relatedly, you wrote "the quadratic scaling costs in large transaction validation" -- is that limited to hashing for signatures, or are there other ways to get quadratic scaling that you know of?
 19 2015-12-20 03:58:10 <maaku> aj: do we have a better idea than six months ago? yes. but do we have sufficient information to say "in 12 months we will begin to deploy 2/4/8; or in six months we will reopen the topic for discussion" or whatever
 20 2015-12-20 03:58:40 <maaku> aj: you can also make quadratic just ECDSA validation by spending large scriptPubKeys
 21 2015-12-20 03:59:14 <sipa> we could fix the quadratic hashing inside witness scriots
 22 2015-12-20 03:59:24 <sipa> by changing how signature hashing works inside
 23 2015-12-20 03:59:39 <aj> maaku: that's quadratic in the data being passed to the sig hash function still isn't it?
 24 2015-12-20 03:59:41 <maaku> sipa: yes, we could also just measure and limit it via jonas' metric
 25 2015-12-20 03:59:50 <sipa> yes indeed
 26 2015-12-20 04:00:04 <sipa> though i prefer fixing quadratic behaviour that's totally unnecessary
 27 2015-12-20 04:00:28 <maaku> sipa: agreed but that changes CHECKSIG's behavior
 28 2015-12-20 04:00:34 <maaku> it's a soft-fork, yes, but a more invasive one
 29 2015-12-20 04:00:57 <maaku> not nack'ing, just pointing out it is complicating
 30 2015-12-20 04:01:05 <sipa> i think it's pretty minor compared to segwit
 31 2015-12-20 04:02:04 <sipa> we could also switch to pubkey recovery, making pay to pubkey hash much smaller on chain
 32 2015-12-20 04:02:09 <maaku> by invasive i mean to the ecosystem .. it's something we'd have to run by hardware wallets etc. and make sure this part of the signing code is upgradeable
 33 2015-12-20 04:02:09 <sipa> :)
 34 2015-12-20 04:02:19 <sipa> agree
 35 2015-12-20 04:02:43 <maaku> and if the answer came back that yes, it's manageable, i'd totally support it
 36 2015-12-20 04:02:46 <sipa> and with a version number in the scriots such things are relatively easy to add later anyway
 37 2015-12-20 04:03:00 <maaku> also, make CHECKSIG == CHECKSIGVERIFY a la elements
 38 2015-12-20 04:03:02 <sipa> it would just make the scaling story better immediately
 39 2015-12-20 04:03:15 <maaku> right
 40 2015-12-20 04:03:20 <sipa> maaku: not useful for ecdsa, as it doesn't support batch verifivation anyway
 41 2015-12-20 04:03:33 <maaku> ah right
 42 2015-12-20 04:03:35 <sipa> unless we change the signature format
 43 2015-12-20 04:03:48 <sipa> which, incidentally, would also increase scale :p
 44 2015-12-20 04:04:06 <maaku> damnit let's just switch to Schnorr! ;)
 45 2015-12-20 04:04:30 <aj> let's git segwit in first? :)
 46 2015-12-20 04:04:35 <aj> git? get, geez...
 47 2015-12-20 04:04:41 <sipa> it's already in git!
 48 2015-12-20 04:04:42 <sipa> hahahaha
 49 2015-12-20 04:04:46 <sipa> evil laughter
 50 2015-12-20 04:04:52 <sipa> i need sleep
 51 2015-12-20 04:08:55 <harding> https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165
 52 2015-12-20 04:18:28 <maaku> but yeah this shows that as a matter of bikeshed avoidance segwit script v0 should be minimally different from bitcoin script, if changed at all
 53 2015-12-20 04:39:10 <jl2012> CodeShark and I are working on a segwit BIP. Please feel free to comment: https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
 54 2015-12-20 05:09:00 <maaku> i assume you are coordinating with sipa?
 55 2015-12-20 05:15:49 <sipa> i will :)
 56 2015-12-20 05:44:41 <jl2012> I suggest we could settle with the witness program format now and define and new address type like BIP13, so wallets may start working on it
 57 2015-12-20 05:47:45 <sipa> jl2012: agree
 58 2015-12-20 05:48:06 <sipa> i think we do need to add the fraud proof data, though
 59 2015-12-20 05:48:20 <sipa> it can be added later, but at the cost of a new commitment
 60 2015-12-20 05:53:56 <maaku> fraud proof data should definately be incorproated into segwit
 61 2015-12-20 05:54:10 <maaku> jl2012: please remove the block size limit section from the bip
 62 2015-12-20 06:09:38 <jl2012> maaku: ok, but that will require another BIP
 63 2015-12-20 06:10:56 <jl2012> For fraud proof, ok if it does not delay the deployment
 64 2015-12-20 06:12:24 <jl2012> The commitment structure allows any number of new commitments with one hash
 65 2015-12-20 06:59:41 <arioBarzan> one issue regarding wiki for BIP-0065. "Trustless Payments for Publishing Data" is insecure guys.
 66 2015-12-20 07:05:08 <arioBarzan> it says spending reveals encryption keys to the data. It's right that for spending the coins, publisher has to reveal something such that ripemd160(sha256("that-thing")) should equals a pre-defined data stored in scriptPubKey
 67 2015-12-20 07:06:32 <arioBarzan> but there is no guaranty for buyer to be able to decrypt the information, using "that-thing"
 68 2015-12-20 07:08:54 <arioBarzan> publisher could encrypt the information with a "secret-key" and then put ripemd160(sha256("irrelevant-key")) in scriptPubKey
 69 2015-12-20 07:09:42 <arioBarzan> am I wrong petertodd ?
 70 2015-12-20 07:10:28 <midnightmagic> arioBarzan: i think that's partly why it's in chunks. if the first chunk doesn't decrypt anything, then nobody's paying for the rest.
 71 2015-12-20 07:13:16 <midnightmagic> paypub can be seen in its slightly post-conceptual stage here: https://github.com/unsystem/paypub
 72 2015-12-20 07:16:29 <arioBarzan> midnightmagic: thanks. it would be nice if wiki also had relevant reference though.
 73 2015-12-20 07:18:13 <midnightmagic> ehh. it's peter. he assumes people know more than they do. the nature of that paragraph isn't to highlight paypub, but I'm assuming he's giving people enough to find out on their own by using the name.
 74 2015-12-20 07:22:59 <arioBarzan> I have been playing with CLTV a little and was fun. anything important has happened since its enforcement on main-chain, like chain forks, etc. ?
 75 2015-12-20 07:25:26 <aj> arioBarzan: you could use a SNARK to prove the hash corresponds to the private key for a given public key :) but otherwise you're right
 76 2015-12-20 08:41:04 <maaku> jl2012: "The commitment structure allows any number of new commitments with one hash" <--- yes but we may want to change the structure of that hash tree, and it'd be better to get that in first
 77 2015-12-20 08:42:35 <maaku> e.g. putting commitments in as a merkle mountain rage
 78 2015-12-20 08:56:28 <sipa> maaku: how does that help?
 79 2015-12-20 08:57:03 <maaku> sipa: minimizing proof size for future commitments, while favoring earlier commitments
 80 2015-12-20 08:57:32 <sipa> the commitment structure i implemented is optimal in size for up to ~20 commitments
 81 2015-12-20 08:57:44 <sipa> and very close to it afterwards
 82 2015-12-20 08:59:25 <maaku> sipa: you're doing a simple merkle tree. that's not optimal
 83 2015-12-20 08:59:43 <sipa> maaku: i don't understand
 84 2015-12-20 08:59:49 <sipa> how is it not optimal?
 85 2015-12-20 08:59:58 <sipa> what bytes can be saved?
 86 2015-12-20 09:00:06 <maaku> i think we are talking past each other. what structure are you talking about?
 87 2015-12-20 09:00:24 <sipa> look at the code, there are comments about it even :)
 88 2015-12-20 09:01:07 <sipa> it's similar to namecoin mm commitments, but using a non-broken scheme for determining locations in the tree
 89 2015-12-20 09:03:22 <maaku> i know, i'm reading it. the depth of the merkle tree is constant, no?
 90 2015-12-20 09:03:28 <sipa> no
 91 2015-12-20 09:03:55 <sipa> it can be anything from 0 to 32
 92 2015-12-20 09:04:20 <sipa> and the positions of commitments in it aren't constant either
 93 2015-12-20 09:04:46 <maaku> sipa: but you can have an unbalanced tree of commitments?
 94 2015-12-20 09:11:36 <jl2012> maaku, I think that's just a binary tree. And the merkle path to the actual commitment is sent as the witness of the coinbase tx
 95 2015-12-20 09:13:16 <maaku> i see. ok i was misinterpreting the comment
 96 2015-12-20 10:00:45 <jl2012> i'm going to write a BIP for the SW payment address. I'll do it like P2SH address: address version|witness program|checksum, where checksum is first 4 bytes of dSHA256(address version|witness program)
 97 2015-12-20 10:01:15 <jl2012> the length of the address is variable, depends on the length of the witness program. Does it make sense?
 98 2015-12-20 10:01:57 <jl2012> and what address prefix? W?
 99 2015-12-20 10:06:05 <maaku> i know this is bikeshedding territory, but I would really like to use something other than base58 for these addresses
100 2015-12-20 10:10:29 <aschildbach> jl2012: If the address can be longer than current addresses, be aware addresses are used in QR codes.
101 2015-12-20 10:19:34 <jl2012> aschildbach, I think that could be at most double of current addresses
102 2015-12-20 10:23:03 <Luke-Jr> jl2012: SW works inside P2SH addresses
103 2015-12-20 10:23:12 <jl2012> maaku, no matter what scheme is used, it must encode the same amount of information......and won't be human memorable anyway
104 2015-12-20 10:23:31 <jl2012> Luke-Jr, I know, but that's very inefficient
105 2015-12-20 10:23:46 <Luke-Jr> jl2012: well, ideally addresses should be obsolete anyway
106 2015-12-20 10:23:47 <jl2012> it's there just for backward compatibility
107 2015-12-20 10:24:58 <jl2012> if we want to bootstrap the use of  SW, it must be familiar to existing users
108 2015-12-20 10:27:51 <adam3us> jl2012 why is p2sh inefficient isnt that norm for non trivial scripts?
109 2015-12-20 10:29:02 <jl2012> adam3us: please read the examples at https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
110 2015-12-20 10:31:00 <Luke-Jr> jl2012: any new address format isn't going to be backward compatible..
111 2015-12-20 10:31:32 <adam3us> looking hmm
112 2015-12-20 10:32:15 <jl2012> Luke-Jr: of course, but so? And I believe this will be truly the last address format as SW is very flexible
113 2015-12-20 10:33:12 <aschildbach> jl2012: Double the length doesn't sound good for scannability. Addresses have never been about memorability.
114 2015-12-20 10:34:11 <Luke-Jr> (btw, that BIP draft probably isn't up to date, as it still reserves 32 bytes of the coinbase for the commitment)
115 2015-12-20 10:34:55 <jl2012> aschildbach: it is doubled just because SW allows  41 byte program. And there is no way to compress
116 2015-12-20 10:35:03 <maaku> jl2012: there are very severe problems with base58 with regard to variable lengths, lack of error correction, inability to phonetically read
117 2015-12-20 10:35:12 <maaku> it's a UX nightmare and never should have been used
118 2015-12-20 10:35:14 <jl2012> Luke-Jr: the commitment part is not finished
119 2015-12-20 10:36:23 <Luke-Jr> the concept of a single-use token seems lost on users anyway
120 2015-12-20 10:36:26 <Luke-Jr> addresses just need to die
121 2015-12-20 10:37:01 <Luke-Jr> users were never generally familiar with them, so it makes no sense to claim we need it to be familiar
122 2015-12-20 10:38:24 <jl2012> Luke-Jr every bitcoin users have the experience to use base58 address
123 2015-12-20 10:39:18 <jl2012> in the past 5 years, were there any better proposal AND actually got widely adopted?
124 2015-12-20 10:39:33 <Luke-Jr> jl2012: base58 is irrelevant to the address format, and it seems the majority of users *still* don't understand addresses
125 2015-12-20 10:39:47 <maaku> jl2012: we have a chance to deprecate such usage. infrastructure HAS to update to use SW, so this is an opportunity  to make the adjustment to no-address bitcoin
126 2015-12-20 10:39:48 <Luke-Jr> jl2012: payment protocol is half widely adopted (sending to it)
127 2015-12-20 10:40:47 <jl2012> Luke-Jr: I personnaly never used payment protocol
128 2015-12-20 10:41:12 <jl2012> and I'm not sure if any exchange is using it
129 2015-12-20 10:41:27 <jl2012> at least not those I'm familiar with
130 2015-12-20 10:42:42 <jgarzik> jl2012, exchanges are exchanges, payment processors are payment processors, two different things.  Coinbase, Bitpay, GoCoin use BIP 70 AFAIK
131 2015-12-20 10:43:00 <jgarzik> some exchanges do payment processing too - not sure about the protocol
132 2015-12-20 10:43:43 <jl2012> My motivation is very simple: I don't want the adoption of SW is deferred due to any irrelevant reason
133 2015-12-20 10:43:48 <Luke-Jr> jgarzik: payment protocol isn't merely for payment processors
134 2015-12-20 10:43:54 <jgarzik> nod
135 2015-12-20 10:44:36 <jl2012> I guess BIP70 is already ready for SW. But obviously there is still many people not using BIP70
136 2015-12-20 10:47:28 <aschildbach> Yeah especially on the wallet side BIP70 is not very widespread.
137 2015-12-20 10:48:24 <jl2012> having a new address type is the easiest way for wallets to adopt native SW (not with the P2SH hack)
138 2015-12-20 10:49:23 <jl2012> and using the same algorithm minimize the change in wallets
139 2015-12-20 10:54:06 <Luke-Jr> IMO P2SH-hack for quick-adoption and full adoption via payment protocol is sufficient
140 2015-12-20 10:55:57 <jgarzik> P2SH is pro-privacy and pro-upgradability
141 2015-12-20 10:56:15 <jgarzik> Using P2SH out of the gate is nice
142 2015-12-20 10:57:19 <jgarzik> You can even upgrade to a different type of signature with P2SH
143 2015-12-20 10:57:19 <jl2012> jgarzik, there is nothing about privacy here, please read the examples at https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
144 2015-12-20 10:58:40 <jl2012> you have exactly the same level of privacy with native v1 SW and SW in P2SH. But SW in P2SH costs more to store, transmit, and validate
145 2015-12-20 10:58:45 <jgarzik> jl2012, Just make a general observation.   Using P2SH makes <new feature> indistinguishable from <old, in-use feature> and <other feature we haven't invented yet>
146 2015-12-20 10:58:51 <jgarzik> *making
147 2015-12-20 10:59:20 <jgarzik> Presumably witness & non-witness look the same in TxOut
148 2015-12-20 11:03:07 <jl2012> jgarzik: it is irrelevant  as more people use SW. SW in P2SH  must obsolete not long in the future due to its inefficiency
149 2015-12-20 11:03:10 <Luke-Jr> jgarzik: the ideal case for SW can't
150 2015-12-20 11:03:27 <Luke-Jr> jgarzik: P2SH requires data in the scriptSig field
151 2015-12-20 11:13:43 <jgarzik> Luke-Jr, nod
152 2015-12-20 11:43:05 <jtimon> wumpus: sipa can we please merge or close #6625 ?
153 2015-12-20 12:12:28 <jgarzik> jtimon, I don't see any obstacle to merging
154 2015-12-20 12:12:48 <jgarzik> jtimon, It was ACK'd for 0.12
155 2015-12-20 12:32:03 <jtimon> jgarzik: but is still unmerged, I just want to know if I should maintain that in my consensus branch or just forget about it, if it's not going to be merged soon, I'd rather not wait for the next "needs rebase" to know the answer
156 2015-12-20 15:05:00 <coreRPCquery> Hello all.. i am unsure if i have stumbled upon a bug in heavily used core nodes. My node is long lived & most certainly synched. uptime for weeks. version 011.2 - when trying RPC command to 'listreceivedbyaddress' i am not finding all the results... When looking to 'dumpprivkey' or 'signmessage' it works, so i am 100% sure i have the private key f
157 2015-12-20 15:05:01 <coreRPCquery> or said address.... but i am not seeing its history in list
158 2015-12-20 15:05:36 <coreRPCquery> i am able to do 'gettransaction' for the txid also, and returns the result expected.... it would appear the list command does not return what i am expecting.... bug or operator error?
159 2015-12-20 15:06:48 <coreRPCquery> also, this node has NO watch-only ever been imported, however doing a list command with True/False for 'includewatchonly' and 'includeempty' will yield different #s of results...
160 2015-12-20 15:51:40 <siegfired> hi!
161 2015-12-20 15:52:57 <coreRPCquery> furthermore, validateaddress also returns back that it belongs to the wallet, and is valid etc... so there is definitely something wrong with the 'listreceivedbyaddress' command
162 2015-12-20 17:28:08 <t7> :o
163 2015-12-20 17:28:30 <t7> on HEAD?
164 2015-12-20 17:40:48 <sipa> maaku: no, it can't be unbalanced
165 2015-12-20 17:42:15 <Ylbam> 438
166 2015-12-20 17:43:01 <sipa> maaku: all data is at the leaves
167 2015-12-20 18:03:56 <maaku> sipa: that's what I meant by suboptimal -- some commited structures are more space critical than others, and it would be nicer to have a tree structure that allowed those to be placed at a higher level in the tree
168 2015-12-20 18:04:16 <maaku> but reading the code (and with some help in scrollback), I think unbalanced trees are ok, right?
169 2015-12-20 18:04:28 <maaku> it's just checking a path so the validation code is in fact structurally agnostic
170 2015-12-20 18:04:50 <maaku> *more space critical = more sensitive to proof size
171 2015-12-20 18:06:13 <sipa> maaku: the size of the tree is shared for all commitments
172 2015-12-20 18:06:49 <maaku> sipa: where in the code is that required?
173 2015-12-20 18:06:59 <sipa> and the path is determined by a hash, not chosen per commitment
174 2015-12-20 18:07:31 <sipa> if you don't do that, you could have two separate witness commitnents for a block
175 2015-12-20 18:07:50 <maaku> sipa: not if you specify the path explicitly
176 2015-12-20 18:08:09 <sipa> the path is part of the witness
177 2015-12-20 18:08:27 <maaku> yes, [<magic> <path> <hash>]
178 2015-12-20 18:08:47 <sipa> i really don't follow
179 2015-12-20 18:09:28 <maaku> right now you are taking a hash to figure out what index to place the commitment. i really don't see the need for that
180 2015-12-20 18:09:44 <maaku> put the path to the witness in the coinbase commitment instead
181 2015-12-20 18:10:01 <sipa> then why do you not just put all commitments in the coinbase?
182 2015-12-20 18:10:19 <sipa> the point is combining so you can compress
183 2015-12-20 18:10:20 <maaku> so the essential information of the commitment is <root hash> and <path> both of which are in the coinbase string (or wherever the commitment goes)
184 2015-12-20 18:10:38 <maaku> what do you mean by compress?
185 2015-12-20 18:11:03 <sipa> you can't go stuff all paths for every possible commitment in the base block
186 2015-12-20 18:11:24 <maaku> maybe our confusion is over "path" . by path I mean "left, right, left, left, right"
187 2015-12-20 18:11:32 <sipa> the point is having o(1) data in the block, and allow near infinite commitments in it
188 2015-12-20 18:11:35 <sipa> yesz i know
189 2015-12-20 18:11:37 <maaku> which can be encoded as an integer -- 0b01001
190 2015-12-20 18:11:43 <maaku> not the actual hashes
191 2015-12-20 18:11:43 <sipa> yes, i know
192 2015-12-20 18:11:55 <sipa> but it's one integer per possible commitment
193 2015-12-20 18:12:10 <maaku> per consensus critical commitment
194 2015-12-20 18:12:14 <maaku> i do not see this as an issue
195 2015-12-20 18:12:40 <sipa> i really prefer something that obviously scales well beyond that
196 2015-12-20 18:12:56 <sipa> and allows us to trivially add new commitments
197 2015-12-20 18:13:19 <maaku> if that's the case you can use a purposefully unbalanaced tree with commitments at fixed positions -- e.g. a merkle mountain range or huffman tree
198 2015-12-20 18:13:28 <sipa> instead of worrying whether we'll go exceed some limit
199 2015-12-20 18:13:59 <sipa> perhaps just put the depth in the commitment itself
200 2015-12-20 18:14:23 <sipa> if the commitment uses a different hash than the merkle structure, i think that is safe
201 2015-12-20 18:14:55 <maaku> sipa: it's not about exceeding some limit. imagine we have 1000 different commitments, but I still want (e.g.) the witness or fraud proof or block header commiment to have a short path, because minimal proof size
202 2015-12-20 18:16:25 <maaku> an unbalanced tree structure lets that happen. you can put your factom proofs or whatever deep in the tree, but keep the important protocol-sensitive stuff that needs to be kept small, higher up
203 2015-12-20 18:16:48 <sipa> yes, this would allow unbalanced trees
204 2015-12-20 18:17:09 <sipa> but i'm not convinced it's safe
205 2015-12-20 18:17:54 <maaku> btw i'm pretty sure that your code does allow unbalanced trees, so long as you put the commitment (if needed) for the other trees somewhere else
206 2015-12-20 18:18:05 <maaku> although it does so somewhat annoyingly because you have to grind the nonce
207 2015-12-20 18:18:19 <maaku> *in a somewhat annoying way
208 2015-12-20 18:18:44 <sipa> well factom things can use a non-consensus commitment
209 2015-12-20 18:19:15 <sipa> the reason for not reusing the namecoin root but a separate one is exactly to separate the consensus critical one and the one defined externally
210 2015-12-20 18:19:27 <maaku> it was just an example
211 2015-12-20 18:19:48 <maaku> merged mining headers would be a less sensitive example of something non-consensus
212 2015-12-20 18:20:08 <sipa> so those can go in the namecoin root
213 2015-12-20 18:20:20 <maaku> but I don't really see the need to keep them separate
214 2015-12-20 18:20:29 <sipa> ah
215 2015-12-20 18:20:36 <sipa> the reason is infrastructure
216 2015-12-20 18:21:18 <maaku> let's say a commitment is added in the future -- to older nodes it appears as if there is non-consensus information in the tree
217 2015-12-20 18:21:30 <sipa> i think it is hard to have part of the commitments come from outside and part from inside, and force mining software to combine them into a single grinded commitment using different algorothms
218 2015-12-20 18:21:57 <sipa> not in my proposal
219 2015-12-20 18:22:22 <sipa> the tree is never materialized
220 2015-12-20 18:25:03 <sipa> but i think it can be made to support unbalanced trees
221 2015-12-20 18:25:39 <sipa> if the path still comes from the randomizer, but its length is per-commitment
222 2015-12-20 18:28:40 <maaku> i'll have to take this up with you at a better hour, it's late here
223 2015-12-20 18:29:51 <sipa> ok!
224 2015-12-20 18:30:03 <sipa> i'll adapt my code to support unbalanced trees
225 2015-12-20 18:45:36 <jl2012> sipa: "if the path still comes from the randomizer, but its length is per-commitment": so it's up to the miner to decide how deep they want to put the commitment?
226 2015-12-20 18:45:44 <juneBug> Hello
227 2015-12-20 18:45:44 <juneBug> https://litecointalk.org/index.php?Ja=12&topic=28005.0
228 2015-12-20 18:45:54 <juneBug> Check it out... urgent request.
229 2015-12-20 18:46:41 <katu> juneBug: oh god, how many channels are you going to spam :/
230 2015-12-20 18:46:54 <juneBug> how many are there... and its not spam
231 2015-12-20 18:47:00 <juneBug> its saving a life
232 2015-12-20 18:47:03 <juneBug> 3 to be exact
233 2015-12-20 18:49:59 <jl2012> I think that could be a good idea, especially when the total number of commitment is not a power of 2, it is most efficient
234 2015-12-20 18:59:52 <jl2012> I notice that you put the path as the first item in the coinbase witness. So the length of the path divided by 32 will tell you the depth
235 2015-12-20 19:01:12 <jl2012> I assume when we have another consensus critical commitment in the future, it's path would be the second item in the coinbase witness?
236 2015-12-20 19:16:08 <sipa> jl2012: right
237 2015-12-20 19:16:53 <sipa> jl2012: it's path would be wherever it wants... if it has its own associated optional data structure, the path will go in that data structure
238 2015-12-20 19:22:03 <jl2012> sipa: in that case you may even save a byte in the coinbase (or wherever else) for the depth of the tree
239 2015-12-20 19:23:01 <jl2012> the depth is determined by the length of the path. If you want to restrict it to 32 level, just restrict the path to be 32*32 at max
240 2015-12-20 19:29:03 <sipa> jl2012: right, i was formerly of the opinion that the (in witness) commitment could not have any influence over where in the tree it goes
241 2015-12-20 19:29:51 <sipa> jl2012: but talking to maaku made me realize it's fine to let the witness commitment decide its own depth, as long as the position is determined in such a way that if two commitments for the same data exist in the tree, one is a child of the other
242 2015-12-20 19:33:16 <Eliel> which kinds of multisigs are currently considered standard? n of m is, obviously but if someone wanted (1 of 2) and (1 of 1), would that be standard?
243 2015-12-20 19:44:50 <sipa> Eliel: all of them
244 2015-12-20 19:44:58 <Eliel> (in case it wasn't clear, a multisig that always requires signature with a specific key and also requires one signature from a set of 2 keys)
245 2015-12-20 19:45:40 <sipa> there are no longer any standardness rules on p2sh
246 2015-12-20 19:45:48 <Eliel> ah, great.