<unnamed>

Public Key

npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0

Profile Code

nprofile1qqsrwtp3vasnvz6w5g8j6l5p5kfk8dlytw8fgkjns8p3ygzfctztsjspzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqqfyhkv

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:05:13 CEST

- reply

📅 Original date posted:2022-02-20
📝 Original message:
Morning!
>
> For the latter case, CPFP would work and already exists.
> **Unless** you are doing something complicated and offchain-y and involves
> relative locktimes, of course.
>
>
The "usual" design I recommend for Vaults contains something that is like:
{<maturity> CSV <pk_hot> CHECKSIG, <pk_cold> CHECKSIG}
or
{<maturity> CSV <pk_hot> CHECKSIG, <H(tx to: <pk_cold> CHECKSIG)> CTV}
where after an output is created, it has to hit maturity before hot
spendable but can be kicked to recovery any time before (optional: use CTV
to actually transition on chain removing hot wallet, if cold key is hard to
access).
Not that this means if you're waiting for one of these outputs to be
created on chain, you cannot spend from the hot key since it needs to
confirm on chain first. Spending from the cold key for CPFP'ing the hot is
an 'invalid move' (emergency key for non emergency sitch)
Thus in order to CPFP, you would need a separate output just for CPFPing
that is not subject to these restrictions, or some sort of RBF-able addable
input/output. Or, Sponsors.
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220220/92d8f0e2/attachment.html>

2023-06-09 15:05:09 CEST

- reply

📅 Original date posted:2022-02-18
📝 Original message:
> As I said, it's a new kind of pinning attack, distinct from other types
of pinning attack.
I think pinning is "formally defined" as sequences of transactions which
prevent or make it less likely for you to make any progress (in terms of
units of computation proceeding).
Something that only increases possibility to make progress cannot be
pinning.
If you want to call it something else, with a negative connotation, maybe
call it "necromancing" (bringing back txns that would otherwise be
feerate/fee irrational).
I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.
Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.
In particular, for the use case you mentioned "Eg a third party could mess
up OpenTimestamps calendars at relatively low cost by delaying the mining
of timestamp txs.", this is incorrect. A third party can only accelerate
the mining on the timestamp transactions, but they *can* accelerate the
mining of any such timestamp transaction. If you have a single output chain
that you're RBF'ing per block, then at most they can cause you to shift the
calendar commits forward one block. But again, they cannot pin you. If you
want to shift it back one block earlier, just offer a higher fee for the
later RBF'd calendar. Thus the interference is limited by how much you wish
to pay to guarantee your commitment is in this block as opposed to the next.
By the way, you can already do out-of-band transaction fees to a very
similar effect, google "BTC transaction accelerator". If the attack were at
all valuable to perform, it could happen today.
Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
third party for OTS, you should be relatively happy because it cost you
less fees overall, since the undoing of your later RBF surely returned some
satoshis to your wallet.
Best,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220218/83410688/attachment.html>

2023-06-09 15:05:08 CEST

- reply

📅 Original date posted:2022-02-10
📝 Original message:
That's not really pinning; painning usually refers to pinning something to
the bottom of the mempool whereas these mechanisms make it easier to
guarantee that progress can be made on confirming the transactions you're
interested in.
Often times in these protocols "the call is coming inside the house". It's
not a third party adding fees we are scared of, it's a direct party to the
protocol!
Sponsors or fee accounts would enable you to ensure the protocol you're
working on makes forward progress. For things like Eltoo the internal
ratchet makes this work well.
Protocols which depend on in mempool replacements before confirmation
already must be happy (should they be secure) with any prior state being
mined. If a third party pays the fee you might even be happier since the
execution wasn't on your dime.
Cheers,
Jeremy
On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> > Happy new years devs,
> >
> > I figured I would share some thoughts for conceptual review that have
> been
> > bouncing around my head as an opportunity to clean up the fee paying
> > semantics in bitcoin "for good". The design space is very wide on the
> > approach I'll share, so below is just a sketch of how it could work which
> > I'm sure could be improved greatly.
> >
> > Transaction fees are an integral part of bitcoin.
> >
> > However, due to quirks of Bitcoin's transaction design, fees are a part
> of
> > the transactions that they occur in.
> >
> > While this works in a "Bitcoin 1.0" world, where all transactions are
> > simple on-chain transfers, real world use of Bitcoin requires support for
> > things like Fee Bumping stuck transactions, DoS resistant Payment
> Channels,
> > and other long lived Smart Contracts that can't predict future fee rates.
> > Having the fees paid in band makes writing these contracts much more
> > difficult as you can't merely express the logic you want for the
> > transaction, but also the fees.
> >
> > Previously, I proposed a special type of transaction called a "Sponsor"
> > which has some special consensus + mempool rules to allow arbitrarily
> > appending fees to a transaction to bump it up in the mempool.
> >
> > As an alternative, we could establish an account system in Bitcoin as an
> > "extension block".
>
> <snip>
>
> > This type of design works really well for channels because the addition
> of
> > fees to e.g. a channel state does not require any sort of pre-planning
> > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> > design is naturally immune to pinning issues since you could offer to
> pay a
> > fee for any TXID and the number of fee adding offers does not need to be
> > restricted in the same way the descendant transactions would need to be.
>
> So it's important to recognize that fee accounts introduce their own kind
> of
> transaction pinning attacks: third parties would be able to attach
> arbitrary
> fees to any transaction without permission. This isn't necessarily a good
> thing: I don't want third parties to be able to grief my transaction
> engines by
> getting obsolete transactions confirmed in liu of the replacments I
> actually
> want confirmed. Eg a third party could mess up OpenTimestamps calendars at
> relatively low cost by delaying the mining of timestamp txs.
>
> Of course, there's an obvious way to fix this: allow transactions to
> designate
> a pubkey allowed to add further transaction fees if required. Which Bitcoin
> already has in two forms: Replace-by-Fee and Child Pays for Parent.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220210/bfed4525/attachment.html>

2023-06-08 01:15:12 CEST

- reply

📅 Original date posted:2022-10-17
📝 Original message:Building on the most work chain is perhaps not rational in many normal
circumstances that can come up today under the stated reference strategy:
1) Take highest paying transactions that fit
2) Mine on tips
E.g., suppose:
Block N: Fees = 10, reward = 1
Mempool: Fees = 2
Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging leads
to reward of up to 10 + 1 + c, (c < 2, where c is the extra transactions
that fit). Assume instead your reward is 8, leaving 3+c on the table.
If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for them,
which is the new one you made as a non-tip miner since you "shared" some
fee.
You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require larger
incentive).
However, as many have pointed out, perhaps not following the simple "honest
tip mining" strategy is bad for bitcoin, so maybe we should expect it not
to happen often? Or other strategies to emerge around selecting
transactions so that the next M blocks have a similar fee profile, as
opposed to picking greedily for the next block.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Sun, Oct 16, 2022 at 3:03 PM <email at yancy.lol> wrote:
> The proof-of-work also solves the problem of determining
> representation in majority decision
> making. If the majority were based on one-IP-address-one-vote, it
> could be subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially
> one-CPU-one-vote. The majority
> decision is represented by the longest chain, which has the greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes, the
> honest chain will grow the
> fastest and outpace any competing chains. To modify a past block, an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and then
> catch up with and surpass the
> work of the honest nodes. We will show later that the probability of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
>
>
> It's interesting that Nash Equilibrium isn't mentioned here. Since each
> miner has the option to either contribute to the longest chain or not, even
> if the miners know what strategy the other miners will use, they still
> wouldn't change their decision to contribute to the majority.
>
>
> For example, if I run a shop that takes rain checks, but I sell an
> item to a higher bidder who didn't have a hold on the item, that is
> not honest, but it may be selfish profit maximizing.
>
>
> It would be honest if the store policy said ahead of time they are allowed
> to sell rain checks for more in such an occurrence. Although this is a
> good example of the difference between honest and rational. I think this
> means it's not a Nash Equilibrium if we needed to rely on the store owner
> to be honest.
>
>
> Satoshi said an honest majority is required for the chain to be
> extended. Honest is not really defined though. Honesty, in my
> definition, is that you follow a pre specified rule, rational or not.
>
>
> My take is that "rational" is probably a better word than honest. In
> terms of a Nash Equilibrium, each participant is simply trying to maximize
> their outcome and honesty doesn't matter (only that participants are
> rational).
>
>
> It seems a lot of the RBF controversy is that Protocol developers have
> aspired to make the honest behavior also be the rational behavior.
> This is maybe a good idea because, in theory, if the honest behavior
> is rational then we can make a weaker assumption of selfishness
> maximizing a parameter.
>
>
> I'm curious, can RBF can be described by a Nash Equilibrium? If yes, then
> it also shouldn't matter if participants are honest?
>
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms of
> properties of Bitcoin, as well as pathways to weakening the
> assumptions without compromising the behaviors users expect the
> network to have. An "extended white paper" if you will.
>
>
> White paper 1.1 :D
>
>
> A last reflection is that Bitcoin is specified with an honest majority
> assumption, but also has a rational dishonest minority assumption over
> both endogenous (rewards) and exogenous (electricity) costs. Satoshi
> did not suggest, at least as I read it, that Bitcoin works with an
> rational majority assumption. (If anyone thinks these three are
> similar properties you can make some trivial counterexamples)
>
>
> My take is the opposite unless I'm missing something. Participants are
> always incentivized to choose the rational solution (Not to waste
> electricity on a minority chain).
>
> Cheers,
> -Yancy
>
> On 2022-10-16 19:35, Jeremy Rubin via bitcoin-dev wrote:
>
> The Bitcoin white paper says:
>
> The proof-of-work also solves the problem of determining
> representation in majority decision
> making. If the majority were based on one-IP-address-one-vote, it
> could be subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially
> one-CPU-one-vote. The majority
> decision is represented by the longest chain, which has the greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes, the
> honest chain will grow the
> fastest and outpace any competing chains. To modify a past block, an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and then
> catch up with and surpass the
> work of the honest nodes. We will show later that the probability of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
>
> This, Satoshi (who doesn't really matter anyways I guess?) claimed
> that for Bitcoin to function properly you need a majority honest
> nodes.
>
> There are multiple behaviors one can describe as honest, and
> economically rational or optimizing is not necessarily rational.
>
> For example, if I run a shop that takes rain checks, but I sell an
> item to a higher bidder who didn't have a hold on the item, that is
> not honest, but it may be selfish profit maximizing.
>
> Satoshi said an honest majority is required for the chain to be
> extended. Honest is not really defined though. Honesty, in my
> definition, is that you follow a pre specified rule, rational or not.
>
> It seems a lot of the RBF controversy is that Protocol developers have
> aspired to make the honest behavior also be the rational behavior.
> This is maybe a good idea because, in theory, if the honest behavior
> is rational then we can make a weaker assumption of selfishness
> maximizing a parameter.
>
> However, Satoshi did not particularly bound what aspects of honesty
> are important for the network, because there isn't a spec defining
> exactly what is honest or not. And also as soon as people are honest,
> you can rely on that assumption for good effect.
>
> And sometimes, defining an honest behavior can be creating a higher
> utility system because most people are "law abiding citizens" who
> might not be short term rational. For example, one might expect that
> miners would be interested in making sure lightning closes are
> "accurate" because increasing the utility of lightning is good for
> Bitcoin, even if it is irrational.
>
> It seems that the NoRBF crowd want to rely on an honest majority
> assumption where the honest behavior is not doing replacement if not
> requested. This is really not much different than trying to close
> lightning channels "the right way".
>
> However, where it may be different, is that even in the presence of
> honest majority, the safety of 0conf isn't assured given the potential
> of race conditions in the mempool. Therefore it's not clear to me that
> 0conf working well is something you can drive from the Honest Majority
> Assumption (where honest includes first seen).
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms of
> properties of Bitcoin, as well as pathways to weakening the
> assumptions without compromising the behaviors users expect the
> network to have. An "extended white paper" if you will.
>
> It's somewhat clear to me that we shouldn't weaken assumptions that
> only seem local to one subsystem of Bitcoin if they end up
> destabilizing another system. In particular, things that decrease
> "transaction utility" for end users decrease the demand for
> transactions which hurts the fee market's longer term viability, even
> if we feel good about making an honest policy assumption into a self
> interested policy assumption.
>
> A last reflection is that Bitcoin is specified with an honest majority
> assumption, but also has a rational dishonest minority assumption over
> both endogenous (rewards) and exogenous (electricity) costs. Satoshi
> did not suggest, at least as I read it, that Bitcoin works with an
> rational majority assumption. (If anyone thinks these three are
> similar properties you can make some trivial counterexamples)
>
> Cheers,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/16a24252/attachment-0001.html>

2023-06-08 01:14:38 CEST

- reply

📅 Original date posted:2022-10-19
📝 Original message:If they do this to you, and the delta is substantial, can't you sweep all
such abusers with a cpfp transaction replacing their package and giving you
the original txn?
On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as
> default policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even bigger danger called the
> american call option, which risks endangering the entirety of BIP21 "Scan
> this QR code with your wallet to buy this product" model that I believe
> we've all come to appreciate. Specifically, in a scenario with high
> volatility and many transactions in the mempools (which is where RBF would
> come in handy), a user can make a low-fee transaction and then wait for
> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
> up, user can cancel his transaction and make a new - cheaper one. The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end. But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF, which may lead to us at some point refusing those payments (even with
> confirmation) or cumbersome UX to work around it, such as crediting the
> bitcoin to a custodial account.
>
> To compare zeroconf risk with FX risk: I think we've had one incident in 8
> years of operation where a user successfully fooled our server to accept a
> payment that in the end didn't confirm. To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled. This is simply due to the fact
> that the network currently won't propagage the replacement transaction to
> the miner, which is what's being discussed here. American call option risk
> would however be available to 100% of all users, needs nothing beyond the
> wallet app, and has no cost to the user - only upside.
>
> Bitrefill currently processes 1500-2000 onchain payments every day. For
> us, a world where bitcoin becomes de facto RBF by default, means that we
> would likely turn off the BIP21 model for onchain payments, instruct
> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
> account that we have.
> This option is however not available for your typical
> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
> from other merchants or payment providers how they see this new behavior
> and how they would counteract it.
>
> Currently Lightning is somewhere around 15% of our total bitcoin payments.
> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce. For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions. Currently far too many bitcoin users
> simply don't have access to Lightning, and of those that do and hold their
> own keys Muun is the biggest wallet per our data, not least due to their
> ease-of-use which is under threat per the OP. It's hard to assess how many
> users would switch to Lightning in such a scenario, the communication
> around it would be hard. My intuition says that the majority of the current
> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
> probably shift to an alt. The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. As an
> anecdote, we did experiment with defaulting to bech32 addresses some years
> back. The result was that simply users of the wallets that weren't able to
> pay to bech32 didn't complete the purchase, no support ticket or anything,
> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
> implemented a wallet selector to allow modern wallets to pay to bech32
> while other wallets can pay to P2SH. This type of thing is clunky, and
> requires a certain level of scale to be able to do, we certainly wouldn't
> have had the manpower for that when we were starting out. This why I'm
> cautious about introducing more such clunkiness vectors as they are
> centralizing factors.
>
> I'm well aware of the reason for this policy being suggested and the
> potential pinning attack vector for LN and other smart contracts, but I
> think these two risks/costs need to be weighed against eachother first and
> thoroughly discussed because the costs are non-trivial on both sides.
>
> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.
> In the end a risk-based approach to decide on which payments are
> non-trivial to reverse is the easiest, taking account user experience and
> such. Remember that in the fiat world card payments have up to 5%
> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
> 1 in a million" accepted transactions successfully reversed. These days we
> have very few support issues related to bitcoin payments. The few that do
> come in are due to accidental RBF users venting frustration about waiting
> for their tx to confirm.
> "In theory, theory and practice are the same. In practice, they are not"
>
> All the best,
> Sergej Kotliar
> CEO Bitrefill.com
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/bb48f09b/attachment.html>

2023-06-08 01:07:26 CEST

- reply

📅 Original date posted:2022-04-21
📝 Original message:Probably merits a more thorough response, but, I wanted to respond on the
framework above:
1a) can you make transactions using the new feature with bitcoin-cli,
eg createrawtransaction etc? (*YES)*
since ~Feb 2020, this has existed:
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-feb1-workshop
CTV hasn't changed so this code should work un-rebased. The transaction
outputs may need to be manually submitted to the network, but the covenant
is enforced. This covers congestion control and vaults.
1b) can you make transactions using the new feature with some other
library? *(YES)*
Sapio, Test Framework, also https://min.sc/nextc/ produced independently by
Shesek
1c) can you make transactions using the new feature with most common
libraries? *(YES, kinda)*
Yes, https://crates.io/crates/sapio-miniscript and
https://crates.io/crates/sapio-bitcoin have been maintained for about 1
year, and are now taproot compatible.
Sapio's use of these libraries has even helped find bugs in the release
process of Taproot for rust-bitcoin.
kinda: It's not _most_ common libraries, it's _a_ common library. it's also
not upstreamed, because the patches would not be accepted were it to be.
2) has anyone done a usable prototype of the major use cases of the new
feature?* (YES)*
In addition to https://github.com/jamesob/simple-ctv-vault, there is also
https://github.com/kanzure/python-vaults, although it has an interesting
bug.
There's also a myriad of uses shown in
https://github.com/sapio-lang/sapio/tree/master/sapio-contrib/src/contracts
and in https://github.com/sapio-lang/sapio/tree/master/plugin-example.
While these aren't quite "usable" as an end-to-end application, e.g.,
something you'd want to put real money on, they are a part of a *massive*
infrastructure investment in general purpose smart contract tooling for
covenant design with CTV. That CTV can be targeted with a compiler to
generate a wide variety of composable use cases *is* one of the use cases
for CTV, since it enables people to design many different types of thing
relatively easily. That is a feature of CTV! It's not just for one use case.
The suite of Sapio apps are less "production ready" than they could be for
a few reasons:
1) I've been working hard at pushing the limits of what is possible & the
theory of it v.s. making it production ready
2) I prioritized supporting Taproot v.s. legacy script, and much of the
taproot tooling isn't production ready
3) Sapio is really ambitious undertaking, and it will take time to make it
production
That said, https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-dev-mtg-6/
tutorial was completed by people who weren't me, and at the
pleb.fi/miami2022 one of the projects was able to use sapio congestion
control transactions as well, so it does "work". As it matures, we'll get a
number of implemented use cases people have been excited about like DLCs,
which are implemented here
https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs.
You can see the test case shows how to construct one.
Why did I not focus on production grade? Well, production grade can always
happen later, and I don't think it takes as much imagination. But the main
critique I'd heard of CTV was that no one could see it being used for
anything but one or two use cases. So I built Sapio, in part, to show how
CTV could be used for an incredibly wide and diverse set of applications,
as opposed to the polish on them.
If I knew the bar to surpass was to be polish, I probably could have taken
a less ambitious approach with Sapio and shown like 1-2 applications
working end-to-end. But because the main feedback I got was that CTV wasn't
powerful enough, I opted to build a very general framework for covenants
and demonstrate how CTV fits that.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Thu, Apr 21, 2022 at 12:05 AM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-dev
> wrote:
> > All merits (or lack thereof depending on your view) of CTV aside, I find
> this topic around decision making both interesting and important. While I
> think I sympathize with the high level concern about making sure there are
> use cases, interest, and sufficient testing of a particular proposal before
> soft forking it into consensus code, it does feel like the attempt to
> attribute hard numbers in this way is somewhat arbitrary.
>
> Sure. I included the numbers for falsifiability mostly -- so people
> could easily check if my analysis was way off the mark.
>
> > For example, I think it could be reasonable to paint the list of
> examples you provided where CTV has been used on signet in a positive
> light. 317 CTV spends “out in the wild” before there’s a known activation
> date is quite a lot
>
> Not really? Once you can make one transaction, it's trivial to make
> hundreds. It's more interesting to see if there's multiple wallets or
> similar that support it; or if one wallet has a particularly compelling
> use case.
>
> > (more than taproot had afaik).
>
> Yes; as I've said a few times now, I think we should have had more
> real life demos before locking taproot's activation in. I think that
> would have helped avoid bugs like Neutrino's [0] and made it easier for
> hardware wallets etc to have support for taproot as soon as it was active,
> without having to rush around adding library support at the last minute.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019589.html
>
> Lightning's "two independent implementations" rule might be worth aspiring
> too, eg.
>
> > If we don’t think it is enough, then what number of unique spends and
> use cases should we expect to see of a new proposal before it’s been
> sufficiently tested?
>
> I don't really think that's the metric. I'd go for something more like:
>
> 1a) can you make transactions using the new feature with bitcoin-cli,
> eg createrawtransaction etc?
> 1b) can you make transactions using the new feature with some other
> library?
> 1c) can you make transactions using the new feature with most common
> libraries?
>
> 2) has anyone done a usable prototype of the major use cases of the new
> feature?
>
> I think the answers for CTV are:
>
> 1a) no
> 1b) yes, core's python test suite, sapio
> 1c) no
> 2) no
>
> Though presumably jamesob's simple ctv vault is close to being an answer
> for (2)?
>
> For taproot, we had,
>
> 1a) yes, with difficulty [1]
> 1b) yes, core's python test suite; kalle's btcdeb sometimes worked too
> 1c) no
> 2) optech's python notebook [2] from it's taproot workshops had demos for
> musig and degrading multisig via multiple merkle paths, though I
> think they were out of date with the taproot spec for a while
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019543.html
> [2] https://github.com/bitcoinops/taproot-workshop/
>
> To some extent those things are really proxies for:
>
> 3) how well do people actually understand the feature?
>
> 4) are we sure the tradeoffs being made in this implementation of the
> feature, vs other implementations or other features actually make
> sense?
>
> 5) how useful is the feature?
>
> I think we were pretty confident in the answers for those questions
> for taproot. At least personally, I'm still not super confident in
> the answers for CTV. In particular:
>
> - is there really any benefit to doing it as a NOP vs a taproot-only
> opcode like TXHASH? Theoretically, sure, that saves some bytes; but as
> was pointed out on #bitcoin-wizards the other day, you can't express
> those outputs as an address, which makes them not very interoperable,
> and if they're not interoperable between, say, an exchange and its
> users trying to do a withdraw, how useful is that really ever going
> to be?
>
> - the scriptSig commitments seems very kludgy; combining multiple
> inputs likewise seems kludgy
>
> The continual push to rush activation of it certainly doesn't increase my
> confidence either. Personally, I suspect it's counterproductive; better
> to spend the time answering questions and improving the proposal, rather
> than spending time going around in circles about activating something
> people aren't (essentially) unanimously confident about.
>
> > In absence of the above, the risk of a constantly moving bar
>
> I'd argue the bar *should* be constantly moving, in the sense that we
> should keep raising it.
>
> > To use your meme, miners know precisely what they’re mining for and what
> a metric of success looks like which makes the risk/costs of attempting the
> PoW worth it
>
> The difference between mining and R&D is variance: if you're competing for
> 50k blocks a year, you can get your actual returns to closely match your
> expected return, especially if you pool with others so your probability
> of success isn't miniscule -- for consensus dev, you can reasonably only
> work on a couple of projects a year, so your median return is likely $0,
> rather than a close match to your average/expected return.
>
> > We also have new ideas that only started coming up after Taproot
> activation (TLUV and Taro for example), so there’s also the unknown of what
> we could have once it becomes clear that it’s worth devoting mental energy
> and financial resources towards research.
>
> TLUV was an offshoot of SCRIPTREPLACE which was public (though not
> really published) since 2019.
>
> > One last wrinkle with regards to using countable metrics to determine a
> feature’s “worth” is that not all features are the same. Many of the use
> cases that people are excited to use CTV for ([5], [6]) are very long term
> in nature and targeted for long term store of value in contrast to medium
> of exchange.
>
> I mean, if those use cases are so exciting, it really doesn't seem much
> to ask to see them demoed live on the CTV signet that already exists?
>
> > You can build a CTV vault in signet, but you’ll only really see a lot of
> people using it when it’s to store real value on a time scale measured in
> decades not minutes or days
>
> On the other hand, if the value is really "very long term" and there's no
> rush to implement these features and demo them ASAP, then it doesn't seem
> like there should be a rush to adapt consensus to these use cases either.
> Why not wait until someone does have time to finish sketching out the
> use case so they can demo them in public?
>
> > To put another way and leave CTV out of it completely, what should an
> outside, unbiased observer that doesn’t spend much time on Twitter expect
> to be able to see to evaluate the readiness or acceptability of ANYPREVOUT,
> TLUV,
>
> For ANYPREVOUT, I would like to see a toy implementation of eltoo using
> it, that can handle fees and layered transactions (or has a good argument
> why layered transactions aren't necessary). It's going to take a while
> even to update LN to taproot and PTLCs though, so eltoo doesn't seem like
> it's on the immediate horizon. Besides eltoo, I don't think ANYPREVOUT
> is an optimal design for covenants, so if that was the motivation and
> not eltoo, maybe some other approach would be better.
>
> TLUV's design parameters don't really seem optimal (the mess with x-only
> pubkeys, alternatives like OP_EVICT), so I think it's still on the
> whiteboard.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/4dc687ea/attachment-0001.html>

2023-06-08 01:07:16 CEST

- reply

📅 Original date posted:2022-04-19
📝 Original message:Devs,
In advance of the CTV meeting today, I wanted to share what my next step is
in advocating for CTV, as well as 7 theses for why I believe it to be the
right course of action to take at this time.
Please see the post at
https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
As always, open to hear any and all feedback,
Jeremy
archived at:
https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220419/70812907/attachment.html>

2023-06-08 01:07:15 CEST

- reply

📅 Original date posted:2022-04-12
📝 Original message:note of clarification:
this is from the perspective of a developer trying to build infrastructure
for covenants. from the perspective of bitcoin consensus, a covenant
enforcing primitve would be something like OP_TLUV and less so it's use in
conjunction with other opcodes, e.g. OP_AMOUNT.
One must also analyze all the covenants that one *could* author using a
primitive, in some sense, to demonstrate that our understanding is
sufficient. As a trivial example, you could use
OP_DELETE_BITCOIN_ENTIRELY_IF_KNOWS_PREIMAGE_TO_X_OR_TLUV and just because
you could use it safely for TLUV would not mean we should add that opcode
if there's some way of using it negatively.
Cheers,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Tue, Apr 12, 2022 at 10:33 AM Jeremy Rubin <jeremy.l.rubin at gmail.com>
wrote:
> Sharing below a framework for thinking about covenants. It is most useful
> for modeling local covenants, that is, covenants where only one coin must
> be examined, and not multi-coin covenants whereby you could have issues
> with protocol forking requiring a more powerful stateful prover. It's the
> model I use in Sapio.
>
> I define a covenant primitive as follows:
>
> 1) A set of sets of transaction intents (a *family)*, potentially
> recursive or co-recursive (e.g., the types of state transitions that can be
> generated). These intents can also be represented by a language that
> generates the transactions, rather than the literal transactions
> themselves. We do the family rather than just sets at this level because to
> instantiate a covenant we must pick a member of the family to use.
> 2) A verifier generator function that generates a function that accepts an
> intent that is any element of one member of the family of intents and a
> proof for it and rejects others.
> 3) A prover generator function that generates a function that takes an
> intent that is any element of one member of the family and some extra data
> and returns either a new prover function, a finished proof, or a rejection
> (if not a valid intent).
> 4) A set of proofs that the Prover, Verifier, and a set of intents are
> "impedance matched", that is, all statements the prover can prove and all
> statements the verifier can verify are one-to-one and onto (or something
> similar), and that this also is one-to-one and onto with one element of the
> intents (a set of transactions) and no other.
> 5) A set of assumptions under which the covenant is verified (e.g., a
> multi-sig covenant with at least 1-n honesty, a multisig covenant with any
> 3-n honesty required, Sha256 collision resistance, DLog Hardness, a SGX
> module being correct).
>
> To instantiate a covenant, the user would pick a particular element of the
> set of sets of transaction intents. For example, in TLUV payment pool, it
> would be the set of all balance adjusting transactions and redemptions. *Note,
> we can 'cleave' covenants into separate bits -- e.g. one TLUV + some extra
> CTV paths can be 'composed', but the composition is not guaranteed to be
> well formed.*
>
> Once the user has a particular intent, they then must generate a verifier
> which can receive any member of the set of intents and accept it, and
> receive any transaction outside the intents and reject it.
>
> With the verifier in hand (or at the same time), the user must then
> generate a prover function that can make a proof for any intent that the
> verifier will accept. This could be modeled as a continuation system (e.g.,
> multisig requires multiple calls into the prover), or it could be
> considered to be wrapped as an all-at-once function. The prover could be
> done via a multi-sig in which case the assumptions are stronger, but it
> still should be well formed such that the signers can clearly and
> unambiguously sign all intents and reject all non intents, otherwise the
> covenant is not well formed.
>
> The proofs of validity of the first three parts and the assumptions for
> them should be clear, but do not require generation for use. However,
> covenants which do not easily permit proofs are less useful.
>
> We now can analyze three covenants under this, plain CTV, 2-3 online
> multisig, 3-3 presigned + deleted.
>
> CTV:
> 1) Intent sets: the set of specific next transactions, with unbound inputs
> into it that can be mutated (but once the parent is known, can be filled in
> for all children).
> 2) Verifier: The transaction has the hash of the intent
> 3) Prover: The transaction itself and no other work
> 4) Proofs of impedance: trivial.
> 5) Assumptions: sha256
> 6) Composition: Any two CTVs can be OR'd together as separate leafs
>
> 2-3 Multisig:
> 1) Intent: All possible sets of transactions, one set selected per instance
> 2) Verifier: At least 2 signed the transition
> 3) Prover: Receive some 'state' in the form of business logic to enforce,
> only sign if that is satisfied. Produce a signature.
> 4) Impedance: The business logic must cover the instance's Intent set and
> must not be able to reach any other non-intent
> 5) Assumptions: at least 2 parties are 'honest' for both liveness and for
> correctness, and the usual suspects (sha256, schnorr, etc)
> 6) Composition: Any two groups can be OR'd together, if the groups have
> different signers, then the assumptions expand
>
> 3-3 Presigned:
> Same as CTV except:
> 5) Assumptions: at least one party deletes their key after signing
>
>
> You can also think through other covenants like TLUV in this model.
>
> One useful question is the 'cardinality' of an intent set. The useful
> notion of this is both in magnitude but also contains. Obviously, many of
> these are infinite sets, but if one set 'contains' another then it is
> definitionally more powerful. Also, if a set of transitions is 'bigger'
> (work to do on what that means?) than another it is potentially more
> powerful.
>
> Another question is around composition of different covenants inside of an
> intent -- e.g., a TLUV that has a branch with a CTV or vice versa. We
> consider this outside the model, analysis should be limited to "with only
> these covenants what could you build". Obviously, one recursive primitive
> makes all primitives recursive.
>
> Another question is 'unrollability'. Can the intents, and the intents of
> the outputs of the intents, be unrolled into a representation for a
> specific instantiation? Or is that set of possible transactions infinite?
> How infinite? CTV is, e.g., unrollable.
>
>
> Last note on statefulness: The above has baked into it a notion of
> 'statelessness', but it's very possible and probably required that provers
> maintain some external state in order to prove (whether multisig or not).
> E.g., a multisig managing an account model covenant may need to track who
> is owed what. This data can sometimes be put e.g. in an op return, an extra
> tapleaf branch, or just considered exogenous to the covenant. But the idea
> that a prover isn't just deciding on what to do based on purely local
> information to an output descriptor is important.
>
>
> For Sapio in particular, this framework is useful because if you can
> answer the above questions on intents, and prover/verifier generators, then
> you would be able to generate tooling that could integrate your covenant
> into Sapio and have things work nicely. If you can't answer these questions
> (in code?) then your covenant might not be 'well formed'. The efficiency of
> a prover or verifier is out of scope of this framework, which focuses on
> the engineering + design, but can also be analyzed.
>
>
> Grateful for any and all feedback on this model and if there are examples
> that cannot be described within it,
>
> Jeremy
>
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220412/01e41240/attachment-0001.html>

2023-06-08 01:06:05 CEST

- reply

📅 Original date posted:2022-03-15
📝 Original message:Boker tov bitcoin devs,
A mechanism of soft-forking against activation exists. What more do you
> want?
>
Agreed -- that should be enough.
> Are we supposed to write the code on behalf of this hypothetical group of
> users who may or may not exist for them just so that they can have a node
> that remains stalled on Speedy Trial lockin?
>
That simply isn't reasonable, but if you think it is, I invite you to
> create such a fork.
>
Disagree.
It is a reasonable ask.
I've done it in about 40 lines of python:
https://github.com/jeremyrubin/forkd
Merry Christmas Jorge, please vet the code carefully before running.
Peace,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220315/07cb6ea8/attachment.html>

2023-06-08 01:05:51 CEST

- reply

📅 Original date posted:2022-03-08
📝 Original message:Logs here: https://gnusha.org/ctv-bip-review/2022-03-08.log
Notes:
1) Sapio Updates
Sapio has Experimental Taproot Support now.
See logs for how to help.
Rust-bitcoin can also use your help reviewing, e.g.
https://github.com/rust-bitcoin/rust-miniscript/pull/305
Adding MuSig support for the oracle servers would be really cool, if
someone wants a challenge.
2) Transaction Sponsors
What sponsors are vs. RBF/CPFP.
Why there's not a BIP # assigned (despite it being written up as a BIP+impl
in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html,
should only get a number if it seems like people agree).
3) James' Vaults Post
James' vaults are similar to prior art on recursive CTV vaults (Kanzure's /
Jeremy's), where the number of steps = 1.
Actually ends up being a very good design for many custody purposes, might
be a good "80% of the benefit 20% of the work" type of thing.
People maybe want different things out of vaults... how customizable must
it be?
4) Mailing list be poppin'
Zmn shared a prepared remark which spurred a nice conversation.
General sentiment that we should be careful adding crazy amounts of power,
with great power comes great responsibility...
Maybe we shouldn't care though -- don't send to scripts you don't like?
Math is scary -- you can do all sorts of bizarre stuff with more power
(e.g., what if you made an EVM inside a bitcoin output).
Things like OP_EVICT should be bounded by design.
Problem X: Infrastructure issue for all more flexible covenants:
1) generate a transition function you would like
2) compile it into a script covenant
3) request the transition/txn you want to have happen
4) produce a satisifaction of the script covenant for that transaction
5) prove the transition function *is* what you wanted/secure
Quantifying how hard X is for a given proposal is a good idea.
You can prototype covenants with federations in Sapio pretty easily... more
people should try this!
5) General discuss
People suck at naming things... give things more unique names for protocols!
Jeremy will name something the Hot Tub Coin Machine
Some discussion on forking, if theres any kind of consensus forming, doing
things like
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html
How much does a shot-on-goal cost / unforced errors of not making an
activating client available precluding being able to activate
luke-jr: never ST; ST is a reason enough to oppose CTV
jamesob: <javascript> OP_DOTHETHING
best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220308/1b56b098/attachment.html>

2023-06-08 01:05:13 CEST

- reply

📅 Original date posted:2022-03-05
📝 Original message:It seems like a decent concept for exploration.
AJ, I'd be interested to know what you've been able to build with Chia Lisp
and what your experience has been... e.g. what does the Lightning Network
look like on Chia?
One question that I have had is that it seems like to me that neither
simplicity nor chia lisp would be particularly suited to a ZK prover...
Were that the explicit goal, it would seem that we could pretty easily
adapt something like Cairo for Bitcoin transactions, and then we'd get a
big privacy benefit as well as enabling whatever programming paradigm you
find convenient (as it is compiled to a circuit verifier of some kind)...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/60845e5d/attachment.html>

2023-06-08 01:02:42 CEST

- reply

📅 Original date posted:2022-01-28
📝 Original message:Apologies for the double post*, but I just had a follow up idea
that's pretty interesting to me.
You can make the close portion of a DLC be an "optimistic" execution with a
choice of justice scheme. This enables closing a DLC somewhat securely
without exposing the oracles on-chain at all.
Assuming honest oracles, the only cost of this mechanism over previous is
that you have to do a script path spend (but it can be a top-level branch,
since it's the "most likely" one).
For every DLC branch like:
*<CET-hash-i> CHECKTEMPLATEVERIFY
<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*
add a 2 branches:
*<CET-hash-A> CHECKTEMPLATEVERIFY
<Alice> CHECKSIG
*
*<CET-hash-B> CHECKTEMPLATEVERIFY
<Bob> CHECKSIG*
This enables Alice or Bob to "lock in" a redemption of the contract
that becomes spendable by them after <period>. CET-hash-* should
include a nLockTime/nSequence such that it is at the same time as the
attestation points should be known.
Where CET-hash-T sends funds to a DLC that has the following conditions:
(cooperate):
*pk_internal=musig(Alice, Bob)*
or (unilateral timeout)
*<T> Checksig <2 weeks> CSV*
or (show oracles for this outcome)
*<CET-hash-i> CHECKTEMPLATEVERIFY*
*<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*
or (justice with no punishment), forall j !=i:
*<CET-hash-j> CHECKTEMPLATEVERIFY*
*<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*
or (justice with punishment), forall j!=i:
*<CET-hash-punish-j, send funds to not-T> CHECKTEMPLATEVERIFY*
*<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*
Justice with punishment seems to me to be the better option since T is
actively choosing this resolution (the CTV transition is signed), but
justice with no punishment might be better if you think the oracles
might screw you over and collude to steal.
One interesting question is if the justice transactions can be
"compressed" to be fewer for a given outcome. I.e., if Bob has claimed
that the outcome is 35, and there are 100 total outcomes, do we need
99 justice paths or is there a way to make fewer of them? Intuitively,
it would seem so, because if we have a 8-10 threshold for picking a
path, a 3-10 proof would be sufficient to prove Bob claimed to know
the 8-10 falsely. However, that then means 3-10 could collude, v.s.
the fraud proof requiring a full 8-10 counter. Things to think about!
Best,
Jeremy
* this might actually be a triple or quadruple post depending on how
you count, I adjusted which email was the subscriber on my mailing
list account and resultantly sent from the old address... sincere
apologies if you are seeing this message >1 times to those who were on
the CC.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Jan 28, 2022 at 9:21 AM Jeremy <jlrubin at mit.edu> wrote:
> Lloyd,
>
> This is an excellent write up, the idea and benefits are clear.
>
> Is it correct that in the case of a 3/5th threshold it is a total 10x *
> 30x = 300x improvement? Quite impressive.
>
> I have a few notes of possible added benefits / features of DLCs with CTV:
>
> 1) CTV also enables a "trustless timeout" branch, whereby you can have a
> failover claim that returns funds to both sides.
>
> There are a few ways to do this:
>
> A) The simplest is just an oracle-free <STH(timeout tx)> CTV whereby the
> timeout transaction has an absolute/relative timelock after the creation of
> the DLC in question.
>
> B) An alternative approach I like is to have the base DLC have a branch
> `<STH(begin timeout)> CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with `<STH(timeout
> tx)> CTV` which contains a relative timelock R for the desired amount of
> time to resolve. This has the advantage of always guaranteeing at least R
> amount of time since the Oracles have been claimed to be non-live to
> "return funds" to parties participating
>
>
> 2) CTV DLCs are non-interactive asynchronously third-party unilaterally
> creatable.
>
> What I mean by this is that it is possible for a single party to create a
> DLC on behalf of another user since there is no required per-instance
> pre-signing or randomly generated state. E.g., if Alice wants to create a
> DLC with Bob, and knows the contract details, oracles, and a key for Bob,
> she can create the contract and pay to it unilaterally as a payment to Bob.
>
> This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
> also be constructed and then sent (along with a specific amount) to a third
> party service (such as an exchange or Lightning node) to create DLCs
> without requiring the third party service to do anything other than make
> the payment as requested.
>
>
> 3) CTV DLCs can be composed in interesting ways
>
> Options over DLCs open up many exciting types of instrument where Alice
> can do things like:
> A) Create a Option expiring in 1 week where Bob can add funds to pay a
> premium and "Open" a DLC on an outcome closing in 1 year
> B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
> premium (on-chain DEX?).
>
> See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete
> stuff around this.
>
> There are also opportunities for perpetual-like contracts where you could
> combine into one logical DLC 12 DLCs closing 1 per month that can either be
> payed out all at once at the end of the year, or profit pulled out
> partially at any time earlier.
>
> 4) This satisfies (I think?) my request to make DLCs expressible as Sapio
> contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/
>
> 5) An additional performance improvement can be had for iterative DLCs in
> Lightning where you might trade over a fixed set of attestation points with
> variable payout curves (e.g., just modifying some set of the CTV points).
> Defer to you on performance, but this could help enable some more HFT-y
> experiences for DLCs in LN
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
>
> On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi dlc-dev and bitcoin-dev,
>>
>> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/7ec469d9/attachment.html>

2023-06-07 17:43:14 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:While we're all debating the block size, please review this proposal to
modestly increase the number of transactions per block.
https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63
Best,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/79674044/attachment.html>

2023-06-07 17:42:41 CEST

- reply

📅 Original date posted:2015-07-21
📝 Original message:I think it's not a horrible idea to just add a field into the transaction
metadata for N_SIG_OPS in the script_sig
It is much simpler in implementation if the concern is complexity (once a
transaction goes above N_SIG_OPS it could be considered invalid, number
computed must be equal). It wouldn't even need to be stored permanently as
it can be pruned easily and recomputed later (hashes would protect against
buggy complicated sig counting code).
Furthermore, it would differentiate a branch with different counts well.
On Wed, Jul 22, 2015 at 2:09 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Mitigate a potential CPU exhaustion denial-of-service attack by limiting
>> > the maximum size of a transaction included in a block.
>>
>> This seems like a fairly indirect approach. The resource being watched
>> for is not the size (otherwise two transactions for 200k would be
>> strictly worse than one 200k transactions) but the potential of N^2
>> costs related to repeated hashing in checksig; which this ignores.
>>
>
> Yes. The tradeoff is implementation complexity: it is trivial to check
> transaction size,
> not as trivial to count signature operations, because
> number-of-bytes-in-transaction
> doesn't require any context.
>
> But I would REALLY hate myself if in ten years a future version of me was
> struggling to
> get consensus to move away from some stupid 100,000 byte transaction size
> limit
> I imposed to mitigate a potential DoS attack.
>
> So I agree, a limit on sigops is the right way to go. And if that is being
> changed,
> might as well accurately count exactly how many sigops a transaction
> actually
> requires to be validated...
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/6ff84cc8/attachment-0001.html>