Jeremy Rubin [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-03 to 2022-10-20
💬 Posted a total of 99 messages
📚 Participated in the following categories: bitcoin-dev, Pre-BIP, Lightning-dev, PROPOSAL, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0

Profile Code

nprofile1qqsrwtp3vasnvz6w5g8j6l5p5kfk8dlytw8fgkjns8p3ygzfctztsjss55pha

Author Public Key

npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0

Show more details

Last Notes

2023-06-09 13:05:50

- reply

📅 Original date posted:2022-04-17
📝 Original message:
the 'lots of people' stuff (get confused, can't figure out what i'm
quoting, actually are reading this conversation) is an appeal to an
authority that doesn't exist. If something is unclear to you, let me know.
If it's unclear to a supposed existential person or set of persons, they
can let me know.
concretely, I am confused by how OTS can both support RBF for updating to
larger commitments (the reason you're arguing with me) and not have an
epoch based re-comittings scheme and still be correct. My assumption now,
short of a coherent spec that's not just 'read the code', is that OTS
probably is not formally correct and has some holes in what is
committed to, or relies on clients re-requesting proofs if they fail to be
committed. in any case, you would be greatly aided by having an actual spec
for OTS since i'm not interested in the specifics of OTS software, but I'm
willing to look at the protocol. So if you do that, maybe we can talk more
about the issue you see with how sponsors works.
further, I think that if there is something that sponsors does that could
make a hypothetical OTS-like service work better, in a way that would be
opaque (read: soft-fork like wrt compatibility) to clients, then we should
just change what OTS is rather than committing ourselves to a worse design
in service of some unstated design goals. In particular, it seems that
OTS's servers can be linearized and because old clients aren't looking for
linearization, then the new linearization won't be a breaking change for
old clients, just calendar servers. And new clients can benefit from
linearization.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Fri, Apr 15, 2022 at 7:52 AM Peter Todd <pete at petertodd.org> wrote:
> On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > > nonsense marketing
> >
> > I'm sure the people who are confused about "blockchain schemes as \"world
> > computers\" and other nonsense
> > marketing" are avid and regular readers of the bitcoin devs mailing list
> so
> > I offer my sincerest apologies to all members of the intersection of
> those
> > sets who were confused by the description given.
>
> Of course, uninformed people _do_ read all kinds of technical materials.
> And
> more importantly, those technical materials get quoted by journalists,
> scammers, etc.
>
> > > useless work
> >
> > progress is not useless work, it *is* useful work in this context. you
> have
> > committed to some subset of data that you requested -- if it was
> 'useless',
> > why did you *ever* bother to commit it in the first place? However, it is
> > not 'maximally useful' in some sense. However, progress is progress --
> > suppose you only confirmed 50% of the commitments, is that not progress?
> If
> > you just happened to observe 50% of the commitments commit because of
> > proximity to the time a block was mined and tx propagation naturally
> would
> > you call it useless?
>
> Please don't trim quoted text to the point where all context is lost. Lots
> of
> people read this mailing list and doing that isn't helpful to them.
>
> > > Remember that OTS simply proves data in the past. Nothing more.
> > > OTS doesn't have a chain of transactions
> > Gotcha -- I've not been able to find an actual spec of Open Time Stamps
>
> The technical spec of OpenTimestamps is of course the normative validation
> source code, currently python-opentimestamps, similar to how the technical
> spec
> of Bitcoin is the consensus parts of the Bitcoin Core codebase. The
> explanatory
> docs are linked on https://opentimestamps.org under the "How It Works"
> section.
> It'd be good to take the linked post in that section and turn it into
> better
> explanatory materials with graphics (esp interactive/animated graphics).
>
> > anywhere, so I suppose I just assumed based on how I think it *should*
> > work. Having a chain of transactions would serve to linearize history of
> > OTS commitments which would let you prove, given reorgs, that knowledge
> of
> > commit A was before B a bit more robustly.
>
> I'll reply to this as a separate email as this discussion - while useful -
> is
> getting quite off topic for this thread.
>
> > > I'd rather do one transaction with all pending commitments at a
> > particular time
> > rather than waste money on mining two transactions for a given set of
> > commitments
> >
> > This sounds like a personal preference v.s. a technical requirement.
> >
> > You aren't doing any extra transactions in the model i showed, what
> you're
> > doing is selecting the window for the next based on the prior conf.
>
> ...the model you showed is wrong, as there is no reason to have a
> linearized
> transaction history. OpenTimestamps proofs don't even have the concept of
> transactions: the proof format proves that data existed prior to a merkle
> root
> of a particular Bitcoin block. Not a Bitcoin transaction.
>
> > See the diagram below, you would have to (if OTS is correct) support this
> > sort of 'attempt/confirm' head that tracks attempted commitments and
> > confirmed ones and 'rewinds' after a confirm to make the next commit
> > contain the prior attempts that didn't make it.
> >
> >
> [.........................................................................]
> > ------^ confirm head tx 0 at height 34
> > ------------------------^ attempt head after tx 0
> > -----------^ confirm head tx 1 at height 35
> > --------------------------^ attempt head after tx 1
> > ------------^ confirm head tx 2 at height 36
> > -------------------------------^
> > attempt head after tx 2
> > -------------------------------^
> > confirm head tx 3 at height 37
> >
> > you can compare this to a "spherical cow" model where RBF is always
> perfect
> > and guaranteed inclusion:
> >
> >
> >
> [.........................................................................]
> > ------^ confirm head tx 0 at height 34
> > -------------------------^ confirm head tx 1 at height 35
> > -----------^ confirm head at tx 1
> > height 36
> > -----------------^
> > confirm head tx 3 at height 37
> >
> > The same number of transactions gets used over the time period.
>
> None of the above has anything to do with how OpenTimestamps works.
>
> Anyway, getting back to the topic at hand, I remain of the opinion that in
> the
> unlikely event that fee accounts is ever implemented, it should be opt-in.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220417/be59c0a8/attachment.html>

2023-06-09 13:05:49

- reply

📅 Original date posted:2022-04-11
📝 Original message:
> nonsense marketing
I'm sure the people who are confused about "blockchain schemes as \"world
computers\" and other nonsense
marketing" are avid and regular readers of the bitcoin devs mailing list so
I offer my sincerest apologies to all members of the intersection of those
sets who were confused by the description given.
> useless work
progress is not useless work, it *is* useful work in this context. you have
committed to some subset of data that you requested -- if it was 'useless',
why did you *ever* bother to commit it in the first place? However, it is
not 'maximally useful' in some sense. However, progress is progress --
suppose you only confirmed 50% of the commitments, is that not progress? If
you just happened to observe 50% of the commitments commit because of
proximity to the time a block was mined and tx propagation naturally would
you call it useless?
> Remember that OTS simply proves data in the past. Nothing more.
> OTS doesn't have a chain of transactions
Gotcha -- I've not been able to find an actual spec of Open Time Stamps
anywhere, so I suppose I just assumed based on how I think it *should*
work. Having a chain of transactions would serve to linearize history of
OTS commitments which would let you prove, given reorgs, that knowledge of
commit A was before B a bit more robustly.
> I'd rather do one transaction with all pending commitments at a
particular time
rather than waste money on mining two transactions for a given set of
commitments
This sounds like a personal preference v.s. a technical requirement.
You aren't doing any extra transactions in the model i showed, what you're
doing is selecting the window for the next based on the prior conf.
See the diagram below, you would have to (if OTS is correct) support this
sort of 'attempt/confirm' head that tracks attempted commitments and
confirmed ones and 'rewinds' after a confirm to make the next commit
contain the prior attempts that didn't make it.
[.........................................................................]
------^ confirm head tx 0 at height 34
------------------------^ attempt head after tx 0
-----------^ confirm head tx 1 at height 35
--------------------------^ attempt head after tx 1
------------^ confirm head tx 2 at height 36
-------------------------------^
attempt head after tx 2
-------------------------------^
confirm head tx 3 at height 37
you can compare this to a "spherical cow" model where RBF is always perfect
and guaranteed inclusion:
[.........................................................................]
------^ confirm head tx 0 at height 34
-------------------------^ confirm head tx 1 at height 35
-----------^ confirm head at tx 1
height 36
-----------------^
confirm head tx 3 at height 37
The same number of transactions gets used over the time period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220411/2492791b/attachment.html>

2023-06-09 13:05:09

- 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 13:05:08

- 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-09 12:44:16

- reply

📅 Original date posted:2015-08-28
📝 Original message:
Negotiating & Committing Signatures
============================
In this proposal, I suggest the addition of new types of signature schemes
to Bitcoin, and running lightning over multi signature of the
variants to utilize the advantages of multiple signature schemes without
the drawbacks.
Secure Construction of Signature Variants
================================
Suppose you have a signature scheme A and a signature scheme B.
Assume we can categorize A as a "better to commit to" scheme (ie, it is
easier to put on the blockchain) and B as a "better to negotiate with"
scheme (ie, it is easier to renegotiate with). Assume these advantages and
disadvantages are somewhat disjoint, and we would like to leverage both.
Therefore, we can operate lightning where each parties key is a 1 of 2
merkelized multisig (or H(H(PK_A)+H(PK_B)) ).
Now, in this scheme, only either a signature with A or B would be needed
for the payment to be valid, and the space hit for the merkle proof is
marginal.
What this enables a user to do is to use signature scheme B for the main
set of negotiations, and when it is time to settle, request switching to A.
If the settlement is in the case where parties disagree and are not
cooperating, the version signed with scheme B would still allow for
settlement. However, assuming this case is infrequent, B should rarely be
needed.
Signature Schemes
=================
ECDSA is the only signature scheme available in Bitcoin currently. However,
there exist a multitude of signature schemes with many unique properties.
SecureRF (Derek Atkins, CTO is cc'd) has developed a novel signature
algorithm based on the Braid Group (it's a new paper -- not purely based on
the conjugacy problem) which promises to be significantly more efficient to
verify. (I do not have the know-how to audit their claims and cryptosystem,
so assuming it is correct my analysis follows...). The size of their
keys/signature is approximately an order of magnitude larger, but their
verfication time is approximately 200x faster. Thus, were one to use this
signature scheme as "B", it would have the property of being better to
negotiate with but worse to settle on as it would contribute to blockchain
bloat.
There may be other such schemes B that would be interesting to explore, but
I have limited knowledge here.
Motivation
========
So why put effort into making the negotiation phase easier?
By lowering the requirements to verify a payment, embedded systems could be
made less expensive that can verify a lightning network payment. This
capability would mean that it would be easier to have a large collection of
devices which can receive and verify micropayments easily, eg, anywhere you
might have a coin slot.
It's unclear if this would provide great value over having the devices
outsource verification, but is worth discussion as their may be other
benefits derived from a negotiation v.s. committing key.
Drawbacks
========
Such a scheme requires that new signature algorithms be added to Bitcoin;
this may be difficult to get implemented. However, if the benefits of
having distinct negotiating v.s. committing keys has a tangible effect on
the usability & scalability of layer 2 systems such as lightning it may be
a worthwhile pursuit.
Happy to hear your thoughts on the usefulness of such a scheme, and if it
has applications outside of lightning.
Cheers,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150828/d00b7587/attachment.html>

2023-06-09 12:43:55

- reply

📅 Original date posted:2015-08-10
📝 Original message:
No I think it's a valid place to talk about it, and it helps clarify the
functional goals.
I need to dive in a little bit deeper into the implementation to really see
what is going on, I didn't pick up on the sequence being only for direction
flipping. Where should I look to observe this?
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Aug 10, 2015 at 2:04 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I really think the number inversion to "preserve the old nSequence
> semantics" is not worth it. It's less usable and harder to understand.
> Renaming nSequence to nMaturity and "check sequence verify" to "verify
> input maturity" (or something of the sort) may seem just
> bike-shedding, but I believe could greatly simplify the documentation.
> Maybe not the right thread to repeat this...
>
> On Mon, Aug 10, 2015 at 5:58 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
> > I believe there may be a misconception in your understanding. Lightning
> as
> > implemented by Rusty uses the sequence number field of the transaction
> > format, but not as an increment-on-each-transaction sequence number in
> the
> > traditional sense. Rather, BIP 68
> > (https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)
> specifies a
> > new consensus rule by which the sequence number field can mandate a
> required
> > minimum age for each input, thereby achieving a relative lock-time.
> > Lightning uses these relative lock-times.
> >
> > A sequence number of MAX_INT is allowed to confirm on the block chain in
> the
> > same block or later as its parent. A sequence number one less than that
> > cannot confirm any earlier than one block AFTER its parent. A sequence
> > number two less than MAX_INT requires two blocks to elapse, etc.
> >
> > So let's say that you want a certain script pathway to only take effect
> 30
> > days after confirmation of the parent. You achieve this by checking in
> the
> > script that the sequence number of the spending transaction (the child)
> is
> > equal to MAX_INT - 4320 (= 144 * 30). In the case of a bidirectional
> payment
> > channel, this is a value that is ratcheted up (bringing the confirmation
> > delay down) each time the payment channel switches direction. So for
> > example, you might increment sequence number / decrement the time to
> > confirmation by 144 blocks (1 day) each time the payment channel switches
> > direction, regardless of the number of off-chain transactions that have
> > elapsed in-between.
> >
> > On Mon, Aug 10, 2015 at 8:03 AM, Jeremy Rubin <jr at mit.edu> wrote:
> >>
> >> Hi! A couple questions about the use of sequence numbers in lightning.
> >> Please forgive me if these are somewhat rudimentary.
> >>
> >> 1) Can someone better outline what the race conditions are? It seems
> >> certain things time out w.r.t. the bitcoin blockchain height, which
> seems
> >> negative with respect to censorship vulnerability. How is this
> addressed?
> >> Section 9.5 of the paper seems unsatisfactory.
> >>
> >> 2) Using sequence numbers to select the right transaction to include is
> >> good, but it would seem to leak information about how many LN
> transactions
> >> took place, which could then make it meterable by external parties.
> (eg, a
> >> miner could make the fee for settling proportional to it). Perhaps
> >> incrementing by a random amount would alleviate the ability to reliably
> >> meter. Maybe it is good that this can be metered?
> >>
> >> Cheers,
> >>
> >> Jeremy
> >> --
> >> @JeremyRubin
> >>
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/09f4bb9d/attachment-0001.html>

2023-06-09 12:43:55

- reply

📅 Original date posted:2015-08-10
📝 Original message:
Hi! A couple questions about the use of sequence numbers in lightning.
Please forgive me if these are somewhat rudimentary.
1) Can someone better outline what the race conditions are? It seems
certain things time out w.r.t. the bitcoin blockchain height, which seems
negative with respect to censorship vulnerability. How is this addressed?
Section 9.5 of the paper seems unsatisfactory.
2) Using sequence numbers to select the right transaction to include is
good, but it would seem to leak information about how many LN transactions
took place, which could then make it meterable by external parties. (eg, a
miner could make the fee for settling proportional to it). Perhaps
incrementing by a random amount would alleviate the ability to reliably
meter. Maybe it is good that this can be metered?
Cheers,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/eab58e4e/attachment.html>

2023-06-07 23:15:31

- reply

📅 Original date posted:2022-10-18
📝 Original message:Excellent proposal and I agree it does capture much of the spirit of
sponsors w.r.t. how they might be used for V3 protocols.
The only drawbacks I see is they don't work for lower tx version contracts,
so there's still something to be desired there, and that the requirement to
sweep the output must be incentive compatible for the miner, or else they
won't enforce it (pass the buck onto the future bitcoiners). The Ephemeral
UTXO concept can be a consensus rule (see
https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate UTXO")
we add later on in lieu of managing them by incentive, so maybe it's a
cleanup one can punt.
One question I have is if V3 is designed for lightning, and this is
designed for lightning, is there any sense in requiring these outputs for
v3? That might help with e.g. anonymity set, as well as potentially keep
the v3 surface smaller.
On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > does that effectively mark output B as unspendable once the child gets
> confirmed?
>
> Not at all. It's a normal spend like before, since the parent has been
> confirmed. It's completely unrestricted, not being bound to any
> V3/ephemeral anchor restrictions on size, version, etc.
>
> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Greg,
>>
>> Thank you very much for sharing your proposal!
>>
>> I think there's one thing about the second part of your proposal that I'm
>> missing. Specifically, assuming the scenario of a v3 transaction with three
>> outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction
>> spends A and OP_TRUE, does that effectively mark output B as unspendable
>> once the child gets confirmed? If so, isn't the implication therefore that
>> to safely spend a transaction with an ephemeral anchor, all outputs must be
>> spent? Thanks!
>>
>> Best,
>> Arik
>>
>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>
>> Hello Everyone,
>>
>> Following up on the "V3 Transaction" discussion here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>> , I would like to elaborate a bit further on some potential follow-on work
>> that would make pinning severely constrained in many setups].
>>
>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
>> some constraints[0]. This means that when a replacement is to be made and
>> propagated, it costs the expected amount of fees to do so. This is a great
>> start. What's left in this subset of pinning is *package limit* pinning. In
>> other words, a fee-paying transaction cannot enter the mempool due to the
>> existing mempool package it is being added to already being too large in
>> count or vsize.
>>
>> Zooming into the V3 simplified scenario for sake of discussion, though
>> this problem exists in general today:
>>
>> V3 transactions restrict the package limit of a V3 package to one parent
>> and one child. If the parent transaction includes two outputs which can be
>> immediately spent by separate parties, this allows one party to disallow a
>> spend from the other. In Gloria's proposal for ln-penalty, this is worked
>> around by reducing the number of anchors per commitment transaction to 1,
>> and each version of the commitment transaction has a unique party's key on
>> it. The honest participant can spend their version with their anchor and
>> package RBF the other commitment transaction safely.
>>
>> What if there's only one version of the commitment transaction, such as
>> in other protocols like duplex payment channels, eltoo? What about multi
>> party payments?
>>
>> In the package RBF proposal, if the parent transaction is identical to an
>> existing transaction in the mempool, the parent will be detected and
>> removed from the package proposal. You are then left with a single V3 child
>> transaction, which is then proposed for entry into the mempool. In the case
>> of another parent output already being spent, this is simply rejected,
>> regardless of feerate of the new child.
>>
>> I have two proposed solutions, of which I strongly prefer the latter:
>>
>> 1) Expand a carveout for "sibling eviction", where if the new child is
>> paying "enough" to bump spends from the same parent, it knocks its sibling
>> out of the mempool and takes the one child slot. This would solve it, but
>> is a new eviction paradigm that would need to be carefully worked through.
>>
>> 2) Ephemeral Anchors (my real policy-only proposal)
>>
>> Ephemeral Anchors is a term which means an output is watermarked as an
>> output that MUST be spent in a V3 package. We mark this anchor by being the
>> bare script `OP_TRUE` and of course make these outputs standard to relay
>> and spend with empty witness data.
>>
>> Also as a simplifying assumption, we require the parent transaction with
>> such an output to be 0-fee. This makes mempool reasoning simpler in case
>> the child-spend is somehow evicted, guaranteeing the parent will be as well.
>>
>> Implications:
>>
>> a) If the ephemeral anchor MUST be spent, we can allow *any* value, even
>> dust, even 0, without worrying about bloating the utxo set. We relax this
>> policy for maximum smart contract flexibility and specification simplicity..
>>
>> b) Since this anchor MUST be spent, any spending of other outputs in the
>> same parent transaction MUST directly double-spend prior spends of the
>> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
>> removed in these situations. This greatly magnifies composability of smart
>> contracts, as now we can do things like safely splice directly into new
>> channels, into statechains, your custodial wallet account, your cold
>> wallet, wherever, without requiring other wallets to support arbitrary
>> scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript
>> compatible to begin with...
>>
>> c) *Anyone* can bump the transaction, without any transaction key
>> material. This is essentially achieving Jeremy's Transaction Sponsors (
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html)
>> proposal without consensus changes. As long as someone gets a fully signed
>> parent, they can execute a bump with minimal wallet tooling. If a
>> transaction author doesn’t want a “sponsor”, do not include the output.
>>
>> d) Lightning Carve-out(
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html)
>> is superseded by this logic, as we are not restricted to two immediately
>> spendable output scenarios. In its place, robust multi-party fee bumping is
>> possible.
>>
>> e) This also benefits more traditional wallet scenarios, as change
>> outputs can no longer be pinned, and RBF/CPFP becomes robust. Payees in
>> simple spends cannot pin you. Batched payouts become a lot less painful.
>> This was one of the motivating use cases that created the term “pinning” in
>> the first place(
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html),
>> even if LN/L2 discussion has largely overtaken it due to HTLC theft risks.
>>
>> Open Question(s):
>>
>>
>> 1.
>>
>> If we allow non-zero value in ephemeral outputs, does this open up a
>> MEV we are worried about? Wallets should toss all the value directly to
>> fees, and add their own additional fees on top, otherwise miners have
>> incentive to make the smallest utxo burn transaction to claim those funds.
>> They just confirmed your parent transaction anyways, so do we care?
>> 2.
>>
>> SIGHASH_GROUP like constructs would allow uncommitted ephemeral
>> anchors to be added at spend time, depending on spending requirements.
>> SIGHASH_SINGLE already allows this.
>>
>>
>>
>>
>> Hopefully this gives people something to consider as we move forward in
>> thinking about mempool design within the constraints we have today.
>>
>>
>> Greg
>>
>> 0: With V3 transactions where you have "veto power" over all the inputs
>> in that transaction. Therefore something like ANYONECANPAY is still broken.
>> We need a more complex solution, which I’m punting for the sake of progress.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20221018/dc64cf8c/attachment-0001.html>

2023-06-07 23:09:01

- reply

📅 Original date posted:2022-05-01
📝 Original message:Developers,
There is much to say about the events of the last two weeks and the
response to them. I've been searching for the right words to share here,
but I think it best that short of a more thoughtful writeup I start with a
timely small step with the below comments.
First, let me be clear: I am not advancing a Speedy Trial(ST) activation of
Bitcoin Improvement Proposal-119 (BIP-119) CheckTemplateVerify (CTV) at
this time.
I'm skipping any discussion of the drama here. Most of you are interested
in developing Bitcoin, not drama. Let's try to keep this thread focused on
the actual work. I'll make some limited comments on the drama in a separate
thread, for those who care to hear from me on the subject directly.
I believe that the disinformation spread around my post ("7 Theses on a
next step for BIP-119"[0]) created three main negative outcomes within the
Bitcoin community:
1. Confusion about how Bitcoin's "technical consensus" works and how
changes are "approved".
2. Fear about the safety of CTV and covenants more broadly.
3. Misunderstandings around the properties of Speedy Trial, User Activated
Soft Fork (UASF), User Resisted Soft Fork (URSF), Soft Forks, Hard Forks,
and more.
While I cannot take responsibility for the spread of the disinformation, I
do apologize to anyone dealing with it for the role my actions have had in
leading to the current circumstance.
I personally take some solace in knowing that the only way out of this is
through it. The conversations happening now seem to have been more or less
inevitable, this has brought them to the surface, and as a technical
community we are able to address them head on if -- as individuals and
collectively -- we choose to. And, viewed through a certain lens, these
conversations represent incredibly important opportunities to participate
in defining the future of Bitcoin that would not be happening otherwise.
Ultimately, I am grateful to live in a time where I am able to play a small
role in such an important process. This is the work.
In the coming months, I expect the discourse to be messy, but I think the
work is clear cut that we should undertake at least the following:
1. Make great efforts to better document how Bitcoin's technical consensus
process works today, how it can be improved, and how changes may be
formally reviewed while still being unofficially advanced.
2. Work diligently to address the concerns many in the community have
around the negative potential of covenants and better explain the
trade-offs between levels of functionality.
3. Renew conversations about activation and release mechanisms and
re-examine our priors around why Speedy Trial may have been acceptable for
Taproot, was not acceptable for BIP-119, but may not be optimal long
term[1], and work towards processes that better captures the Bitcoin
network's diverse interests and requirements.
4. Work towards thoroughly systematizing knowledge around covenant
technologies so that in the coming months we may work towards delivering a
coherent pathway for the Bitcoin technical community to evaluate and put up
for offer to the broader community an upgrade or set of upgrades to improve
Bitcoin's capabilities for self sovereignty, privacy, scalability, and
decentralization.
This may not be the easiest path to take, but I believe that this work is
critical to the future of Bitcoin. I welcome all reading this to share your
thoughts with this list on how we might work towards consensus going
forward, including any criticisms of my observations and recommendations
above. While I would expect nothing less than passionate debate when it
comes to Bitcoin, remember that at the end of the day we all largely share
a mission to make the world a freer place, even if we disagree about how we
get there.
Yours truly,
Jeremy
[0]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
[1]: http://r6.ca/blog/20210615T191422Z.html I quite enjoyed Roconnor's
detailed post on Speedy Trial
--
@JeremyRubin <https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/9009e65d/attachment-0001.html>

2023-06-07 23:08:33

- reply

📅 Original date posted:2022-04-27
📝 Original message:Generally speaking, I'm not too fond of these mechanisms, for reasons
others have expounded upon, but I will point out the following:
Taproot means that top-level keys can be used in a ring signature scheme to
collect coin votes from, e.g., all individual coins above a certain value
at a certain time without revealing the particulars of who signed.
This capability helps with some of the chainalysis concerns.
However, note that many thoughtful individuals do not currently have any
taproot outputs on mainchain AFAIK because wallets are not yet 'upgraded',
so it's more of a future possibility.
One thing that might be nice is if there were a way to sign with a NUMS
point for ring signature purposes, but not for transactions. Otherwise if
NUMS points are common these ring signatures protocols might not be too
useful for collecting signals (even if they remain useful for covering a
set including the NUMS pointed tr outs).
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Tue, Apr 26, 2022 at 1:12 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Alongside the debate with CTV right now there's a second debate that was
> not fully hashed out in the activation of Taproot. There is a lot of
> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
> etc. A significant reason for the breakdown in civility around this debate
> is that because we don't have a means of measuring user support for
> proposed sof-fork changes, it invariably devolves into people claiming that
> their circles support/reject a proposal, AND that their circles are more
> broadly representative of the set of Bitcoin users as a whole.
>
> It seems everyone in this forum has at one point or another said "I would
> support activation of ____ if there was consensus on it, but there isn't".
> This statement, in order to be true, requires that there exist a set of
> conditions that would convince you that there is consensus. People have
> tried to dodge this question by saying "it's obvious", but the reality is
> that it fundamentally isn't. My bubble has a different "obvious" answer
> than any of yours.
>
> Secondly, due to the trauma of the block size wars, no one wants to utter
> a statement that could imply that miners have any influence over what
> rulesets get activated or don't. As such "miner signaling" is consistently
> devalued as a signal for market demand. I don't think this is reasonable
> since following the events of '17 miners are aware that they have the
> strong incentive that they understand market demand. Nevertheless, as it
> stands right now the only signal we have to work with is miner signaling,
> which I think is rightly frustrating to a lot of people.
>
> So how can we measure User Support for a proposed rule change?
>
> I've had this idea floating around in the back of my head for a while, and
> I'd like to solicit some feedback here. Currently, all forms of activation
> that are under consideration involve miner signaling in one form or
> another. What if we could make it such that users could more directly
> pressure miners to act on their behalf? After all, if miners are but the
> humble servants of user demands, this should be in alignment with how
> people want Bitcoin to behave.
>
> Currently, the only means users have of influencing miner decisions are A.
> rejection of blocks that don't follow rules and B. paying fees for
> transaction inclusion. I suggest we combine these in such a way that
> transactions themselves can signal for upgrade. I believe (though am not
> certain) that there are "free" bits in the version field of a transaction
> that are presently ignored. If we could devise a mapping between some of
> those free bits, and the signaling bits in the block header, it would be
> possible to have rules as follows:
>
> - A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
> - A transaction that is NOT signaling MAY be included in a block
> regardless of that block's signaling vector
> - (Optional) A transaction signaling in the negative MUST NOT be included
> in a block that signals in the affirmative
>
> Under this set of conditions, a user has the means of sybil-resistant
> influence over miner decisions. If a miner cannot collect the fees for a
> transaction without signaling, the user's fee becomes active economic
> pressure for the miner to signal (or not, if we include some variant of the
> negative clause). In this environment, miners could have a better view into
> what users do want, as would the Bitcoin network at large.
>
> Some may take issue with the idea that people can pay for the outcome they
> want and may try to compare a method like this to Proof of Stake, but there
> are only 3 sybil resistant mechanisms I am aware of, and any "real" view
> into what social consensus looks like MUST be sybil resistant:
>
> - Hashpower
> - Proof of personhood (KYC)
> - Capital burn/risk
>
> Letting hashpower decide this is the thing that is currently contentious,
> KYC is dead on arrival both on technical and social grounds, which really
> just leaves some means of getting capital into the process of consensus
> measurement. This mechanism I'm proposing is measurable completely
> en-protocol and doesn't require trust in institutions that fork futures
> would. Additionally it could be an auxiliary feature of the soft fork
> deployment scheme chosen making it something you could neatly package all
> together with the deployment itself.
>
> There are many potential tweaks to the design I propose above:
> 1. Do we include a notion of negative signaling (allowing for the
> possibility of rejection)
> 2. Do we make it such that miner signaling must be congruent with >X% of
> transactions, where congruence is that the signal must match any
> non-neutral signal of transaction.
>
> Some anticipated objections:
>
> 1. signaling isn't voting, no deployment should be made without consensus
> first.
> - yeah well we can't currently measure consensus right now, so that's not
> a super helpful thing to say and is breeding ground for abuse in the form
> of certain people making the unsubstantiated claim that consensus does or
> does not exist for a particular initiative
>
> 2. This is just a proposal for "pay to play", we should not let the
> wealthy make consensus decisions.
> - I agree that wealth should not be able to strong-arm decision making.
> But the status quo seems even worse where we let publicly influential
> people decide consensus in such a way where not only do they not "lose
> ammunition" in the process of campaigning, but actually accrue it, creating
> really bad long-term balances of power.
>
> 3. Enforcing this proposal requires its own soft fork.
> - Yes. It does...and there's a certain cosmic irony to that, but before we
> consider how to make this happen, I'd like to even discuss whether or not
> it's a good idea.
>
> 4. This gives CoinJoin pool operators and L2 protocol implementations
> power over deciding consensus.
> - I see this as an improvement over the status quo
>
> 5. This encourages "spam"
> - If you pay the fees, it's not spam.
>
> The biggest question I'd like to pose to the forum is:
> - Does a scheme like this afford us a better view into consensus than we
> have today?
> - Can it be gamed to give us a *worse* view into consensus? How?
> - Does it measure the right thing? If not, what do you think is the right
> thing to measure? (assuming we could)
> - Should I write a BIP spec'ing this out in detail?
>
> Cheers,
> Keagan
> _______________________________________________
> 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/20220427/15ebad05/attachment-0001.html>

2023-06-07 23:08:12

- reply

📅 Original date posted:2022-04-26
📝 Original message:I'm a bit confused here. The "personal blog" in question was sent to this
list with an archive link and you saw an replied to it.
The proposal to make an alternative path hadn't gotten buy in sufficient
from those iterating, and given the propensity of people to blow things out
of proportion in this list, I wanted to be sure a follow up plan carried
some buy before wider dissemination.
On Tue, Apr 26, 2022, 6:53 AM Michael Folkson <michaelfolkson at protonmail.com>
wrote:
> Jeremy
>
> > The reason there was not a mailing list post is because that's not a
> committed plan, it was offered up for discussion to a public working group
> for feedback as a potential plan.
>
> In the interests of posterity from your personal blog on April 17th [1]:
>
> "Within a week from today, you’ll find software builds for a CTV Bitcoin
> Client for all platforms linked here:
>
> - Mac OSX TODO:
> - Windows TODO:
> - Linux TODO:
>
> These will be built using GUIX, which are reproducible for verification."
>
> Doesn't sound to me that this was being "offered up for discussion". A
> week from April 17th would have been Sunday April 24th (2 days ago).
> Readers of this mailing list would have had no idea of these plans.
>
> > You've inaccurately informed the list on something no one has
> communicated committed intent for.
>
> I'll let readers assess from the above who is accurately informing the
> mailing list and who is using personal blog posts and messaging apps to
> give a completely different impression to one set of people versus readers
> of this mailing list.
>
> I like to give people the benefit of the doubt and assume incompetence
> rather than malice but when it comes to potential chain splits it doesn't
> really matter which it is. It has the same effect and poses the same
> network risk. If and when you try something like this again I hope this is
> remembered.
>
> The Binance hack rollback suggestion, the NACKing then coin flip
> suggestion on Taproot activation and now this. It seems like this trillion
> dollar industry is a joke to you. I know we aren't supposed to get personal
> on this mailing list but honestly if you are going to continue with these
> stunts I'd rather you do them on a different blockchain.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Tuesday, April 26th, 2022 at 6:48 AM, Jeremy Rubin <
> jeremy.l.rubin at gmail.com> wrote:
>
> The reason there was not a mailing list post is because that's not a
> committed plan, it was offered up for discussion to a public working group
> for feedback as a potential plan. You've inaccurately informed the list on
> something no one has communicated committed intent for. This was an
> alternative discussed in the telegram messaging app but did not seem to
> strike the correct balance so was not furthered.
>
> I was hoping to be able to share something back to this list sooner rather
> than later, but I have not been able to get, among those interested to
> discuss in that venue, coherence on a best next step. I communicated
> inasmuch on the bird app
> https://twitter.com/JeremyRubin/status/1518347793903017984
> https://twitter.com/JeremyRubin/status/1518477022439247872, but do not
> have a clear next step and am pouring over all the fantastic feedback I
> received so far.
>
> Further, you're representing the state of affairs as if there's a great
> need to scramble to generate software for this, whereas there already are
> scripts to support a URSF that work with the source code I pointed to from
> my blog. This approach is a decent one, even though it requires two things,
> because it is simple. I think it's important that people keep this in mind
> because that is not a joke, the intention was that the correct set of check
> and balance tools were made available. I'd be eager to learn what,
> specifically, you think the advantages are of a separate binary release
> rather than a binary + script that can handle both cases? I'm asking
> sincerely because I would make the modifications to the release I prepared
> to support that as well, if they do not entail substantial technical risk.
> Personally, were I aligned with your preferences, I'd be testing the forkd
> script and making sure it is easy to use as the simplest and most effective
> way to achieve your ends.
>
> regards,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
> On Mon, Apr 25, 2022 at 3:44 PM Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The latest I'm hearing (this mailing list appears to be being bypassed in
>> favor of personal blogs and messaging apps) is that Speedy Trial miner
>> signaling for the contentious CTV soft fork is no longer going to start on
>> May 5th (as previously communicated [1]) and may instead now start around
>> August 1st 2022.
>>
>> Hence for now the drama seems to have been averted. I am deeply skeptical
>> that in the next 3 months this soft fork activation attempt will obtain
>> community consensus and will no longer be contentious (although I guess
>> theoretically it is possible). As a result I suspect we'll be in the exact
>> same situation with a URSF effort required 2-3 months down the line.
>>
>> If we are I'll try to keep the mailing list informed. It is important
>> there is transparency and ample time to research and prepare before making
>> decisions on what software to run. Obviously I have no control over what
>> others choose to do. Please don't be rushed into running things you don't
>> understand the implications of and please only signal for a soft fork if
>> you are convinced it has community consensus (what should precede signaling
>> as it did for Taproot) and you are ready to activate a soft fork.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> As I said in my post:
>>
>> "If you care about Bitcoin's consensus rules I'd request you pay
>> attention so you can make an informed view on what to run and what to
>> support."
>>
>> Ideally everyone would come to an informed view independently.
>> Unfortunately many people don't have the time to follow Bitcoin drama 24/7
>> and hence struggle to separate noise from signal. In this case simple
>> heuristics are better than nothing. One heuristic is to listen to those in
>> the past who showed good judgment and didn't seek to misinform. Of course
>> it is an imperfect heuristic. Ideally the community would be given
>> sufficient time to come to an informed view independently on what software
>> to run and not be rushed into making decisions. But it appears they are not
>> being afforded that luxury.
>>
>> > I fear you risk losing respect in the community
>>
>> I appreciate your concern.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <
>> billy.tetrud at gmail.com> wrote:
>>
>> > assuming people pay attention and listen to the individuals who were
>> trusted during that period
>>
>> Bitcoin is not run by a group of authorities of olde. By asking people to
>> trust "those.. around in 2015-2017" you're asking people to blindly trust
>> authorities. This, in my strong opinion, goes against the bitcoin ethos,
>> and is an incredibly harmful way to push for your agenda. I'd very much
>> recommend you reassess the way you're going about what you're trying to do.
>> I fear you risk losing respect in the community by implying without any
>> evidence that certain people are "taking advantage" of some situation and
>> attempting "to confuse".
>>
>> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> If the next few weeks go how I fear they will it could get messy. If you
>>> care about Bitcoin's consensus rules I'd request you pay attention so you
>>> can make an informed view on what to run and what to support. For those of
>>> you who were around in 2015-2017 you'll know what to expect. The right
>>> outcome endured in 2017 and I'm sure the right outcome will endure here
>>> assuming people pay attention and listen to the individuals who were
>>> trusted during that period. There are always a large number of motivated
>>> parties who are incentivized to break nodes off from Bitcoin and may seek
>>> to take advantage of a contentious soft fork activation attempt.
>>>
>>> Remember that if all the information is presented to users in a clear
>>> way well ahead of time then they can make their own mind up. I fear that
>>> things will be made as convoluted as possible in a way intended to confuse
>>> and information will be withheld until the last minute. When in doubt it is
>>> generally better to rely on the status quo and tried and trusted. In this
>>> case that would be Bitcoin Core. Alternative releases such as those seeking
>>> to attempt to activate CTV or indeed those seeking to resist the activation
>>> of CTV really should only be considered if you are informed on exactly what
>>> you are running.
>>>
>>> If you are interested in the effort to resist the contentious soft fork
>>> activation attempt of CTV please join ##ursf on Libera IRC.
>>>
>>> Have a good weekend. Hopefully those behind this contentious soft fork
>>> activation attempt will see sense and we can go back to more productive
>>> things than resisting contentious soft forks.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at protonmail.com
>>> Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> 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/20220426/74387575/attachment-0001.html>

2023-06-07 23:08:02

- reply

📅 Original date posted:2022-04-26
📝 Original message:I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:
- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful
generically, because I may want to reuse the internal key in conjunction
with a script path in some circumstances.
- Add an additional sequence field that is specific to a signature with no
other consensus meaning, so APO can be used with absolute timelocks. For
example, this makes it impossible for more than one ratchet to be
aggregated within a single transaction under any circumstance if their
sequences differ (not sure this is a good example, but an example
nonetheless).
- Replace tagged keys for APO with either a Checksig2 or a separate feature
flag that enables or disables APO behavior so that we can have programmatic
control over if APO is allowed for a given key (e..g., OP_IF <N> CSV DROP
CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a
certain time, perhaps for a pre-approved backup transaction).
Overall, this would make eltoo ratchets look something like this:
<sig> <seq> OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN
where checksig2 leaves seq on the stack which can be used to enforce the
ratchet.
and covenants like:
<sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY
On Fri, Apr 22, 2022 at 4:23 AM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> 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/20220426/8de4425a/attachment-0001.html>

2023-06-07 23:07:35

- reply

📅 Original date posted:2022-04-21
📝 Original message:> You'd be confiscating your own funds by making an absurd spending
condition.
> By this argument, ALL softforks would have to be ruled out.
The argument is that transactions which can be relayed and in the mempool
and then confirmed should not ever be restricted.
This is so that old node's mempools don't produce invalid blocks after an
upgrade.
This is what a good chunk of policy is for, and we (being core) do bounce
these txns to make clear what might be upgraded.
Changing the detail you mentioned represents a tweak that could make old
nodes mine invalid blocks. That's all I'm ruling out.
> > In preparing it I just used what was available in Core now, surely the
> last
> > year you could have gotten the appropriate patches done?
>
> They were done, reviewed, and deployed in time for Taproot. You personally
>
> played a part in sabotaging efforts to get it merged into Core, and
> violating
> the community's trust in it by instead merging your BIP9 ST without
> consensus. Don't play dumb. You have nobody to blame but yourself.
>
Even if I accept full responsibility for BIP9 ST without consensus, you
still had the last year to convince the rest of the maintainers to review
and merge your activation code, which you did not do.
Don't confuse consensus-seeking with preference. My preference was to leave
versionbits entirely.
Nor am I blame seeking. I'm simply asking why, if this is _the_ most
important thing for Bitcoin (as I've heard some BIP8 LOT=true people
remark), did you not spend the last year improving your advocacy. And I'm
suggesting that you redouble those efforts by, e.g., opening a new PR for
Core with logic you find acceptable and continuing to drive the debate
forward. None of these things happen without advocacy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/a737dcb5/attachment.html>

2023-06-07 23:07:29

- reply

📅 Original date posted:2022-04-21
📝 Original message:Hi Russell,
Thank you for your feedback here.
> However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
> that bare-CTV hasn't even appeared on the CTV signet). Unlike the general
> smart-contracting case, bare-CTV does not have any branches. All it can do
> is commit to a subsequent transaction's outputs. At first glance this
> appears to be a waste because, for less bandwidth, that transaction could
> just realize those outputs immediately, so why would anyone want to delay
> the inevitable?
>
I can probably make some show up sometime soon. Note that James' vault uses
one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
think the second use of it (since it's not segwit wrapped) wouldn't be
broadcastable since it's nonstandard.
>
> One reason might be that you want to commit to the output early during a
> high-fee time, and then complete the transaction later during a low-fee
> time. While there are fee-rate situations where this could result in lower
> fees than committing to the outputs all at once, it would be even cheaper
> still to just wait to do the payout at the low-fee time. I'm struggling to
> understand the advantages of the advanced commitment, along with all the
> overhead that entails. Doesn't it just cause more blockspace to be used
> overall?
>
One case where you actually use less space is if you have a few different
sets of customers at N different fee priority level. Then, you might need
to have N independent batches, or risk overpaying against the customer's
priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
I'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine
my batch into a root and N batch outputs. This eliminates the need for
inputs, signatures, change outputs, etc per batch, and can be slightly
smaller. Since the marginal benefit on that is still pretty small, having
bare CTV improves the margin of byte wise saving.
I give this as an example where CTV uses less space, it is detailed more
here: https://utxos.org/analysis/batching_sim/. This benefit might be
marginal and absurd, given these are already big transactions, but it may
_also_ be absurd that feerates only ever go up and congestion control is
not valuable.
Another example where this arises is where you have a transaction set you
need to pay top-of-mempool rate for the soonest confirmation you can get.
CTV has a decongesting effect, because your top-of-mempool transaction is
small, which doesn't trigger as much rivalrous behavior with other
transactors. Concretely, the current policy max txn size is 100kb, or 10%
of a block. If you bump out of next block window 10% of the mempool, then
if those transactors care to maintain their positioning, they will need to
put themselves into a higher percentile with e.g. RBF or CPFP. Whereas if
you put in a transaction that is just 100 bytes, you only bump out 100
bytes of rivals (0.01%), not 10%.
Lastly, perhaps a more realistic scenario, is where I am batching to 100
customers who all wish to do something else after I pay them. E.g., open a
lightning channel. Being able to use CTV noninteractive channels cuts
through the extra hop transaction (unless dual funded channels, unless the
channels are opened between two customers, then they can be dual funded
again). So using CTV here also saves in net blockspace (although, note,
this is sort of orthogonal to using CTV over the batch itself, just a good
example for the related question of 'doesn't ctv generally use more
blockspace').
> There are some other proposed use cases for bare-CTV. A bare-CTV can be
> used to delay a "trigger"-transaction. Some contracts, such as vaults, use
> a relative-locktime as part of their construction and it could make sense
> to make an output commitment but not realize those outputs yet until you
> are ready to start your relative-time lock clock. But bare-CTV doesn't
> support any co-signing ability here, so you are relying entirely on keeping
> the transaction data secret to prevent a third-party from triggering your
> relative-lock clock. More specifically for a vault scheme, since
> bare-CTV's are currently unaddressable, and AFAIK, there is no address
> format proposal yet, it is impossible to receive funds directly into a
> vault. You must shuffle received funds into your vault yourself, which
> seems very likely to negate the cost savings of using bare-CTV in the first
> place (please correct me if I'm wrong). Better to receive funds directly
> into a taproot-CTV vault, which has an address, and while you are at it,
> you could place the cold-key as the taproot key to save even more when
> using the cold-key to move vault funds.
>
>
This is not quite true, you can receive funds into a bare-CTV from your
vault software, and you can send into one from your vault software. What
doesn't work is exporting or creating an address for that. As a reminder
for those following along at home, not all standard output types have
addresses, even today. For example, OP_RETURN.
However, this is a standarness question. If the market _wanted_ such an
address, one could be adopted without requiring consensus processes.
Generally, the vault designs I work on use Sapio and therefore also use
Taproot since I have not added support for non-taproot scripts / removed
support for witness v0. I will eventually add these back, but it's a
marginal fee savings optimization and I'm focused primarily on feature
completeness.
> There might be even more exotic use cases of bare-CTV. For example you
> could commit to a transaction that has a second input that doesn't yet
> exist in the UTXO set in an attempt to coax it into existence. I don't know
> if there have been any proposals to take advantage of this.
>
There are, but it's not specific to how bare ctv works, it should work from
any CTV context.
>
> With that said, everything that bare-CTV can do, can also be done by
> tapscript-CTV; so it is just a matter of cost. I'm struggling to
> understand where this cost savings is and how much those savings are going
> to be given that bare-CTV is unaddressable and seems to ultimately occupy
> more-blockspace than if the outputs were directly committed to.
>
> I also believe the bare-CTV question is material, because if bare-CTV were
> not part of the spec, then I'd be advocating for using an OP_SUCCESS code
> from tapscript instead, and either use push-style semantics for CTV, which
> would be composed with EQUAL_VERIFY to mimic the currently proposed
> verification style-semantics, or a hybrid push-or-verify semantics that
> would either push or verify depending on the size of the input. (And I
> still think a more general TXHASH would be even better, though if I cannot
> convince aj then perhaps I'm wrong.)
>
Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
couldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone
has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
signatures, but still want CTV.
>
> I'm not saying bare-CTV is necessarily a bad idea. I'm just struggling
> with its justification.
>
Fair. I wouldn't have a big problem removing it, if it were clear that were
it to become desired, we could add it back. I think the case for CTV in
Segwitv0 is stronger, which has the same implication for a PUSH variant of
CTV.
Thanks again,
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/20220421/c88f5d72/attachment.html>

2023-06-07 23:07:27

- reply

📅 Original date posted:2022-04-21
📝 Original message:Missed one for part 2:
Shesek's social recovery wallet using CTV to enforce timelocks without
expiry, using his Minsc toolchain:
https://twitter.com/shesek/status/1511619296367153153
https://docs.google.com/presentation/d/1B59CdMIXW-wSW6CaLSgo7y4kvgrEwVgfY14IW2XV_MA/edit#slide=id.g1235f9ffb79_0_81
https://github.com/shesek/plebfi2022-social-recovery
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Thu, Apr 21, 2022 at 1:16 AM Jeremy Rubin <jeremy.l.rubin at gmail.com>
wrote:
> 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/a4e08892/attachment-0001.html>

2023-06-07 23:07:26

- 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-07 23:07:12

- reply

📅 Original date posted:2022-04-17
📝 Original message:the 'lots of people' stuff (get confused, can't figure out what i'm
quoting, actually are reading this conversation) is an appeal to an
authority that doesn't exist. If something is unclear to you, let me know.
If it's unclear to a supposed existential person or set of persons, they
can let me know.
concretely, I am confused by how OTS can both support RBF for updating to
larger commitments (the reason you're arguing with me) and not have an
epoch based re-comittings scheme and still be correct. My assumption now,
short of a coherent spec that's not just 'read the code', is that OTS
probably is not formally correct and has some holes in what is
committed to, or relies on clients re-requesting proofs if they fail to be
committed. in any case, you would be greatly aided by having an actual spec
for OTS since i'm not interested in the specifics of OTS software, but I'm
willing to look at the protocol. So if you do that, maybe we can talk more
about the issue you see with how sponsors works.
further, I think that if there is something that sponsors does that could
make a hypothetical OTS-like service work better, in a way that would be
opaque (read: soft-fork like wrt compatibility) to clients, then we should
just change what OTS is rather than committing ourselves to a worse design
in service of some unstated design goals. In particular, it seems that
OTS's servers can be linearized and because old clients aren't looking for
linearization, then the new linearization won't be a breaking change for
old clients, just calendar servers. And new clients can benefit from
linearization.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Fri, Apr 15, 2022 at 7:52 AM Peter Todd <pete at petertodd.org> wrote:
> On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > > nonsense marketing
> >
> > I'm sure the people who are confused about "blockchain schemes as \"world
> > computers\" and other nonsense
> > marketing" are avid and regular readers of the bitcoin devs mailing list
> so
> > I offer my sincerest apologies to all members of the intersection of
> those
> > sets who were confused by the description given.
>
> Of course, uninformed people _do_ read all kinds of technical materials.
> And
> more importantly, those technical materials get quoted by journalists,
> scammers, etc.
>
> > > useless work
> >
> > progress is not useless work, it *is* useful work in this context. you
> have
> > committed to some subset of data that you requested -- if it was
> 'useless',
> > why did you *ever* bother to commit it in the first place? However, it is
> > not 'maximally useful' in some sense. However, progress is progress --
> > suppose you only confirmed 50% of the commitments, is that not progress?
> If
> > you just happened to observe 50% of the commitments commit because of
> > proximity to the time a block was mined and tx propagation naturally
> would
> > you call it useless?
>
> Please don't trim quoted text to the point where all context is lost. Lots
> of
> people read this mailing list and doing that isn't helpful to them.
>
> > > Remember that OTS simply proves data in the past. Nothing more.
> > > OTS doesn't have a chain of transactions
> > Gotcha -- I've not been able to find an actual spec of Open Time Stamps
>
> The technical spec of OpenTimestamps is of course the normative validation
> source code, currently python-opentimestamps, similar to how the technical
> spec
> of Bitcoin is the consensus parts of the Bitcoin Core codebase. The
> explanatory
> docs are linked on https://opentimestamps.org under the "How It Works"
> section.
> It'd be good to take the linked post in that section and turn it into
> better
> explanatory materials with graphics (esp interactive/animated graphics).
>
> > anywhere, so I suppose I just assumed based on how I think it *should*
> > work. Having a chain of transactions would serve to linearize history of
> > OTS commitments which would let you prove, given reorgs, that knowledge
> of
> > commit A was before B a bit more robustly.
>
> I'll reply to this as a separate email as this discussion - while useful -
> is
> getting quite off topic for this thread.
>
> > > I'd rather do one transaction with all pending commitments at a
> > particular time
> > rather than waste money on mining two transactions for a given set of
> > commitments
> >
> > This sounds like a personal preference v.s. a technical requirement.
> >
> > You aren't doing any extra transactions in the model i showed, what
> you're
> > doing is selecting the window for the next based on the prior conf.
>
> ...the model you showed is wrong, as there is no reason to have a
> linearized
> transaction history. OpenTimestamps proofs don't even have the concept of
> transactions: the proof format proves that data existed prior to a merkle
> root
> of a particular Bitcoin block. Not a Bitcoin transaction.
>
> > See the diagram below, you would have to (if OTS is correct) support this
> > sort of 'attempt/confirm' head that tracks attempted commitments and
> > confirmed ones and 'rewinds' after a confirm to make the next commit
> > contain the prior attempts that didn't make it.
> >
> >
> [.........................................................................]
> > ------^ confirm head tx 0 at height 34
> > ------------------------^ attempt head after tx 0
> > -----------^ confirm head tx 1 at height 35
> > --------------------------^ attempt head after tx 1
> > ------------^ confirm head tx 2 at height 36
> > -------------------------------^
> > attempt head after tx 2
> > -------------------------------^
> > confirm head tx 3 at height 37
> >
> > you can compare this to a "spherical cow" model where RBF is always
> perfect
> > and guaranteed inclusion:
> >
> >
> >
> [.........................................................................]
> > ------^ confirm head tx 0 at height 34
> > -------------------------^ confirm head tx 1 at height 35
> > -----------^ confirm head at tx 1
> > height 36
> > -----------------^
> > confirm head tx 3 at height 37
> >
> > The same number of transactions gets used over the time period.
>
> None of the above has anything to do with how OpenTimestamps works.
>
> Anyway, getting back to the topic at hand, I remain of the opinion that in
> the
> unlikely event that fee accounts is ever implemented, it should be opt-in.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220417/be59c0a8/attachment.html>

2023-06-07 23:07:11

- reply

📅 Original date posted:2022-04-11
📝 Original message:> nonsense marketing
I'm sure the people who are confused about "blockchain schemes as \"world
computers\" and other nonsense
marketing" are avid and regular readers of the bitcoin devs mailing list so
I offer my sincerest apologies to all members of the intersection of those
sets who were confused by the description given.
> useless work
progress is not useless work, it *is* useful work in this context. you have
committed to some subset of data that you requested -- if it was 'useless',
why did you *ever* bother to commit it in the first place? However, it is
not 'maximally useful' in some sense. However, progress is progress --
suppose you only confirmed 50% of the commitments, is that not progress? If
you just happened to observe 50% of the commitments commit because of
proximity to the time a block was mined and tx propagation naturally would
you call it useless?
> Remember that OTS simply proves data in the past. Nothing more.
> OTS doesn't have a chain of transactions
Gotcha -- I've not been able to find an actual spec of Open Time Stamps
anywhere, so I suppose I just assumed based on how I think it *should*
work. Having a chain of transactions would serve to linearize history of
OTS commitments which would let you prove, given reorgs, that knowledge of
commit A was before B a bit more robustly.
> I'd rather do one transaction with all pending commitments at a
particular time
rather than waste money on mining two transactions for a given set of
commitments
This sounds like a personal preference v.s. a technical requirement.
You aren't doing any extra transactions in the model i showed, what you're
doing is selecting the window for the next based on the prior conf.
See the diagram below, you would have to (if OTS is correct) support this
sort of 'attempt/confirm' head that tracks attempted commitments and
confirmed ones and 'rewinds' after a confirm to make the next commit
contain the prior attempts that didn't make it.
[.........................................................................]
------^ confirm head tx 0 at height 34
------------------------^ attempt head after tx 0
-----------^ confirm head tx 1 at height 35
--------------------------^ attempt head after tx 1
------------^ confirm head tx 2 at height 36
-------------------------------^
attempt head after tx 2
-------------------------------^
confirm head tx 3 at height 37
you can compare this to a "spherical cow" model where RBF is always perfect
and guaranteed inclusion:
[.........................................................................]
------^ confirm head tx 0 at height 34
-------------------------^ confirm head tx 1 at height 35
-----------^ confirm head at tx 1
height 36
-----------------^
confirm head tx 3 at height 37
The same number of transactions gets used over the time period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220411/2492791b/attachment.html>

2023-06-07 23:06:26

- reply

📅 Original date posted:2022-03-13
📝 Original message:Hi Antoine,
I have a few high level thoughts on your post comparing these types of
primitive to an explicit soft fork approach:
1) Transaction sponsors *is* a type of covenant. Precisely, it is very
similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I
defined in my 2017 workshop
https://rubin.io/public/pdfs/multi-txn-contracts.pdf (I know, I know...
self citation, not cool, but helps with context).
However, for Sponsors itself we optimize the properties of how it works &
is represented, as well as "tighten the hatches" on binding to specific TX
vs merely spend of the outputs (which wouldn't work as well with APO).
Perhaps thinking of something like sponsors as a form of covenant, rather
than a special purpose thing, is helpful?
There's a lot you could do with a general "observe other txns in {this
block, the chain}" primitive. The catch is that for sponsors we don't
*care* to enable people to use this as a "smart contracting primitive", we
want to use it for fee bumping. So we don't care about programmability, we
care about being able to use the covenant to bump fees.
2) On Chain Efficiency.
A) Precommitted Levels
As you've noted, an approach like precomitted different fee levels might
work, but has substantial costs.
However, with sponsors, the minimum viable version of this (not quite what
is spec'd in my prior email, but it could be done this way if we care to
optimize for bytes) would require 1 in and 1 out with only 32 bytes extra.
So that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output +
32 bytes metadata = 174 bytes per bump. Bumps in this way can also
amortize, so bumping >1 txn at the same time would hit the limit of 32
bytes + 144/n bytes to bump more than one thing. You can imagine cases
where this might be popular, like "close >1 of my LN channels" or "start
withdrawals for 5 of my JamesOB vaulted coins"
B) Fancy(er) Covenants
We might also have something with OP_CAT and CSFS where bumps are done as
some sort of covenant-y thing that lets you arbitrarily rewrite
transactions.
Not too much to say other than that it is difficult to get these down in
size as the scripts become more complex, not to mention the (hotly
discussed of late) ramifications of those covenants more generally.
Absent a concrete fancy covenant with fee bumping, I can't comment.
3) On Capital Efficiency
Something like a precommitted or covenant fee bump requires the fee capital
to be pre-committed inside the UTXO, whereas for something like Sponsors
you can use capital you get sometime later. In certain models -- e.g.,
channels -- where you might expect only log(N) of your channels to fail in
a given epoch, you don't need to allocate as much capital as if you were to
have to do it in-band. This is also true for vaults where you know you only
want to open 1 per month let's say, and not <all of your vaults> per month,
which pre-committing requires.
4) On Protocol Design
It's nice that you can abstract away your protocol design concerns as a
"second tier composition check" v.s. having to modify your protocol to work
with a fee bumping thing.
There are a myriad of ways dynamic txns (e.g. for Eltoo) can lead to RBF
pinning and similar, Sponsor type things allow you to design such protocols
to not have any native way of paying for fees inside the actual
"Transaction Intents" and use an external system to create the intended
effect. It seems (to me) more robust that we can prove that a Sponsors
mechanism allows any transaction -- regardless of covenant stuff, bugs,
pinning, etc -- to move forward.
Still... careful protocol design may permit the use of optimized
constructions! For example, in a vault rather than assigning *no fee* maybe
you can have a single branch with a reasonable estimated fee. If you are
correct or overshot (let's say 50% chance?) then you don't need to add a
sponsor. If you undershot, not to worry, just add a sponsor. Adopted
broadly, this would cut the expected value of using sponsors by <however
good you are at estimating future fees>. This basically enables all
protocols to try to be more efficient, but backstop that with a guaranteed
to work safe mechanism.
There was something else I was going to say but I forgot about it... if it
comes to me I'll send a follow up email.
Cheers,
Jeremy
p.s.
>
> *Of course this makes for a perfect DoS: it would be trivial for a miner
> to infer that you are using*
> *a specific vault standard and guess other leaves and replace the witness
> to use the highest-feerate*
> *spending path. You could require a signature from any of the
> participants. Or, at the cost of an**additional depth, in the tree you
> could "salt" each leaf by pairing it with -say- an OP_RETURN leaf.*
you don't need a salt, you just need a unique payout addr (e.g. hardened
derivation) per revocation txn and you cannot guess the branch.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Sat, Mar 12, 2022 at 10:34 AM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The idea of a soft fork to fix dynamic fee bumping was recently put back
> on the table. It might
> sound radical, as what prevents today reasonable fee bumping for contracts
> with presigned
> transactions (pinning) has to do with nodes' relay policy. But the
> frustration is understandable
> given the complexity of designing fee bumping with today's primitives. [0]
> Recently too, there was a lot of discussions around covenants. Covenants
> (conceptually, not talking
> about any specific proposal) seem to open lots of new use cases and to be
> desired by (some?) Bitcoin
> application developers and users.
> I think that fee bumping using covenants has attractive properties, and it
> requires a soft fork that
> is already desirable beyond (trying) to fix fee bumping. However i could
> not come up with a solution
> as neat for other protocols than vaults. I'd like to hear from others
> about 1) taking this route for
> fee bumping 2) better ideas on applying this to other protocols.
>
>
> In a vault construction you have a UTxO which can only be spent by an
> Unvaulting transaction, whose
> output triggers a timelock before the expiration of which a revocation
> transaction may be confirmed.
> The revocation transaction being signed in advance (typically before
> sharing the signature for the
> Unvault transaction) you need fee bumping in order for the contract to
> actually be enforceable.
>
> Now, with a covenant you could commit to the revocation tx instead of
> presigning it. And using a
> Taproot tree you could commit to different versions of it with increasing
> feerate. Any network
> monitor (the brooadcaster, a watchtower, ..) would be able to RBF the
> revocation transaction if it
> doesn't confirm by spending using a leaf with a higher-feerate transaction
> being committed to.
>
> Of course this makes for a perfect DoS: it would be trivial for a miner to
> infer that you are using
> a specific vault standard and guess other leaves and replace the witness
> to use the highest-feerate
> spending path. You could require a signature from any of the participants.
> Or, at the cost of an
> additional depth, in the tree you could "salt" each leaf by pairing it
> with -say- an OP_RETURN leaf.
> But this leaves you with a possible internal blackmail for multi-party
> contracts (although it's less
> of an issue for vaults, and not one for single-party vaults).
> What you could do instead is attaching an increasing relative timelock to
> each leaf (as the committed
> revocation feerate increases, so does the timelock). You need to be
> careful to note wreck miner
> incentives here (see [0], [1], [2] on "miner harvesting"), but this
> enables the nice property of a
> feerate which "adapts" to the block space market. Another nice property of
> this approach is the
> integrated anti fee sniping protection if the revocation transaction pays
> a non-trivial amount of
> fees.
>
> Paying fees from "shared" funds instead of a per-watchtower fee-bumping
> wallet opened up the
> blackmail from the previous section, but the benefits of paying from
> internal funds shouldn't be
> understated.
> No need to decide on an amount to be refilled. No need to bother the user
> to refill the fee-bumping
> wallet (before they can participate in more contracts, or worse before a
> deadline at which all
> contracts are closed). No need for a potentially large amount of funds to
> just sit on a hot wallet
> "just in case". No need to duplicate this amount as you replicate the
> number of network monitors
> (which is critical to the security of such contracts).
> In addition, note how modifying the feerate of the revocation transaction
> in place is less expensive
> than adding a (pair of) new input (and output), let alone adding an entire
> new transaction to CPFP.
> Aside, and less importantly, it can be made to work with today's relay
> rules (just use fee thresholds
> adapted to the current RBF thresholds, potentially with some leeway to
> account for policy changes).
> Paying from shared funds (in addition to paying from internal funds) also
> prevents pervert
> incentives for contracts with more than 2 parties. In case one of the
> parties breaches it, all
> remaining parties have an incentive to enforce the contract.. But only one
> would otherwise pay for
> it! It would open up the door to some potential sneaky techniques to wait
> for another party to pay
> for the fees, which is at odd with the reactive security model.
>
> Let's examine how it could be concretely designed. Say you have a vault
> wallet software for a setup
> with 5 participants. The revocation delay is 144 blocks. You assume
> revocation to be infrequent (if
> one happens it's probably a misconfigured watchtower that needs be fixed
> before the next
> unvaulting), so you can afford infrequent overpayments and larger fee
> thresholds. Participants
> assume the vault will be spent within a year and assume a maximum possible
> feerate for this year of
> 10ksat/vb.
> They create a Taproot tree of depth 7. First leaf is the spending path
> (open to whomever the vault
> pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a
> covenant to the revocation
> transaction with a feerate `i * 79` sats/vb and a relative timelock of `i
> - 1` blocks.
> Assuming the covenant to the revocation transaction is 33 bytes [3],
> that's a witness of:
> 1 + 33 + 1 + 33 + 7 * 32 = 292 WU (73 vb)
> ^^^^^^ ^^^^^^^^^^^^^^
> witscript control block
> for any of the revocation paths. The revocation transaction is 1-input
> 1-output, so in total it's
> 10.5 + 41 + 73 + 43 = 167.5 vb
> ^^^^ ^^^^^^^^^^^ ^^^^
> header input|witness output
> The transaction size is not what you'd necessarily want to optimize for
> first, still, it is smaller
> in this case than using other feebumping primitives and has a smaller
> footprint on the UTxO set. For
> instance for adding a feebumping input and change output assuming all
> Taproot inputs and outputs
> (CPFP is necessarily even larger):
> 5 * 64 + 1 + 5 * (32 + 1) + 1 + 33 = 520 WU (105 vb)
> ^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^
> witness witscript control
> 10.5 + 41 + 105 + 41 + 16.5 + 2 * 43 = 300 vb
> ^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
> header input|witness fb input|witness outputs
> From there, you can afford more depths at the tiny cost of 8 more vbytes
> each. You might want them
> for:
> - more granularity (if you can afford large enough timelocks)
> - optimizing for the spending path rather than the revocation one
> - adding a hashlock to prevent nuisance (with the above script a third
> party could malleate a
> spending path into a revocation one). You can use the OP_RETURN trick
> from above to prevent that.
>
> Unfortunately, the timelocked-covenant approach to feebumping only applies
> to bumping the first
> transaction of a chain (you can't pay for the parent with a timelock) so
> for instance it's not
> usable for HTLC transactions in Lightning to bump the parent commitment
> tx. The same goes for
> bumping the update tx in Coinpool.
> It could be worked around by having a different covenant per participant
> (paying the fee from either
> of the participants' output) behind a signature check. Of course it
> requires funds to already be in
> the contract (HTLC, Coinpool leaf) to pay for your own unilateral close,
> but if you don't have any
> fund in the contract it doesn't make sense to try to feebump it in the
> first place. The same goes
> for small amounts: you'd only allocate up to the value of the contract
> (minus a dust preference) in
> fees in order to enforce it.
> This is less nice for external monitors as it requires a private key (or
> another secret) to be
> committed to in advance) to be able to bump [4] and does not get rid of
> the "who's gonna pay for the
> enforcement" issue in >2-parties contracts. Still, it's more optimal and
> usable than CPFP or adding
> a pair of input/output for all the reasons mentioned above.
>
>
> Thoughts?
> Antoine
>
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019627.html
> [3] That's obviously close to the CTV construction. But using another more
> flexible (and therefore
> less optimized) construction would not be a big deal. It might in fact
> be necessary for more
> elaborated (realistic?) usecases than the simple one detailed here.
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
> _______________________________________________
> 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/20220312/980f7dcc/attachment-0001.html>

2023-06-07 23:05:51

- 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-07 23:05:48

- reply

📅 Original date posted:2022-03-08
📝 Original message:Hi all,
There will be a CTV meeting tomorrow at noon PT. Agenda below:
1) Sapio Taproot Support Update / Request for Review (20 Minutes)
- Experimental support for Taproot merged on master
https://github.com/sapio-lang/sapio
2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
3) Jamesob's Non-Recursive Vaults Post (20 minutes)
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
4) What the heck is everyone talking about on the mailing list all of the
sudden (30 minutes)
- EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
5) Q&A (30 mins)
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220307/b455f5e5/attachment.html>

2023-06-07 23:05:48

- reply

📅 Original date posted:2022-03-08
📝 Original message:* Tuesday, March 8th.
I think Noon PT == 8pm UTC?
but dont trust me i cant even tell what day is what.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin <jeremy.l.rubin at gmail.com>
wrote:
> Hi all,
>
> There will be a CTV meeting tomorrow at noon PT. Agenda below:
>
> 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
> - Experimental support for Taproot merged on master
> https://github.com/sapio-lang/sapio
> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
> -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
> -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
> -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
> 4) What the heck is everyone talking about on the mailing list all of the
> sudden (30 minutes)
> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
> 5) Q&A (30 mins)
>
> Best,
>
> Jeremy
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220307/9bf27d21/attachment.html>

2023-06-07 23:05:28

- reply

📅 Original date posted:2022-03-04
📝 Original message:I've seen some discussion of what the Annex can be used for in Bitcoin. For
example, some people have discussed using the annex as a data field for
something like CHECKSIGFROMSTACK type stuff (additional authenticated data)
or for something like delegation (the delegation is to the annex). I think
before devs get too excited, we should have an open discussion about what
this is actually for, and figure out if there are any constraints to using
it however we may please.
The BIP is tight lipped about it's purpose, saying mostly only:
*What is the purpose of the annex? The annex is a reserved space for future
extensions, such as indicating the validation costs of computationally
expensive new opcodes in a way that is recognizable without knowing the
scriptPubKey of the output being spent. Until the meaning of this field is
defined by another softfork, users SHOULD NOT include annex in
transactions, or it may lead to PERMANENT FUND LOSS.*
*The annex (or the lack of thereof) is always covered by the signature and
contributes to transaction weight, but is otherwise ignored during taproot
validation.*
*Execute the script, according to the applicable script rules[11], using
the witness stack elements excluding the script s, the control block c, and
the annex a if present, as initial stack.*
Essentially, I read this as saying: The annex is the ability to pad a
transaction with an additional string of 0's that contribute to the virtual
weight of a transaction, but has no validation cost itself. Therefore,
somehow, if you needed to validate more signatures than 1 per 50 virtual
weight units, you could add padding to buy extra gas. Or, we might somehow
make the witness a small language (e.g., run length encoded zeros) such
that we can very quickly compute an equivalent number of zeros to 'charge'
without actually consuming the space but still consuming a linearizable
resource... or something like that. We might also e.g. want to use the
annex to reserve something else, like the amount of memory. In general, we
are using the annex to express a resource constraint efficiently. This
might be useful for e.g. simplicity one day.
Generating an Annex: One should write a tracing executor for a script, run
it, measure the resource costs, and then generate an annex that captures
any externalized costs.
-------------------
Introducing OP_ANNEX: Suppose there were some sort of annex pushing opcode,
OP_ANNEX which puts the annex on the stack as well as a 0 or 1 (to
differentiate annex is 0 from no annex, e.g. 0 1 means annex was 0 and 0 0
means no annex). This would be equivalent to something based on <annex
flag> OP_TXHASH <has annex flag> OP_TXHASH.
Now suppose that I have a computation that I am running in a script as
follows:
OP_ANNEX
OP_IF
`some operation that requires annex to be <1>`
OP_ELSE
OP_SIZE
`some operation that requires annex to be len(annex) + 1 or does a
checksig`
OP_ENDIF
Now every time you run this, it requires one more resource unit than the
last time you ran it, which makes your satisfier use the annex as some sort
of "scratch space" for a looping construct, where you compute a new annex,
loop with that value, and see if that annex is now accepted by the program.
In short, it kinda seems like being able to read the annex off of the stack
makes witness construction somehow turing complete, because we can use it
as a register/tape for some sort of computational model.
-------------------
This seems at odds with using the annex as something that just helps you
heuristically guess computation costs, now it's somehow something that
acts to make script satisfiers recursive.
Because the Annex is signed, and must be the same, this can also be
inconvenient:
Suppose that you have a Miniscript that is something like: and(or(PK(A),
PK(A')), X, or(PK(B), PK(B'))).
A or A' should sign with B or B'. X is some sort of fragment that might
require a value that is unknown (and maybe recursively defined?) so
therefore if we send the PSBT to A first, which commits to the annex, and
then X reads the annex and say it must be something else, A must sign
again. So you might say, run X first, and then sign with A and C or B.
However, what if the script somehow detects the bitstring WHICH_A WHICH_B
and has a different Annex per selection (e.g., interpret the bitstring as a
int and annex must == that int). Now, given and(or(K1, K1'),... or(Kn,
Kn')) we end up with needing to pre-sign 2**n annex values somehow... this
seems problematic theoretically.
Of course this wouldn't be miniscript then. Because miniscript is just for
the well behaved subset of script, and this seems ill behaved. So maybe
we're OK?
But I think the issue still arises where suppose I have a simple thing
like: and(COLD_LOGIC, HOT_LOGIC) where both contains a signature, if
COLD_LOGIC and HOT_LOGIC can both have different costs, I need to decide
what logic each satisfier for the branch is going to use in advance, or
sign all possible sums of both our annex costs? This could come up if
cold/hot e.g. use different numbers of signatures / use checksigCISAadd
which maybe requires an annex argument.
------------
It seems like one good option is if we just go on and banish the OP_ANNEX.
Maybe that solves some of this? I sort of think so. It definitely seems
like we're not supposed to access it via script, given the quote from above:
*Execute the script, according to the applicable script rules[11], using
the witness stack elements excluding the script s, the control block c, and
the annex a if present, as initial stack.*
If we were meant to have it, we would have not nixed it from the stack, no?
Or would have made the opcode for it as a part of taproot...
But recall that the annex is committed to by the signature.
So it's only a matter of time till we see some sort of Cat and Schnorr
Tricks III the Annex Edition that lets you use G cleverly to get the annex
onto the stack again, and then it's like we had OP_ANNEX all along, or
without CAT, at least something that we can detect that the value has
changed and cause this satisfier looping issue somehow.
Not to mention if we just got OP_TXHASH
-----------
Is the annex bad? After writing this I sort of think so?
One solution would be to... just soft-fork it out. Always must be 0. When
we come up with a use case for something like an annex, we can find a way
to add it back. Maybe this means somehow pushing multiple annexes and
having an annex stack, where only sub-segments are signed for the last
executed signature? That would solve looping... but would it break some
aggregation thing? Maybe.
Another solution would be to make it so the annex is never committed to and
unobservable from the script, but that the annex is always something that
you can run get_annex(stack) to generate the annex. Thus it is a hint for
validation rules, but not directly readable, and if it is modified you
figure out the txn was cheaper sometime after you execute the scripts and
can decrease the value when you relay. But this sounds like something that
needs to be a p2p only annex, because consensus we may not care (unless
it's something like preallocating memory for validation?).
-----------------------
Overall my preference is -- perhaps sadly -- looking like we should
soft-fork it out of our current Checksig (making the policy that it must 0
a consensus rule) and redesign the annex technique later when we actually
know what it is for with a new checksig or other mechanism. But It's not a
hard opinion! It just seems like you can't practically use the annex for
this worklimit type thing *and* observe it from the stack meaningfully.
Thanks for coming to my ted-talk,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220304/361dd848/attachment.html>

2023-06-07 23:05:26

- reply

📅 Original date posted:2022-03-05
📝 Original message:There's no point to pegging coins that are worthless into a system of also
worthless coins, unless you want to test the mechanism of testing pegging.
As is, it's hard enough to get people set up on a signet, if they have to
run two nodes and then scramble to find testnet coins and then peg them
were just raising the barriers to entry for starting to use a signet for
testing.
If anything I think we should permanently shutter testnet now that signet
is available.
On Sat, Mar 5, 2022, 3:53 PM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> In testnet3, anyone can become a miner, it is possible to even mine a
> block on some CPU, because the difficulty can drop to one. In signet, we
> create some challenge, for example 1-of-2 multisig, that can restrict who
> can mine, so that chain can be "unreliably reliable". Then, my question is:
> why signets are introducing new coins out of thin air, instead of forming
> two-way peg-in between testnet3 and signet?
>
> The lack of coins is not a bug, it is a feature. We have more halvings in
> testnet3 than in mainnet or signets, but it can be good, we can use this to
> see, what can happen with a chain after many halvings. Also, in testnet3
> there is no need to have any coins if we are mining. Miners can create,
> move and destroy zero satoshis. They can also extend the precision of the
> coins, so a single coin in testnet3 can be represented as a thousand of
> coins in some signet sidechain.
>
> Recently, there are some discussions regarding sidechains. Before they
> will become a real thing, running on mainnet, they should be tested.
> Nowadays, a popular way of testing new features is creating a new signet
> with new rules. But the question still remains: why we need new coins,
> created out of thin air? And even when some signet wants to do that, then
> why it is not pegged into testnet3? Then it would have as much chainwork
> protection as testnet3!
>
> It seems that testnet3 is good enough to represent the main chain during
> sidechain testing. It is permissionless and open, anyone can start mining
> sidechain blocks, anyone with a CPU can be lucky and find a block with the
> minimal difficulty. Also, because of blockstorms and regular chain reorgs,
> some extreme scenarios, like stealing all coins from some sidechain, can be
> tested in a public way, because that "unfriendly and unstable" environment
> can be used to test stronger attacks than in a typical chain.
>
> Putting that proposal into practice can be simple and require just
> creating one Taproot address per signet in testnet3. Then, it is possible
> to create one testnet transaction (every three months) that would move
> coins to and from testnet3, so the same coins could travel between many
> signets. New signets can be pegged in with 1:1 ratio, existing signets can
> be transformed into signet sidechains (the signet miners rule that chains,
> so they can enforce any transition rules they need).
> _______________________________________________
> 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/20220305/b5cb634a/attachment-0001.html>

2023-06-07 23:05:10

- reply

📅 Original date posted:2022-03-05
📝 Original message:This may be of interest:
https://github.com/sapio-lang/sapio/blob/01830132bbbe39c3225e173e099f6e1a0611461c/sapio/examples/subscription.py
Basically, a (old, python) sapio contract whereby you can make cancellable
subscriptions that are essentially a time based autopay scheme whereby
cancellation gives time for the receiver to claim the correct amount of
money.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Sat, Mar 5, 2022 at 10:58 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Chris,
>
> > I think this proposal describes arbitrary lines of pre-approved credit
> from a bitcoin wallet. The line can be drawn down with oracle attestations.
> You can mix in locktimes on these pre-approved lines of credit if you would
> like to rate limit, or ignore rate limiting and allow the full utxo to be
> spent by the borrower. It really is contextual to the use case IMO.
>
> Ah, that seems more useful.
>
> Here is an example application that might benefit from this scheme:
>
> I am commissioning some work from some unbranded workperson.
> I do not know how long the work will take, and I do not trust the
> workperson to accurately tell me how complete the work is.
> However, both I and the workperson trust a branded third party (the
> oracle) who can judge the work for itself and determine if it is complete
> or not.
> So I create a transaction whose signature can be completed only if the
> oracle releases a proper scalar and hand it over to the workperson.
> Then the workperson performs the work, then asks the oracle to judge if
> the work has been completed, and if so, the work can be compensated.
>
> On the other hand, the above, where the oracle determines *when* the fund
> can be spent, can also be implemented by a simple 2-of-3, and called an
> "escrow".
> After all, the oracle attestation can be a partial signature as well, not
> just a scalar.
> Is there a better application for this scheme?
>
> I suppose if the oracle attestation is intended to be shared among
> multiple such transactions?
> There may be multiple PTLCs, that are triggered by a single oracle?
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20220306/df48d359/attachment-0001.html>

2023-06-07 23:04:33

- reply

📅 Original date posted:2022-02-18
📝 Original message:This is a fascinating post and I'm still chewing on it.
Chiming in with two points:
Point 1, note with respect to evictions, revivals, CTV, TLUV:
CTV enables 1 person to be evicted in O(log N) or one person to leave in
O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but
evictions take (AFAICT?) O(N) O(log N) transactions because the un-live
party stays in the pool. Hence OP_EVICT helps also make it so you can kick
someone out, rather than all having to leave, which is an improvement.
CTV rejoins work as follows:
suppose you have a pool with 1 failure, you need to do log N txns to evict
the failure, which creates R * log_R(N) outputs, which can then do a
transaction to rejoin.
For example, suppose I had 64 people in a radix 4 tree. you'd have at the
top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.
Kicking 1 person out would make you do 3 txns, and create 12 outputs total.
A transaction spending the 11 outputs that are live would capture 63 people
back into the tree, and with CISA would not be terribly expensive. To be a
bit more economical, you might prefer to just join the 3 outputs with 16
people in it, and yield 48 people in one pool. Alternatively, you can
lazily re-join if fees make it worth it/piggybacking another transaction,
or operate independently or try to find new, better, peers.
Overall this is the type of application that necessitates *exact* byte
counting. Oftentimes things with CTV seem inefficient, but when you crunch
the numbers it turns out not to be so terrible. OP_EVICT seems promising in
this regard compared to TLUV or accumulators.
Another option is to randomize the CTV trees with multiple outputs per
party (radix Q), then you need to do Q times the evictions, but you end up
with sub-pools that contain more people/fractional liquidity (this might
happen naturally if CTV Pools have channels in them, so it's good to model).
Point 2, on Eltoo:
One point of discomfort I have with Eltoo that I think is not universal,
but is shared by some others, is that non-punitive channels may not be good
for high-value channels as you do want, especially in a congested
blockspace world, punishments to incentivize correct behavior (otherwise
cheating may look like a free option).
Thus I'm reluctant to fully embrace designs which do not permit nested
traditional punitive channels in favor of Eltoo, when Eltoo might not have
product-market-fit for higher valued channels.
If someone had a punitive-eltoo variant that would ameliorate this concern
almost entirely.
Cheers,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning ariard,
>
>
> > > A statechain is really just a CoinPool hosted inside a
> > > Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
> >
> > Note, to the best of my knowledge, how to use LN-Penalty in the context
> of multi-party construction is still an unsolved issue. If an invalidated
> state is published on-chain, how do you guarantee that the punished output
> value is distributed "fairly" among the "honest" set of users ? At least
> > where fairness is defined as a reasonable proportion of the balances
> they owned in the latest state.
>
> LN-Penalty I believe is what I call Poon-Dryja?
>
> Both Decker-Wattenhofer (has no common colloquial name) and
> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
> The former has bad locktime tradeoffs in the unilateral close case, and
> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>
>
> > > In principle, a set of promised outputs, if the owners of those
> > > outputs are peers, does not have *any* inherent order.
> > > Thus, I started to think about a commitment scheme that does not
> > > impose any ordering during commitment.
> >
> > I think we should dissociate a) *outputs publication ordering* from the
> b) *spends paths ordering* itself. Even if to each spend path a output
> publication is attached, the ordering constraint might not present the same
> complexity.
> >
> > Under this distinction, are you sure that TLUV imposes an ordering on
> the output publication ?
>
> Yes, because TLUV is based on tapleaf revelation.
> Each participant gets its own unique tapleaf that lets that participant
> get evicted.
>
> In Taproot, the recommendation is to sort the hashes of each tapleaf
> before arranging them into a MAST that the Taproot address then commits to.
> This sort-by-hash *is* the arbitrary ordering I refer to when I say that
> TLUV imposes an arbitrary ordering.
> (actually the only requirement is that pairs of scripts are
> sorted-by-hash, but it is just easier to sort the whole array by hash.)
>
> To reveal a single participant in a TLUV-based CoinPool, you need to
> reveal O(log N) hashes.
> It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and
> I believe the reason for that O(log N) revelation is due precisely to the
> arbitrary but necessary ordering.
>
> > > With `OP_TLUV`, however, it is possible to create an "N-of-N With
> > > Eviction" construction.
> > > When a participant in the N-of-N is offline, but the remaining
> > > participants want to advance the state of the construction, they
> > > instead evict the offline participant, creating a smaller N-of-N
> > > where *all* participants are online, and continue operating.
> >
> > I think we should dissociate two types of pool spends : a) eviction by
> the pool unanimity in case of irresponsive participants and b) unilateral
> withdrawal by a participant because of the liquidity allocation policy. I
> think the distinction is worthy, as the pool participant should be stable
> and the eviction not abused.
> >
> > I'm not sure if TLUV enables b), at least without transforming the
> unilateral withdrawal into an eviction. To ensure the TLUV operation is
> correct (spent leaf is removed, withdrawing participant point removed,
> etc), the script content must be inspected by *all* the participant.
> However, I believe
> > knowledge of this content effectively allows you to play it out against
> the pool at any time ? It's likely solvable at the price of a CHECKSIG.
>
> Indeed, that distinction is important.
> `OP_TLUV` (and `OP_EVICT`, which is just a redesigned `OP_TLUV`) supports
> (a) but not (b).
>
> > `OP_EVICT`
> > ----------
> >
> > > * If it is `1` that simply means "use the Taproot internal
> > > pubkey", as is usual for `OP_CHECKSIG`.
> >
> > IIUC, this assumes the deployment of BIP118, where if the public key is
> a single byte 0x01, the internal pubkey is used
> > for verification.
>
> I thought it was part of Taproot?
>
> >
> > > * Output indices must not be duplicated, and indicated
> > > outputs must be SegWit v1 ("Taproot") outputs.
> >
> > I think public key duplication must not be verified. If a duplicated
> public key is present, the point is subtracted twice from the internal
> pubkey and therefore the aggregated
> > key remains unknown ? So it sounds to me safe against replay attacks.
>
> Ah, right.
>
> > > * The public key is the input point (i.e. stack top)
> > > **MINUS** all the public keys of the indicated outputs.
> >
> > Can you prevent eviction abuse where one counterparty threatens to evict
> everyone as all the output signatures are known among participants and free
> to sum ? (at least not considering fees)
>
> No, I considered onchain fees as the only mechanism to avoid eviction
> abuse.
> The individual-evict signatures commit to fixed quantities.
> The remaining change is then the only fund that can pay for onchain fees,
> so a single party evicting everyone else has to pay for the eviction of
> everyone else.
>
>
> > > Suppose however that B is offline.
> > > Then A, C, and D then decide to evict B.
> > > To do so, they create a transaction that has an output
> > > with "B := 6", and they reveal the `OP_EVICT` Tapscript
> > > as well as sign(b, "B := 6").
> > > This lets them change state and spend their funds without
> > > B being online.
> > > And B remains secure, as they cannot evict B except using
> > > the pre-signed output, which B certifies as their expected
> > > promised output.
> >
> > I think in the context of (off-chain) payment pool, OP_EVICT requires
> participant cooperation *after* the state update to allow a single
> participant to withdraw her funds.
>
> How so?
>
> A single participant withdrawing their funds unilaterally can do so by
> evicting everyone else (and paying for those evictions, as sort of a
> "nuisance fee").
> The signatures for each per-participant-eviction can be exchanged before
> the signature exchange for the Decker-Wattenhofer or
> Decker-Russell-Osuntokun.
>
>
> > > The combined fund cannot be spent except if all participants
> > > agree.
> >
> > If all participants agree minus the evicted ones, correct ? The output
> promises signatures are shared at state setup, therefore no additional
> contribution from the evicted participant (I think).
>
> Yes.
>
> >
> > > To prevent signature replay, each update of an updateable
> > > scheme like CoinPool et al should use a different pubkey
> > > for each participant for each state.
> >
> > I'm not even sure if it's required with OP_EVICT, as the publication of
> the promised output are ultimately restrained by a signature of the updated
> internal pubkey, this set of signers verify that promised output N does
> bind to the published state N ?
>
> If the internal pubkey is reused (for example, if all participants are
> online and want to change state cooperatively) then the component keys need
> to be re-tweaked each time.
>
> The tweaking can be done with non-hardened derivation.
>
>
> > > Its advantage is reduced number of eviction transactions,
> > > as multiple evictions, plus the revival of the CoinPool,
> > > can be put in a single transaction.
> > > It has the disadvantage relative to `OP_TLUV` of requiring
> > > point operations.
> > > I have not explored completely, but my instinct suggests
> > > that `OP_TLUV` use may require at least one signature
> > > validation anyway.
> >
> > I believe you can slightly modify TLUV to make it functional for
> CoinPool revival, where you want to prevent equivocation among the
> remaining set of signers. Though, I'm leaning to agree that you may require
> at least one signature validation (first to restrain spend authorization
> inside the pool participants, second to attach fees at broadcast-time).
>
> Yes, TLUV does have that advantage relative to CTV, and `OP_EVICT` is
> "just" a redesigned `OP_TLUV`.
>
> In particular, I first developed my thoughts on revivable constructs with
> eviction of participants here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20220218/a48f8546/attachment-0001.html>

2023-06-07 23:03:24

- reply

📅 Original date posted:2022-02-15
📝 Original message:Hi Rusty,
Please see my post in the other email thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
The differences in this regard are several, and worth understanding beyond
"you can iterate CTV". I'd note a few clear examples for showing that "CTV
is just as powerful" is not a valid claim:
1) CTV requires the contract to be fully enumerated and is non-recursive.
For example, a simple contract that allows n participants to take an action
in any order requires factorially many pre-computations, not just linear or
constant. For reference, 24! is about 2**80. Whereas for a more
interpretive covenant -- which is often introduced with the features for
recursion -- you can compute the programs for these addresses in constant
time.
2) CTV requires the contract to be fully enumerated: For example, a simple
contract one could write is "Output 0 script matches Output 1", and the set
of outcomes is again unbounded a-priori. With CTV you need to know the set
of pairs you'd like to be able to expand to a-priori
3) Combining 1 and 2, you could imagine recursing on an open-ended thing
like creating many identical outputs over time but not constraining what
those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output
2.
I think for your point the inverse seems to hold: for the limited
situations we might want to set up, CTV often ends up being sufficient
because usually we can enumerate all the possible outcomes we'd like (or at
least find a mapping onto such a construction). CTV is indeed very
powerful, but as I demonstrated above, not powerful in the same way
("Complexity Class") that OP_TX or TXHASH might be.
At the very least we should clearly understand *what* and *why* we are
advocating for more sophisticated designs and have a thorough understanding
of the protocol complexity we are motivated to introduce the expanded
functionality. Further, if one advocates for TX/TXHASH on a featureful
basis, it's at least a technical ACK on the functionality CTV is
introducing (as it is a subset) and perhaps a disagreement on project
management, which I think is worth noting. There is a very wide gap between
"X is unsafe" and "I prefer Y which X is a subset of ''.
I'll close by repeating : Whether that [the recursive/open ended
properties] is an issue or not precluding this sort of design or not, I
defer to others.
Best,
Jeremy
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Jeremy Rubin <jeremy.l.rubin at gmail.com> writes:
> > Rusty,
> >
> > Note that this sort of design introduces recursive covenants similarly to
> > how I described above.
> >
> > Whether that is an issue or not precluding this sort of design or not, I
> > defer to others.
>
> Good point!
>
> But I think it's a distinction without meaning: AFAICT iterative
> covenants are possible with OP_CTV and just as powerful, though
> technically finite. I can constrain the next 100M spends, for
> example: if I insist on those each having incrementing nLocktime,
> that's effectively forever.
>
> Thanks!
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/3c2a5425/attachment.html>

2023-06-07 23:03:23

- reply

📅 Original date posted:2022-02-08
📝 Original message:Rusty,
Note that this sort of design introduces recursive covenants similarly to
how I described above.
Whether that is an issue or not precluding this sort of design or not, I
defer to others.
Best,
Jeremy
On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
> > Given the overlap in functionality between CTV and ANYPREVOUT, I think it
> > makes sense to decompose their operations into their constituent pieces
> and
> > reassemble their behaviour programmatically. To this end, I'd like to
> > instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.
> >
> > OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)
> > txhash in accordance with that flag, and push the resulting hash onto the
> > stack.
>
> It may be worth noting that OP_TXHASH can be further decomposed into
> OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).
>
> OP_TX would place the concatenated selected fields onto the stack
> (rather than hashing them) This is more compact for some tests
> (e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs
> "OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and also range
> testing (e.g amount less than X or greater than X, or less than 3 inputs).
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust set of TXHASH flags from the start. For example
> having
> > bits to control whether (1) the version is covered; (2) the locktime is
> > covered; (3) txids are covered; (4) sequence numbers are covered; (5)
> input
> > amounts are covered; (6) input scriptpubkeys are covered; (7) number of
> > inputs is covered; (8) output amounts are covered; (9) output
> scriptpubkeys
> > are covered; (10) number of outputs is covered; (11) the tapbranch is
> > covered; (12) the tapleaf is covered; (13) the opseparator value is
> > covered; (14) whether all, one, or no inputs are covered; (15) whether
> all,
> > one or no outputs are covered; (16) whether the one input position is
> > covered; (17) whether the one output position is covered; (18) whether
> the
> > sighash flags are covered or not (note: whether or not the sighash flags
> > are or are not covered must itself be covered). Possibly specifying
> which
> > input or output position is covered in the single case and whether the
> > position is relative to the input's position or is an absolute position.
>
> These easily map onto OP_TX, "(1) the version is pushed as u32, (2) the
> locktime is pushed as u32, ...".
>
> We might want to push SHA256() of scripts instead of scripts themselves,
> to reduce possibility of DoS.
>
> I suggest, also, that 14 (and similarly 15) be defined two bits:
> 00 - no inputs
> 01 - all inputs
> 10 - current input
> 11 - pop number from stack, fail if >= number of inputs or no stack elems.
>
> Cheers,
> Rusty.
> _______________________________________________
> 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/20220207/2a0a1a47/attachment.html>

2023-06-07 23:02:42

- 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 15:41:30

- reply

📅 Original date posted:2015-07-03
📝 Original message:Jean-Paul,
I think you're missing what I'm saying -- the point of my suggestion to
make Rocket a min-spec is more along the lines of saying that the Rocket
serves as a fixed point, Bitcoin Core performance must be acceptable on
that platform, however it can be lower. Yes there are conversion factors
and different architectures will perform differently. However, there still
must be some baseline, a point at which we can say processors below it no
longer are supported. I am saying that line should never be set so high as
to exclude presently available open hardware.
Ultimately, this ends up making an odd, but nice, goal for Bitcoin
development. If Bitcoin Core needs more MIPS, the community must ensure the
availability of open hardware that it can run on.
Jeff,
Moxie looks fantastic! The reason I thought RISC-V was a good selection is
the very active development community which is pushing the performance of
the ISA implementations forward. Can you speak to the health of Moxie
development? Ultimately, ensuring support for many open architectures would
be preferable. Are there other reasonable open-source processors that you
are aware of?
I would be willing to work on a design a Bitcoin specific open-hardware
processor, up to the FPGA bound, if this would be useful for this goal.
On Fri, Jul 3, 2015 at 12:19 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com
> wrote:
> Ideally, the metrics that we settle on would be architecture agnostic and
> have some sort of conversion metric to map it onto any specific
> architecture. An Intel based architecture is going to perform vastly
> different from an ARM based one for example.
>
> Simple example: The PS3 PPE and Xbox 360 CPU are RISC processors that run
> at 3.2GHz, but their non-vector performance is rather poor. You’d be lucky
> to get about 33% effective utilization out of them (up to 50%, tops, but
> that’s really pushing it), so if you were to map this onto another
> architecture, you’d have at least a 3x conversion from this end alone (the
> other end could also have a scaling factor).
>
> Ultimately, how these values are expressed isn’t the important part. It’s
> the ability to measure the impact of a change that’s important. If some
> metric changes by, say, 5%, then it doesn’t really matter if it’s expressed
> in MIPS, INTOPS, MB or GB. The fact that it changed is what matters and
> what the effect is on the baseline (that ultimately could be expressed as a
> certain specific hardware configuration). It would probably be practical to
> have a number of comparable concrete min spec configurations and even more
> ideal would be if people in the community would have these systems up and
> running to do actual on-target performance benchmarks.
>
>
> jp
>
>
> On Jul 2, 2015, at 8:13 PM, Jeremy Rubin <jeremy.l.rubin.travel at gmail.com>
> wrote:
>
> Might I suggest that the min-spec, if developed, target the RISC-V Rocket
> architecture (running on FPGA, I suppose) as a reference point for
> performance? This may be much lower performance than desirable, however, it
> means that we don't lock people into using large-vendor chipsets which have
> unknown, or known to be bad, security properties such as Intel AMT.
>
> In general, targeting open hardware seems to me to be more critical than
> performance metrics for the long term health of Bitcoin, however,
> performance is still important.
>
> Does anyone know how the RISC-V FPGA performance stacks up to, say, a
> Raspberry Pi?
>
> On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <ogunden at phauna.org> wrote:
>
>> I'm also a user who runs a full node, and I also like this idea. I think
>> Gavin has done some back-of-the-envelope calculations around this stuff,
>> but nothing so clearly defined as what you propose.
>>
>> On 07/02/2015 08:33 AM, Mistr Bigs wrote:
>>
>>> I'm an end user running a full node on an aging laptop.
>>> I think this is a great suggestion! I'd love to know what system
>>> requirements are needed for running Bitcoin Core.
>>>
>>> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
>>> <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>> wrote:
>>>
>>> I’m a game developer. I write time critical code for a living and
>>> have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
>>> These budgets are based on what we call a minimum specification (of
>>> hardware); min spec for short. In most cases the min spec is based
>>> on entry model machines that are available during launch, and will
>>> give the user an enjoyable experience when playing our games.
>>> Obviously, we can turn on a number of bells and whistles for people
>>> with faster machines, but that’s not the point of this mail.
>>>
>>> The point is, can we define a min spec for Bitcoin Core? The number
>>> one reason for this is: if you know how your changes affect your
>>> available budgets, then the risk of breaking something due to
>>> capacity problems is reduced to practically zero.
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> 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/20150703/80b655af/attachment-0001.html>

2023-06-07 15:41:29

- reply

📅 Original date posted:2015-07-03
📝 Original message:Might I suggest that the min-spec, if developed, target the RISC-V Rocket
architecture (running on FPGA, I suppose) as a reference point for
performance? This may be much lower performance than desirable, however, it
means that we don't lock people into using large-vendor chipsets which have
unknown, or known to be bad, security properties such as Intel AMT.
In general, targeting open hardware seems to me to be more critical than
performance metrics for the long term health of Bitcoin, however,
performance is still important.
Does anyone know how the RISC-V FPGA performance stacks up to, say, a
Raspberry Pi?
On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <ogunden at phauna.org> wrote:
> I'm also a user who runs a full node, and I also like this idea. I think
> Gavin has done some back-of-the-envelope calculations around this stuff,
> but nothing so clearly defined as what you propose.
>
> On 07/02/2015 08:33 AM, Mistr Bigs wrote:
>
>> I'm an end user running a full node on an aging laptop.
>> I think this is a great suggestion! I'd love to know what system
>> requirements are needed for running Bitcoin Core.
>>
>> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
>> <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>> wrote:
>>
>> I’m a game developer. I write time critical code for a living and
>> have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
>> These budgets are based on what we call a minimum specification (of
>> hardware); min spec for short. In most cases the min spec is based
>> on entry model machines that are available during launch, and will
>> give the user an enjoyable experience when playing our games.
>> Obviously, we can turn on a number of bells and whistles for people
>> with faster machines, but that’s not the point of this mail.
>>
>> The point is, can we define a min spec for Bitcoin Core? The number
>> one reason for this is: if you know how your changes affect your
>> available budgets, then the risk of breaking something due to
>> capacity problems is reduced to practically zero.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
> 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/20150703/881fb610/attachment-0001.html>