--- Log opened Wed Jan 08 00:00:01 2020 02:55 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 04:18 -!- jonatack [~jon@213.152.162.94] has joined ##ctv-bip-review 06:42 -!- jonatack [~jon@213.152.162.94] has quit [Ping timeout: 268 seconds] 06:43 -!- jonatack [~jon@109.202.107.147] has joined ##ctv-bip-review 07:27 -!- jonatack [~jon@109.202.107.147] has quit [Ping timeout: 260 seconds] 08:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##ctv-bip-review 09:37 <@jeremyrubin> Does anyone have any feelings on RPCs returning metadata? I'm working on a new RPC which returns a lot of transactions and I want them to have custom lables & "suggestions" for color (or other properties) when combine with the viewer software I'm making 09:37 <@jeremyrubin> It just seems weird to return a color from core :p 12:50 < bsm1175321> Deleted keys could be known, that would be a compromise of your vault device tasked with deleting keys (e.g. evil maid firmware hack). The solution to this is to use multiple devices and have them each contribute entropy, then as long as any one of them deletes their entropy, the key is deleted. 12:50 < bsm1175321> A better idea is to use a RNG to generate a signature, and compute the corresponding pubkey using ecrecover. This requires SIGHASH_NOINPUT. We discuss this but prototype a device that actually does delete keys. 12:51 < bsm1175321> The taproot BIP also adds new commitments to the pubkey that prevent (Schnorr) pubkey recovery from a signature. Thus, an additional flag to prevent those pubkey commitments is needed. SIGHASH_NOPUBKEY or some such. 12:52 < bsm1175321> That would be the optimal case for "deleted key" covenants, and could be contrasted with OP_CTV -- where multi-sig in your vault is simpler. 13:15 < harding> jeremyrubin: agree that returning a color from core sounds weird. Mabye you could deterministically derive the color from the other data returned? (E.g. hash a name and use the first few bytes as the RGB color code) 18:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds] 20:21 <@jeremyrubin> harding: probably something like that is best, but in this case color is supposed to convey something... and random would be too much noise I think/lead to bad colors. I'll leave it in the RPCs for now because it's easy to remove later -- it's just much more convenient to compile it in than to manually map it in the application layer 20:21 <@jeremyrubin> e.g. txs which move to hot wallets are red 20:32 < aj> jeremyrubin: so add the wallet metadata directly, not a colour? "vout": [ { .., "wallet": "hothothot" } ] ? 20:42 <@jeremyrubin> yeah I am doing that already; trying to define some sort of common format for vaults, congestion control, etc 20:43 <@jeremyrubin> The nice thing about adding the color *in addition* to the metadata (e.g., send_to_hot) is that it makes it easier for the tools I'm working on to pick up new contracts 20:44 <@jeremyrubin> h/o I'll share a gif 20:47 <@jeremyrubin> https://imgur.com/a/HoVtU1b 20:50 <@jeremyrubin> The code for viewing vaults like this is pretty generic; ideally I could add sort of arbitrary information per-tx which is not derivable from the transactions themselves 20:50 < aj> "this post may contain erotic or adult imagery"... well done imgur ai 20:51 <@jeremyrubin> Which is what I have currently -- I guess my question is more if it's just weird or if it's actively bad to return some more application specific metadata from core 20:51 <@jeremyrubin> If so; I'd probably go the way of maintaining a separate (knots-like) patch set, but that's a maitnence nightmare. I'd rather just put it behind a verbose flag or something 20:52 <@jeremyrubin> aj: well I think it is pretty sexy so ;) 23:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##ctv-bip-review --- Log closed Thu Jan 09 00:00:04 2020