JackTheMimic on Nostr: I don't want to turn this into a huge chain of nuh-uh, yuh-huh sessions(like I see ...
I don't want to turn this into a huge chain of nuh-uh, yuh-huh sessions(like I see with the more tenacious of your commentors). So I will posit a few questions to which I don't intend to ask follow-ups.
The "Punishment System" is present all throughout Bitcoin. I see it more as a feature than a workaround. That said, wanting rapidity is the goal of lightning not the consequentially low fees. How does CTV incentivize honest collaborative behavior if you are trading coupons off chain non-interactively?
Secondly I'm guessing multiparty ownership of a single UTXO would be a function of if-else statements if Key [1] does action, then Key [2] is output upon resolve condition and so on. The question is what if distribution contitions are so verbose that A) it bloats the timechain with "arbitrary" data or B) that spend conditions specified SEEM like they will send to Key[2] but really the secondary and tertiary conditions could be so complex that it does?
I understand the benefits of a Lightning pool with implications of payroll. The issue I see arising is to make that UTXO worth the CTV Pool, you would have a very large honey pot that if you could satisfy conditions of, you'd get a large chunk of quiche. How, without a punishment system does one monitor millions of outputs for closure?
This is my absolute ignorance here (saved the best for last) How does one party close a channel and get final settlement in a CTV pool situation? How does one get their on-chain asset OUT of the coupon layer if all settlement conditions on the template haven't been fulfilled?
Thanks for your time and contributions of value to the Network of Freedom.
The "Punishment System" is present all throughout Bitcoin. I see it more as a feature than a workaround. That said, wanting rapidity is the goal of lightning not the consequentially low fees. How does CTV incentivize honest collaborative behavior if you are trading coupons off chain non-interactively?
Secondly I'm guessing multiparty ownership of a single UTXO would be a function of if-else statements if Key [1] does action, then Key [2] is output upon resolve condition and so on. The question is what if distribution contitions are so verbose that A) it bloats the timechain with "arbitrary" data or B) that spend conditions specified SEEM like they will send to Key[2] but really the secondary and tertiary conditions could be so complex that it does?
I understand the benefits of a Lightning pool with implications of payroll. The issue I see arising is to make that UTXO worth the CTV Pool, you would have a very large honey pot that if you could satisfy conditions of, you'd get a large chunk of quiche. How, without a punishment system does one monitor millions of outputs for closure?
This is my absolute ignorance here (saved the best for last) How does one party close a channel and get final settlement in a CTV pool situation? How does one get their on-chain asset OUT of the coupon layer if all settlement conditions on the template haven't been fulfilled?
Thanks for your time and contributions of value to the Network of Freedom.