> I should note that under Decker-Russell-Osuntokun the expectation is that
> both counterparties hold the same offchain transactions (hence why it is
> sometimes called "LN-symmetry").
> However, there are two ways to get around this:
>
> 1. Split the fee between them in some "fair" way.
>
Sent with Proton Mail secure email.
On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd
wrote:
> On Tue, Jan 30, 2024 at 04:12:07AM +, ZmnSCPxj wrote:
>
> > Peter Todd proposes to sign multiple versions of offchain transactions at
> > varying feerates.
> > However, this proposal
Good morning Michael et al,
>
> I assume that a CTV based LN-Symmetry also has this drawback when compared to
> an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry could
> change the fees in every channel update based on what the current market fee
> rate was at the time of
Good morning Antoine,
> Once the HTLC is committed on the Bob-Caroll link, Caroll releases the
> preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob
> does _not_ send back his signature for the updated channel state.
>
> Some blocks before 100, Caroll goes on-chain to
Hi all,
This was discussed partially on the platform formerly known as twitter, but an
alternate design goes like this:
* Add an `nExpiryTime` field in taproot annex.
* This indicates that the transaction MUST NOT exist in a block at or above
the height specified.
* Mempool should put txes
Good morning Greg,
> > I do not know if existing splice implementations actually perform such a
> > check.
> Unless all splice implementations do this, then any kind of batched splicing
> is risky.
> As long as the implementation decides to splice again at some point when a
> prior
> splice
Good morning Bastien,
I have not gotten around to posting it yet, but I have a write-up in my
computer with the title:
> Batched Splicing Considered Risky
The core of the risk is that if:
* I have no funds right now in a channel (e.g. the LSP allowed me to have 0
reserve, or this is a
Good morning Antoine et al.,
Let me try to rephrase the core of the attack.
There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==`
are channels):
A = B = C
`A` routes `A->B->C`.
The timelocks, for example, could be:
A->B timeelock = 144
B->C timelock
Good morning Robin et al,
It strikes me that it may be possible to Scriptless Script BitVM, replacing
hashes and preimages with points and scalars.
For example, equivocation of bit commitments could be done by having the prover
put a slashable fund behind a pubkey `P` (which is a point).
This
Good morning list,
I have been thinking further on this with regards to BitVM.
By my initial analyses, it seems that BitVM *cannot* be used to improve this
idea.
What we want is to be able to restrict the actuary to only signing for a
particular spend exactly once.
The mechanism proposed in
Good morning Antoine,
Does `OP_EVICT` not fit?
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, September 25th, 2023 at 6:18 PM, Antoine Riard via bitcoin-dev
Good morning Erik,
> > replacing CTV usage with Musig2
>
>
> this changes the trust model to a federated one vs trustless and also
> increases the on-chain footprint of failure, correct?
As I understand it, no.
MuSig and MuSig2 are n-of-n signing algorithms.
The implied usage is that all
Good morning John,
> On the other hand, if the consensus rules are changed to allow even simple
> covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can co-own an
> off-chain Lightning channel without having to sign all (or any) of the
Good morning Dave,
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, September 18th, 2023 at 12:12 AM, David A. Harding
wrote:
>
> On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
&
Good morning Antoine,
> Hi Zeeman
>
> > What we can do is to add the actuary to the contract that
> > controls the funds, but with the condition that the
> > actuary signature has a specific `R`.
>
> > As we know, `R` reuse --- creating a new signature for a
> > different message but the same
(N > 2) Multiparticipant Offchain Mechanisms
Introduction
The blockchain layer of Bitcoin provides an excellent non-interactivity:
users can go offline, then come online, synchronize, and broadcast
transactions to the mempool.
Always-online miners then get the transactions and add
Good morning Ryan, et al.,
My long-ago interest in sidechains was the hope that they would be a scaling
solution.
However, at some point I thought "the problem is that blockchains cannot scale,
sidechains means MORE blockchains that cannot scale, what was I thinking???"
This is why I turned my
Good morning Ryan,
> I appreciate your questions, ZmnSCPxj.
>
> I will answer your second question first: Mainchain nodes do not ever
> validate sidechain blocks. Sidechain nodes watch Bitcoin for invalid
> withdrawals, and publish signed attestations to a public broadcast network
> (such
Good morning Ryan,
If I modify your Sentinel Chain open-source software so that it is honest for
999 sidechain blocks, then lies and says that the 1000th block is invalid even
though it actually is, what happens?
Do mainchain nodes need to download the previous 999 sidechain blocks, run the
Good morning John Light,
> 2. Documentation about OP_RETURN says that OP_RETURN outputs are
> "provably-prunable".[2] A question I had about this was, are there any tools
> available that a full node operator could use to prune this data from their
> nodes?
As I understand it, `OP_RETURN`
Good morning Tom,
Would this allow party 2 to itself be composed of N >= 2 parties?
MuSig2 (as opposed to MuSig1) requires that signatories provide multiple `R`
points, not just one each, which are finally aggregated by first combining them
using the MuSig() public key compose function.
This
Here is an old write-up that should be read by everyone trying to design a
NON-custodial L2: https://zmnscpxj.github.io/offchain/safety.html
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, May 24th, 2023 at 12:40 AM, ZmnSCPxj via bitcoin-dev
wrote
Good morning Burak,
> > As the access to Lightning is also by the (same?) ASP, it seems to me that
> > the ASP will simply fail to forward the payment on the broader Lightning
> > network after it has replaced the in-mempool transaction, preventing
> > recipients from actually being able to
Good morning Burak,
I have not gone through the deep dive fully yet, but I find myself confused
about this particular claim:
> A pool transaction can be double-spent by the Ark service provider while it
> remains in the mempool. However, in the meantime, the recipient can pay a
> lightning
Good Morning Weiji,
> Hi ZmnSCPxy,
> > As the network is pseudonymous, an anonymous attacker can flood the
> > fullnode mempool network with large numbers of non-aggregated transactions,
> > then in cooperation with a miner confirm a single aggregated transaction
> > with lower feerate than
Good morning Weiji,
The issue here is that non-aggregated transaction are a potential attack vector.
As the network is pseudonymous, an anonymous attacker can flood the fullnode
mempool network with large numbers of non-aggregated transactions, then in
cooperation with a miner confirm a single
Good morning Weiji,
> Meanwhile, as we can potentially aggregate many proofs or recursively verify
> even more, the average cost might still be manageable.
Are miners supposed to do this aggregation?
If miners do this aggregation, then that implies that all fullnodes must also
perform the
Good morning Weiji,
Have not completed reading, but this jumped out to me:
> 3. Dealing with system limitation: verification keys could be very long and
> exceed the MAX_SCRIPT_ELEMENT_SIZE (520 bytes). They could be put into
> configurations and only use their hash in the scriptPubKey. The
Good morning John, et al,
> > As has been pointed out by may others before, full RBF is aligned with
> > miner (and user) economic incentives
>
>
> This is a theory, not a fact. I can refute this theory by pointing out
> several aspects:
> 1. RBF is actually a fee-minimization feature that
Good morning Andrew,
>
>
> Can output amounts be mapped to a tap branch? For the goal of secure partial
> spends of a single UTXO? Looking for feedback on this idea. I got it from
> Taro.
Not at all.
The issue you are facing here is that only one tap branch will ever consume the
entire
Good morning ArmchairCryptologist,
> --- Original Message ---
> On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > I mean, if you think the feedback is wrong, that's different: maybe we
> > shouldn't care that
Good morning Salvatore,
Interesting idea.
The idea to embed the current state is similar to something I have been musing
about recently.
> ### Game theory (or why the chain will not see any of this)
>
> With the right economic incentives, protocol designers can guarantee that
> playing a
Good morning Trey,
> * something like OP_PUSHSCRIPT which would remove the need for the
> introspection the the prevout's script and avoids duplicating data in
> the witness
> * some kind of OP_MERKLEUPDATEVERIFY which checks a merkle proof for a
> leaf against a root and checks if replacing the
Good morning Mark,
> The idea is simple: instead of requiring that the final parameter on the
> stack be zero, require instead that it be a minimally-encoded bitmap
> specifying which keys are used, or alternatively, which are not used and must
> therefore be skipped. Before attempting
Good morning Jeremy,
Excellent work!
> # Terminal States / Thresholds
>
> When a counter reaches the Nth state, it represents a certain amount
> of accumulated work over a period where progress was agreed on for
> some outcome.
>
> There should be some viable state transition at this point.
Good morning Ali,
> Over the past few days I've figured out a novel way to batch transactions
> together into blocks, thereby compacting the transaction size and increasing
> the transactions-per-second. This is all on layer 1, without any hardforks -
> only a single softfork is required to
Good morning Greg,
> Hi James,
> Could you elaborate on a L2 contract where speedy
> settlement of the "first part" can be done, while having the rest
> take their time? I'm more thinking about time-out based protocols.
>
> Naturally my mind drifts to LN, where getting the proper commitment
>
Good morning alia, Antoine, and list,
> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology in
> bitcoin development, is just too much. Bitcoin development methodology is an
> open problem, given the contemporary escalation/emergence of challenges,
> history is
Good morning Ruben,
> Good evening ZmnSCPxj,
> Interesting attempt.
>
> >a * G + b * G + k * G
>
> Unfortunately I don't think this qualifies as a commitment, since one could
> trivially open the "commitment" to some uncommitted value x (e.g. a is set to
> x and b is set to a+b-x). Perhaps
Good morning Ruben and Veleslav,
> Hi Veleslav,
>
> This is something I've been interested in.
>
>
> What you need is a basic merkle sum tree (not sparse), so if e.g. you want to
> burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you can
> burn 100 sats and commit to a tree
Good morning e, and list,
> Yet you posted several links which made that specific correlation, to which I
> was responding.
>
> Math cannot prove how much coin is “lost”, and even if it was provable that
> the amount of coin lost converges to the amount produced, it is of no
> consequence -
Good morning vjudeu,
> Some people think that sidechains are good. But to put them into some working
> solution, people think that some kind of soft-fork is needed. However, it
> seems that it can be done in a no-fork way, here is how to make it
> permissionless, and introduce them without
Good morning fd0,
> > In addition, covenant mechanisms that require large witness data are
> > probably more vulnerable to MEV.
>
>
> Which covenant mechanisms require large witness data?
`OP_CSFS` + `OP_CAT`, which requires that you copy parts of the transaction
into the witness data if you
Good morning fd0,
> MEV could be one the issues associated with general covenants. There are some
> resources on https://mev.day if anyone interested to read more about it.
> 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g.
> sandwiched13:07 <@jeremyrubin> so given that
Good morning e,
> Good evening ZmnSCPxj,
>
> Sorry for the long delay...
Thank you very much for responding.
>
> > Good morning e,
> >
> > > Good evening ZmnSCPxj,
> > >
> > > For the sake of simplicity, I'll use the terms lender (Landlord), borrower
> > > (Lessor), interest (X), principal
Good morning Chris,
> I don't know yet exactly the details of how such a scheme would work,
> maybe something like each fidelity bond owner creates a key in the
> multisig scheme, and transaction fees from the sidechain or ecash server
> are divided amongst the fidelity bonds in proportion to
Good morning Chris,
> Yes linking the two identities (joinmarket maker and teleport maker)
> together slightly degrades privacy, but that has to be balanced against
> the privacy loss of leaving both systems open to sybil attacks. Without
> fidelity bonds the two systems can be sybil attacked
Good morning Chris,
> Hello waxwing,
>
> > A user sacrifices X amount of time-value-of-money (henceforth TVOM)
>
> by committing in Joinmarket with FB1. He then uses the same FB1 in
> Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket,
> and benefit Z in Teleport, then
Good morning Jorge,
> I fail to understand why non recursive covenants are called covenants at all.
> Probably I'm missing something, but I guess that's another topic.
A covenant simply promises that something will happen in the future.
A recursive covenant guarantees that the same thing will
Good morning Russell,
> On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev
> wrote:
>
> > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE
> > OR NOT.
>
>
> I think the state of the art has advanced to the point where we can say
Good morning vjudeu,
> > Looks like `OP_CAT` is not getting enabled until after we are reasonably
> > sure that recursive covenants are not really unsafe.
>
> Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT.
> Then, we could have OP_SPLIT... that would split a
>
Good morning waxwing,
> --- Original Message ---
> On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hello ZmnSCPxj,
> > This is an intended feature. I'm thinking that the same fidelity bond
> > can be used to running a
Good morning Billy,
> Very interesting exploration. I think you're right that there are issues with
> the kind of partitioning you're talking about. Lightning works because all
> participants sign all offchain states (barring data loss). If a participant
> can be excluded from needing to
Good morning shesek,
> On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev
> wrote:
> > * Even ***with*** `OP_CAT`, the following will enable non-recursive
> > covenants without enabling recursive covenants:
> > * `OP_CTV`, ...
> > * With `OP_CAT`, the fo
Good morning Jorge,
> I think people may be scared of potential attacks based on covenants. For
> example, visacoin.
> But there was a thread with ideas of possible attacks based on covenants.
> To me the most scary one is visacoin, specially seeing what happened in
> canada and other places
Good morning Jorge,
> Thanks again.
> I won't ask anything else about bitcoin, I guess, since it seems my questions
> are too "misinforming" for the list.
> I also agreed with vjudeu, also too much misinformation on my part to agree
> with him, it seems.
> I mean, I say that because it doesn't
Good morning Jorge,
> Thanks a lot for the many clarifications.
> Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things.
> I guess this wouldn't be a covenants proposal then.
> But simplicity would enable covenants too indeed, no?
> Or did I get that wrong too?
Yes, it
Good morning Jorge,
> OP_CAT was removed. If I remember correctly, some speculated that perhaps it
> was removed because it could allow covenants.I don't remember any technical
> concern about the OP besides enabling covenants.Before it was a common
> opinion that covenants shouldn't be
Good morning e,
> Good evening ZmnSCPxj,
>
> For the sake of simplicity, I'll use the terms lender (Landlord), borrower
> (Lessor), interest (X), principal (Y), period (N) and maturity (height after
> N).
>
> The lender in your scenario "provides use" of the principal, and is paid
> interest
Good morning e,
> It looks like you are talking about lending where the principal return is
> guaranteed by covenant at maturity. This make the net present value of the
> loan zero.
I am talking about lending where:
* Lessor pays landlord X satoshis in rent.
* Landlord provides use of the
Good morning vjudeu,
> Typical P2PK looks like that: " OP_CHECKSIG". In a
> typical scenario, we have "" in out input and "
> OP_CHECKSIG" in our output. I wonder if it is possible to use covenants right
> here and right now, with no consensus changes, just by requiring a specific
>
Good morning Chris,
> Hello ZmnSCPxj,
>
> Renting out fidelity bonds is an interesting idea. It might happen in
> the situation where a hodler wants to generate yield but doesn't want
> the hassle of running a full node and yield generator. A big downside of
> it is that the yield generator
Good morning again Chris,
I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I
am interested in application A, you are interested in application B, and you
rent my fidelity bond for application B.
We can use a pay-for-signature protocol now that Taproot is available, so
Good morning Chris,
Excellent BIP!
>From a quick read-over, it seems to me that the fidelity bond does not commit
>to any particular scheme or application.
This means (as I understand it) that the same fidelity bond can be used to
prove existence across multiple applications.
I am uncertain
Good morning Billy,
> @Zman
> > if two people are perfectly rational and start from the same information,
> > they *will* agree
> I take issue with this. I view the word "rational" to mean basically logical.
> Someone is rational if they advocate for things that are best for them. Two
> humans
Good morning Keagan, et al,
> I think there are a few questions surrounding the issue of soft fork
> activation. Perhaps it warrants zooming out beyond even what my proposal aims
> to solve. In my mind the most important questions surrounding this process
> are:
>
> 1. In an ideal world,
Good morning Zac,
> On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj wrote
>
> > CTV *can* benefit layer 2 users, which is why I switched from vaguely
> > apathetic to CTV, to vaguely supportive of it.
>
>
> Other proposals exist that also benefit L2 solutions. What makes you support
> CTV specifically?
Good morning Peter,
>
> On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > I like the maxim of Peter Todd: any change of Bitcoin must benefit all
> > users. This means that every change must have well-defined and
Good morning Dave, et al.,
I have not read through *all* the mail on this thread, but have read a fair
amount of it.
I think the main argument *for* this particular idea is that "it allows the use
of real-world non-toy funds to prove that this feature is something actual
users demand".
An
Good morning vjudeu,
> When I see more and more proposals like this, where things are commited to
> Taproot outputs, then I think we should start designing "miner-based
> commitments". If someone is going to make a Bitcoin transaction and add a
> commitment for zero cost, just by tweaking some
Good morning aj,
> On Tue, Mar 22, 2022 at 05:37:03AM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
>
> (Have you considered applying a jit or some other compression algorithm
> to your emails?)
>
&
Good morning again Russell,
> Good morning Russell,
>
> > Thanks for the clarification.
> > You don't think referring to the microcode via its hash, effectively using
> > 32-byte encoding of opcodes, is still rather long winded?
For that matter, since an entire microcode represents a language
Good morning Russell,
> Thanks for the clarification.
>
> You don't think referring to the microcode via its hash, effectively using
> 32-byte encoding of opcodes, is still rather long winded?
A microcode is a *mapping* of `OP_` codes to a variable-length sequence of
`UOP_` micro-opcodes.
So a
Good morning Russell,
> Setting aside my thoughts that something like Simplicity would make a better
> platform than Bitcoin Script (due to expression operating on a more narrow
> interface than the entire stack (I'm looking at you OP_DEPTH)) there is an
> issue with namespace management.
>
>
Good morning list,
It is entirely possible that I have gotten into the deep end and am now
drowning in insanity, but here goes
Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
Introduction
Recent (Early 2022) discussions on the bitcoin-dev mailing
Good morning Billy,
> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a
> coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like support:10%}>
Good morning Antoine,
> For "hot contracts" a signature challenge is used to achieve the same. I know
> the latter is imperfect, since
> the lower the uptime risk (increase the number of network monitors) the
> higher the DOS risk (as you duplicate
> the key).. That's why i asked if anybody had
Good morning Billy,
> > I think we would want to have a cleanstack rule at some point
>
> Ah is this a rule where a script shouldn't validate if more than just a true
> is left on the stack? I can see how that would prevent the non-soft-fork
> version of what I'm proposing.
Yes.
There was
Good morning Bram,
> On Wed, Mar 9, 2022 at 6:30 AM ZmnSCPxj wrote:
>
> > I am pointing out that:
> >
> > * We want to save bytes by having multiple inputs of a transaction use the
> > same single signature (i.e. sigagg).
> >
> > is not much different from:
> >
> > * We want to save bytes by
Good morning aj et al.,
> On Tue, Mar 08, 2022 at 03:06:43AM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > > > They're radically different approaches and
> > > > it's hard to see how they mix. Everything in lisp is completely
> > > > sandboxed,
> >
Good morning Billy,
> Hi ZmnSCPxj,
>
> > Just ask a bunch of fullnodes to add this 1Mb of extra ignored data in
> >this tiny 1-input-1-output transaction so I pay only a small fee
>
> I'm not suggesting that you wouldn't have to pay a fee for it. You'd pay a
> fee for it as normal, so there's
Good morning Jorge,
> What is ST? If it may be a reason to oppose CTV, why not talk about it more
> explicitly so that others can understand the criticisms?
ST is Speedy Trial.
Basically, a short softfork attempt with `lockinontimeout=false` is first done.
If this fails, then developers stop
Good morning Bram,
> On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj wrote:
>
> > But cross-input signature aggregation is a nice-to-have we want for
> > Bitcoin, and, to me, cross-input sigagg is not much different from
> > cross-input puzzle/solution compression.
>
> Cross-input signature
Good morning aj et al.,
> > They're radically different approaches and
> > it's hard to see how they mix. Everything in lisp is completely sandboxed,
> > and that functionality is important to a lot of things, and it's really
> > normal to be given a reveal of a scriptpubkey and be able to rely
Good morning Antoine,
> Hi James,
>
> Interesting to see a sketch of a CTV-based vault design !
>
> I think the main concern I have with any hashchain-based vault design is the
> immutability of the flow paths once the funds are locked to the root vault
> UTXO. By immutability, I mean there is
Good morning Billy,
Changed subject since this is only tangentially related to `OP_FOLD`.
> Let me organize my thoughts on this a little more clearly. There's a couple
> possibilities I can think of for a jet-like system:
>
> A. We could implement jets now without a consensus change, and
Good morning Bram,
> while in the coin set model each puzzle (scriptpubkey) gets run and either
> assert fails or returns a list of extra conditions it has, possibly including
> timelocks and creating new coins, paying fees, and other things.
Does this mean it basically gets recursive
Good morning Billy,
> Even changing the weight of a transaction using jets (ie making a script
> weigh less if it uses a jet) could be done in a similar way to how segwit
> separated the witness out.
The way we did this in SegWit was to *hide* the witness from unupgraded nodes,
who are then
Good morning Chris,
> >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".
>
> I think something that is underappreciated by protocol developers is the fact
> that multisig requires
Good morning Russell,
> On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev
> wrote:
>
> > It seems like a decent concept for exploration.
> >
> > AJ, I'd be interested to know what you've been able to build with Chia Lisp
> > and what your experience has been... e.g. what does the
Good morning Billy,
> It sounds like the primary benefit of op_fold is bandwidth savings.
> Programming as compression. But as you mentioned, any common script could be
> implemented as a Simplicity jet. In a world where Bitcoin implements jets,
> op_fold would really only be useful for
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
Good morning Jeremy,
Umm `OP_ANNEX` seems boring
> 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:
>
>
Good morning aj,
> On Sun, Feb 27, 2022 at 04:34:31PM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > In reaction to this, AJ Towns mailed me privately about some of his
> > thoughts on this insane `OP_EVICT` proposal.
> > He observed that we could generali
Good morning vjudeu,
> > Continuous operation of the sidechain then implies a constant stream of
> > 32-byte commitments, whereas continuous operation of a channel factory, in
> > the absence of membership set changes, has 0 bytes per block being
> > published.
>
> The sidechain can push zero
Good morning Chris,
Quick question.
How does this improve over just handing over `nLockTime`d transactions?
Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
Good morning Paul,
> On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
>
> > ...
> >
> > > Such a technique would need to meet two requirements (or, so it seems to
> > > me):
> > > #1: The layer1 UTXO (that defines the channel) can never change (ie, the
> > > 32-bytes which define the
`OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
=
(This writeup requires at least some programming background, which I
expect most readers of this list have.)
Recently, some rando was ranting on the list about this weird crap
called `OP_EVICT`, a
Good morning again Paul,
> With sidechains, changing the ownership set requires that the sidechain
> produce a block.
> That block requires a 32-byte commitment in the coinbase.
> What is more, if any transfers occur on the sidechain, they cannot be real
> without a sidechain block, that has to
Good morning Paul,
> ***
>
> You have emphasized the following relation: "you have to show your
> transaction to everyone" = "thing doesn't scale".
>
> However, in LN, there is one transaction which you must, in fact, "show to
> everyone": your channel-opener.
>
> Amusingly, in the largeblock
1 - 100 of 568 matches
Mail list logo
