--- Log opened Mon Jan 13 00:00:05 2020
01:52 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds]
02:49 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##ctv-bip-review
02:54 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 268 seconds]
02:55 -!- jonatack [~jon@213.152.161.138] has joined ##ctv-bip-review
07:57 -!- jonatack [~jon@213.152.161.138] has quit [Ping timeout: 240 seconds]
09:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##ctv-bip-review
10:34 < kanzure> where has 843ceb10947cf49cc6d28f48b2698b7de9e1afe8 gone?
11:28 < kanzure> what is a "2 input CHECKTEMPLATEVERIFY"? is it a UTXO that was created by a transaction with 2 inputs, or is it a CHECKTEMPLATEVERIFY spent by two separate inputs?
11:54 < kanzure> i think i need a more practical demonstration of the half-spend fee-burn reuse stuff
11:54 < kanzure> due to multiple inputs
11:57 < kanzure> 15:34 < jeremyrubin> Only one input breaks some vault use cases so I'd prefer to keep it.
11:57 < kanzure> what's this one about?
11:59 < kanzure> how does the "spend two outputs at once that allow two inputs, converting half the funds into fees" attack work?
12:24 < kanzure> in the congestion controlled batch transactions, who is paying the fees to publish the fan-out transaction later? which recipient pays that?
12:49 < aj> kanzure: in my mind 2-input CTMPLV is a tx with 2 inputs, at least one of which was secured by CTMPLV -- the other might also be CTMPLV (in which case things are complicated) or it might be paying fees
12:58 < harding> kanzure: for the fee attack, if you have two 1 BTC inputs that each pay "<hash(1 BTC vout to Alice)> CTV" then Alice gets 1 BTC and the other 1 BTC from the input value is unallocated (i.e. fees).
12:58 < harding> s/vout/vout0/
13:00 < bsm1175321> That's one reason we constructed our vault work around 1-in-1-out transactions (SIGHASH_SINGLE) allowing fees to be added separately. If multiple inputs/outputs are enforced, there are rearrangement/fee attacks, and you haven't satisfied the goal of ensuring that these coins go <somewhere>
13:01 < bsm1175321> So I really don't understand the multiple input thing.
13:02 < bsm1175321> I'm also afraid that if one of these inputs is a fee-paying wallet, you're tying the fee wallet keys to the vault keys (which are held more securely), possibly making vaulted funds unspendable if the less-secure fee wallet is compromised.
13:04 -!- jeremyrubin [~jr@4.53.92.114] has joined ##ctv-bip-review
13:05 < jeremyrubin> Thanks kanzure for the ping
13:05 < jeremyrubin> I'm traveling this week so pings appreciated if I need to follow up somewhere; don't have a cloud IRC setup :)
13:06 < jeremyrubin> 2 inputs does indeed mean that the hash commits to 2 inputs being included
13:06 < kanzure> harding: wtf? why would that work? it should be: alice gets paid *this* 1 BTC.
13:06 < jeremyrubin> This makes TXIDs unstable (sometimes!) so is not generall recomended unless you have a specific application in mind
13:06 < kanzure> harding: the transaction has a number of obligations to satisfy. if it has two "alice gets paid 1 BTC" obligations then there should be two satisfactions not one.
13:07 < jeremyrubin> harding: is correct
13:07 < jeremyrubin> but that this is impossible via key reuse with OP_CTV
13:07 < jeremyrubin> OP_CTV's hash function commits to the input index
13:07 < jeremyrubin> so these two outputs, with identical scripts, cannot be co-spent
13:08 < bsm1175321> Can you explain the rationale for committing to two inputs?
13:08 < jeremyrubin> Yes
13:09 < kanzure> aj: jeremyrubin: i think we need better terminology when referring to inputs, outputs, scriptpubkeys from input-associated utxos but not the new utxos, etc..
13:09 < jeremyrubin> You can do different things with it; e.g. if you want to add fees dynamically you can use a fee paying wallet to construct an output to sign onto the CTV txn adding appropraite fees
13:09 < bsm1175321> You can also do that with SIGHASH_SINGLE|ANYONECANPAY
13:09 < jeremyrubin> kanzure: we need new terminology across the board
13:09 < bsm1175321> and then the fees and vaulted funds can't be mixed
13:09 < jeremyrubin> Hang on
13:10 < jeremyrubin> bsm1175321: can you let me answer your question?
13:10 < bsm1175321> go ahead :-D
13:10 < jeremyrubin> You guys haven't published a design on your vaults yet either so it's hard to compare what the tradeoffs are
13:10 < bsm1175321> I realized we haven't sent you our draft...
13:10 < kanzure> to complicate it further, i also have a separate vault proposal
13:10 < jeremyrubin> I generally think for fees people will prefer to use CPFP constructions
13:11 < jeremyrubin> because they are txid stable and therefore composable with L2 solutions
13:11 < jeremyrubin> This is true no matter what design you use; if you wanna work with L2 you gotta have stable txids
13:12 < bsm1175321> I see. So you're forced to commit to your fee paying wallet, even though it's less secure.
13:12 < jeremyrubin> noo
13:12 < bsm1175321> Because you want a stable txid
13:12 < jeremyrubin> Where'd you get that from
13:12 < jeremyrubin> You aren't forced to commit to your fee paying wallet at all
13:12 < bsm1175321> Isn't the second input for fees?
13:13 < jeremyrubin> Yeah
13:13 < jeremyrubin> But it's not comitted?
13:13 < bsm1175321> But if I reference a txid of my fee wallet in the CTV script, I've locked that output and can't use it for anything else.
13:15 < jeremyrubin> CTV doesn't commit to txids :)
13:15 < bsm1175321> Among other problems, I don't know the fee rate when I redeem the vaulted output, and that second input may be insufficient.
13:15 < jeremyrubin> Read the BIP
13:15 < bsm1175321> We are :-P
13:15 < jeremyrubin> the hash function doesn't commit to any TXIDs you can pick whichever one you want
13:15 < kanzure> but it does commit to a scriptSig
13:16 < jeremyrubin> Which is 0 for all segwit spends
13:16 < jeremyrubin> so as long as your gas is segwit, no problem
13:16 < bsm1175321> But then I'm not committing to the vaulted funds at all?
13:16 < jeremyrubin> You are
13:16 < bsm1175321> how?
13:16 < jeremyrubin> in the CTV
13:16 < jeremyrubin> in the outputs
13:17 < bsm1175321> But if it doesn't commit to any input txids or scriptSigs (segwit), it hasn't committed to any funds, no?
13:17 < jeremyrubin> nope; not true
13:17 < kanzure> see this is why we need new terminology.
13:17 < jeremyrubin> When you spend to create the vault, you actually fund it
13:17 < bsm1175321> But I could satisfy it with different inputs.
13:18 < jeremyrubin> That's true always
13:18 < bsm1175321> Not if you commit to the inputs :-P
13:18 < jeremyrubin> Anyone can spend to any output that already exists and 'create it again'
13:18 < jeremyrubin> E.g. key reuse
13:18 < jeremyrubin> https://imgur.com/a/tL6Aq6J
13:18 < jeremyrubin> btw here's a picture of what CPFP gas outputs might look like
13:19 < kanzure> 12:24 < kanzure> in the congestion controlled batch transactions, who is paying the fees to publish the fan-out transaction later? which recipient pays that?
13:19 < kanzure> i see the same fan-out pattern in that diagram
13:19 < bsm1175321> anyone can spend to any <address> that already exists. This is why we created a vault "receiving wallet" -- vaulted funds only come from this wallet, which you also control. Other funds sent to those addresses are unspendable (but also, not yours)
13:19 < jeremyrubin> That's from a congestion controlled tree in fact, not a vault
13:20 < jeremyrubin> You can pay fees along the vault, you can pay CPFP from any of the leafs, you can add anyone can spend gas outputs along the path too
13:20 < jeremyrubin> Who pays depends on the contract with the sender
13:20 < kanzure> so someone ends up paying for the fan-out transaction to publish 100 UTXOs on chain, right?
13:21 < jeremyrubin> Well, usually it should happen just by CPFP
13:21 < kanzure> or is this like a MERKLEBRANCHVERIFY thing where there's an accumulator.. or new CTV output minus the original spend.. ?
13:21  * bsm1175321 hates CPFP... :-/
13:21 < jeremyrubin> You can emulate that if you can stomach a 2**n blowup
13:21 < jeremyrubin> ;)
13:22 < jeremyrubin> There's like 5 different ways to pay fees; it will depend heavily on use case
13:22 < jeremyrubin> If it's a single party protocol you'll probably be ok with gas ports and do a txn that claims them along the execution path to drive progress
13:22 < jeremyrubin> If it's a two party you will want maybe that + CPFP
13:23 < jeremyrubin> If you don't care about stability you can do 2-input CTV and create a gas output to co-spend with the ctv
13:23 < jeremyrubin> But to continue answering your q, you can also use a co-spend with under-funded CTVs to express crowdfundlogic
13:24 < jeremyrubin> E.g., 0.5 BTC to OP_IF 1 BTC to ALice CTV OP_ELSE <1 month> CSV Bob Signature OP_ENDIF
13:24 < jeremyrubin> then if someone fills in with another 1/2 BTC then Alice gets the money, otherwise it times out back to Bob
13:25 < bsm1175321> What does "gas ports and do a txn that claims them along the execution path" mean? What's a gas port? What's the "execution path"?
13:25 < jeremyrubin> Execution path are the set of txns in the transaction "program" which get confirmed on chain
13:25 < jeremyrubin> in the diagram I sent you can see 3 gas port outputs
13:26 < jeremyrubin> If you wanted to drive progress to create the outputs, you could spend 2 of the outputs in one txn to advance those transactions
13:29 < jeremyrubin> You can also do 2 txns too, but you can adjust the overall fee you're paying optimally in that case
13:29 < bsm1175321> Does the receiver's wallet have to be aware of the congestion control protocol to redeem the outputs?
13:29 < jeremyrubin> No
13:29 < jeremyrubin> Standard wallets should, today, be able to generate appropriat spends from unconfirmed txns
13:29 < bsm1175321> Can you explain then how the receiver redeems the funds?
13:30 < jeremyrubin> It depends on if the sender included sufficient fees at each interior node txn
13:30 < bsm1175321> Well with N potential receivers, my address certainly isn't committed in the outputs, no?
13:30 < jeremyrubin> Which would be the 'recommendation' for the time being if wallet support isn't built to support 0 fee txns
13:30 < jeremyrubin> Huh?
13:31 < bsm1175321> If I'm a receiver, where is my address in this structure?
13:31 < jeremyrubin> bsm1175321: I'm confused at what you're confused about
13:31 < bsm1175321> me too
13:31 < jeremyrubin> green nodes
13:31 < bsm1175321> What's a green node?
13:31 < jeremyrubin> did you look at the diagram I sent over
13:33 < bsm1175321> Yes. It makes me even more confused.
13:33 < bsm1175321> Oh green node as in green box on your diagram
13:34 < jeremyrubin> well it's a ovaly thing but yeah
13:34 < jeremyrubin> Can you zoom in?
13:34 < jeremyrubin> it's pretty high res
13:34 < bsm1175321> So none of the interior nodes are known by the receiver(?)
13:34 < bsm1175321> Yeah...need a bigger monitor
13:35 < jeremyrubin> Well you just broadcast them all, and assuming sufficient fee on the nodes themselves, the mempool picks them up and so do wallets
13:35 < bsm1175321> So...I thought the point was that the receiver could choose when to redeem. But it seems that's not correct? (?)
13:35 < jeremyrubin> The output based gas ports are there if you want to add fee via CPFP to get confirmed more quickly
13:36 < jeremyrubin> Well you're asking me two very incompatible questions
13:36 < jeremyrubin> If the receiver is unwilling to get wallet software which can download CTV based programs out-of-band of the mempool we're limited to a model where the txns are in the mempool only
13:37 < bsm1175321> Ok so that contradicts your previous statement. The receiver *does* have to have special wallet software.
13:37 < jeremyrubin> If they are able to receive a private broadcast (e.g., via email) they can just submit the txns to their wallet themselves and broadcast to the pool
13:37 < jeremyrubin> No they don't *have to*
13:38 < jeremyrubin> If you want 1st class support for CTV you will need a wallet which understands it
13:38 < bsm1175321> But if they don't have this special wallet software, the sender is better off just waiting for the low-fee situation and then send.
13:38 < jeremyrubin> But if you want it to just work with existing stuff, it also does
13:38 < jeremyrubin> You can just make it *work better* if you're aware of the new stuff
13:38 < bsm1175321> Sure. So to be clear, to take advantage of receiver-initiated receive, he has to have special software.
13:39 < bsm1175321> If he does not, when to send is sender-initiated.
13:39 < jeremyrubin> Well it depends -- the sender can just always broadcast to the mempool there's nothing wrong with that.
13:40 < bsm1175321> And in the receiver-initiated case, this results in larger on-chain load, due to the intermediate transactions, no?
13:40 < jeremyrubin> There are workarounds for that stuff
13:40 < bsm1175321> Yes and it's sender-initiated. The receiver can't "pull".
13:40 < bsm1175321> What workarounds?
13:40 < jeremyrubin> did you watch my scaling bitcoin talk?
13:40 < jeremyrubin> Yes, fundamentally a receiver not knowing the preimage to the ctv hash cannot initiate a xfer
13:41 < kanzure> https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bip-securethebag/
13:41 < bsm1175321> No (scaling bitcoin talk)
13:41 < jeremyrubin> :P
13:41 < jeremyrubin> Go watch that!
13:41 < jeremyrubin> I have to go :)
13:41 < bsm1175321> What prevents the sender from double-spending the vaulted funds, preventing the receiver from pulling?
13:42 < kanzure> the CTV output gets committed and confirmations in the blockchain
13:42 < bsm1175321> But CTV doesn't commit to the input txid.
13:43 < kanzure> the input to the transaction that creates the CTV output?
13:46 < kanzure> i think your concern is: the CTV script might allow for multiple exit-paths for each output (e.g. the script is: really-good-OP_CTV OR really-bad-OP_CTV) and then the creator publishes multiple conflicting transactions?
13:46 -!- jeremyrubin [~jr@4.53.92.114] has quit [Ping timeout: 258 seconds]
13:46 < bsm1175321> Create a transaction with a CTV commitment to a subsequent transaction: (S, fee) -> (R, change) where S,R are Sender, Receiver respectively.
13:47 < bsm1175321> Since amounts and txids are not committed, the sender can extract the entire value through the <change> output by creating this subsequent transaction.
13:48 < bsm1175321> If R holds a competing transaction that actually receives his value, he's in a double-spend situation against the sender.
13:49 < bsm1175321> kanzure: exactly.
13:49 < bsm1175321> CPFP doesn't help here since it's a double-spend and won't be relayed.
13:50 < bsm1175321> So the receiver can't CPFP it.
13:50 < kanzure> what's the attack though? most wallets consider funds received once they have a UTXO spendable by their key... and if the sender double spends, then obviously the wallet doesn't accept the unconfirmed transaction as payment...
13:51 < kanzure> for vaults, simply don't sign multiple competing possibilities and don't commit your funds into that vault if you don't like the scripts
13:51 < bsm1175321> The attack is that the receiver *doesn't* have a (mined) utxo. They have a CTV'd output for which they can create a transaction, but so can the sender.
13:51 < bsm1175321> But the scripts weren't committed.
13:52 < kanzure> the scripts are committed; see "outputs hash" in "The StandardTemplateHash commits to the serialized version, locktime, scriptSigs hash (if any non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and currently executing input index."
13:52 < bsm1175321> In a sender/receiver situation, the receiver doesn't participate, doesn't sign anything...
13:53 < bsm1175321> but scriptSigs are null in segwit, hence, not committed.
13:53 < kanzure> scriptsigs are not output hashes
13:54 < kanzure> output hash is scriptpubkey
13:54 < bsm1175321> In (S, fee) -> (R, change) the committed output hash is (R, change)
13:55 < bsm1175321> Ok so then it does commit to the receiver actually receiving, but screws you on fees and forces you to use CPFP on the change to get it confirmed.
13:55 < bsm1175321> And only the sender can do that, since he controls <change>
13:55 < bsm1175321> Well the receiver can CPFP his output R too...
13:56 < kanzure> but iirc most wallets don't try that by default when their transaction isn't confirming
13:56 < kanzure> (don't try CPFP)
13:56 < bsm1175321> Well, wallets being dumb is a thing.
13:57 < bsm1175321> This implies a lot of wallet work anyway, just to be able to "pull" your payment.
13:58  * bsm1175321 withdraws above attack.
14:16 < kanzure> i think the fanout diagram is deceptive; it should really be one box that creates the CTV output, and then another box (for another transaction) that is broadcasting the fan-out transaction creating many UTXOs. then each of those UTXOs is spendable by the receivers.
16:34 < bsm1175321> jeremyrubin: the notion of "pruning interior nodes" is confusing to me. Isn't this just the same as saying nodes should keep the UTXO set plus some reorg data, which is much smaller than the full state?
16:35 < bsm1175321> Because there's another idea here...if you have NOINPUT/ANYPREVOUT, it seems to me that interior nodes can truly be deleted Eltoo-style, and never appear in the blockchain.
16:35 < bsm1175321> Do you mean the former or the latter with "pruning interior nodes"? Or something else?
19:20 -!- jeremyrubin [~jr@cpe-184-152-11-117.nyc.res.rr.com] has joined ##ctv-bip-review
19:23 < jeremyrubin> bsm1175321: I think you're confused with how you use CTV.
19:23 < jeremyrubin> You pay to an output which has a root hash CTV
19:23 < jeremyrubin> And then once that is confirmed, the other transactions are confirmed
20:53 < aj> technically, the other transactions aren't confirmed, but there's no longer any possibility of them being double-spent?
21:22 -!- jeremyrubin [~jr@cpe-184-152-11-117.nyc.res.rr.com] has quit [Ping timeout: 260 seconds]
--- Log closed Tue Jan 14 00:00:06 2020