Re: [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.

2022-11-21 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-11-10 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Merkleize All The Things

2022-11-08 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Validity Rollups on Bitcoin

2022-11-04 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Batch validation of CHECKMULTISIG using an extra hint field

2022-10-20 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Spookchains: Drivechain Analog with One-Time Trusted Setup & APO

2022-09-19 Thread ZmnSCPxj via bitcoin-dev
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.

Re: [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1

2022-09-04 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] More uses for CTV

2022-08-19 Thread ZmnSCPxj via bitcoin-dev
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 >

Re: [bitcoin-dev] On a new community process to specify covenants

2022-07-24 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] How to do Proof of Micro-Burn?

2022-07-19 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] How to do Proof of Micro-Burn?

2022-07-17 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-09 Thread ZmnSCPxj via bitcoin-dev
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 -

Re: [bitcoin-dev] Using Merged Mining on a separate zero supply chain, instead of sidechains

2022-06-05 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

2022-05-20 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

2022-05-19 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-18 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Improving chaumian ecash and sidechains with fidelity bond federations

2022-05-16 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-15 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-13 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

2022-05-12 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-11 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-11 Thread ZmnSCPxj via bitcoin-dev
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 >

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-10 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

2022-05-10 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

2022-05-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

2022-05-06 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-03 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-03 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Pay to signature hash as a covenant

2022-05-03 Thread ZmnSCPxj via bitcoin-dev
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 >

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-02 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-01 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

2022-05-01 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-04-30 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-04-27 Thread ZmnSCPxj via bitcoin-dev
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,

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-25 Thread ZmnSCPxj via bitcoin-dev
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?

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-24 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

2022-04-24 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

2022-04-05 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

2022-03-22 Thread ZmnSCPxj via bitcoin-dev
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?) > &

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

2022-03-22 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

2022-03-22 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

2022-03-22 Thread ZmnSCPxj via bitcoin-dev
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. > >

[bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

2022-03-21 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Speedy Trial

2022-03-18 Thread ZmnSCPxj via bitcoin-dev
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%}>

Re: [bitcoin-dev] Covenants and feebumping

2022-03-16 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT)

2022-03-16 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-16 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-16 Thread ZmnSCPxj via bitcoin-dev
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, > >

Re: [bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT)

2022-03-09 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

2022-03-09 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-09 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] CTV vaults in the wild

2022-03-07 Thread ZmnSCPxj via bitcoin-dev
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

[bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT)

2022-03-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-07 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT

2022-03-06 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

2022-03-06 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-05 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT

2022-03-05 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

2022-03-05 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

2022-03-04 Thread ZmnSCPxj via bitcoin-dev
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: > >

Re: [bitcoin-dev] bitcoin scripting and lisp

2022-03-04 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-03-04 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

2022-03-04 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-27 Thread ZmnSCPxj via bitcoin-dev
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

[bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT

2022-02-27 Thread ZmnSCPxj via bitcoin-dev
`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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-26 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-26 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

2022-02-25 Thread ZmnSCPxj via bitcoin-dev
Good morning Paul, > I don't think I can stop people from being ignorant about Drivechain. But I > can at least allow the Drivechain-knowledgable to identify each other. > > So here below, I present a little "quiz". If you can answer all of these > questions, then you basically understand

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-25 Thread ZmnSCPxj via bitcoin-dev
Good morning AJ, > ZmnSCPaj, are you arguing that drivechains are bad for bitcoin or are you > arguing that it would be unwise to opt into a drivechain? Those are very > different arguments. If drivechains compromised things for normal bitcoin > nodes that ignore drivechains, then I agree that

Re: [bitcoin-dev] OP_RETURN inside TapScript

2022-02-25 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Hi ZmnSCPxj, > > To me it seems that more space can be saved. > > The data-“transaction” need not specify any output. The network could > subtract the fee amount of the transaction directly from the specified UTXO. That is not how UTXO systems like Bitcoin work. Either you

Re: [bitcoin-dev] OP_RETURN inside TapScript

2022-02-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Hi ZmnSCPxj, > > Any benefits of my proposal depend on my presumption that using a standard > transaction for storing data must be inefficient. Presumably a transaction > takes up significantly more on-chain space than the data it carries within > its OP_RETURN. Therefore,

Re: [bitcoin-dev] OP_RETURN inside TapScript

2022-02-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Reducing the footprint of storing data on-chain might better be achieved by > *supporting* it. > > Currently storing data is wasteful because it is embedded inside an OP_RETURN > within a transaction structure. As an alternative, by supporting storing of > raw data without

[bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

2022-02-24 Thread ZmnSCPxj via bitcoin-dev
Good morning lightning-dev and bitcoin-dev, Recently, some dumb idiot, desperate to prove that recursive covenants are somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caused Paul Sztorc to [revive][1] and make the following statement: > As is well known, it is easy for

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-24 Thread ZmnSCPxj via bitcoin-dev
Good morning aj, > > Logically, if the construct is general enough to form Drivechains, and > > we rejected Drivechains, we should also reject the general construct. > > Not providing X because it can only be used for E, may generalise to not > providing Y which can also only be used for E, but

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Paul, welcome back, and the list, For the most part I am reluctant to add Turing-completeness due to the Principle of Least Power. We saw this play out on the web browser technology. A full Turing-complete language was included fairly early in a popular HTML implementation,

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine, > TLUV doesn't assume cooperation among the construction participants once the > Taproot tree is setup. EVICT assumes cooperation among the remaining > construction participants to satisfy the final CHECKSIG. > > So that would be a feature difference between TLUV and

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-23 Thread ZmnSCPxj via bitcoin-dev
Subject: Turing-Completeness, And Its Enablement Of Drivechains Introduction Recently, David Harding challenged those opposed to recursive covenants for *actual*, *concrete* reasons why recursive covenants are a Bad Thing (TM). Generally, it is accepted that recursive covenants,

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-02-21 Thread ZmnSCPxj via bitcoin-dev
> Good morning Prayank, > > (offlist) My apologies. I pushed the wrong button, I should have pressed "Reply" and not "Reply All". Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-02-21 Thread ZmnSCPxj via bitcoin-dev
Good morning, > If this is the reason to stop/delay improvements in bitcoin, maybe it applies > for Taproot as well although I don't remember reading such things in your > posts or maybe missed it. Perhaps a thing to note, is that if it allows us to move some activity off-chain, and reduce

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

2022-02-21 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, (offlist) > Satoshi I object to the invocation of Satoshi here, and in general. If Satoshi wants to participate in Bitcoin development today, he can speak for himself. If Satoshi refuses to participate in Bitcoin development today, who cares what his opinion is? Satoshi

Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

2022-02-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > opt-in or explicit tagging of fee account is a bad design IMO. > > As pointed out by James O'Beirne in the other email, having an explicit key > required means you have to pre-plan suppose you're building a vault meant > to distribute funds over many years, do you

Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

2022-02-20 Thread ZmnSCPxj via bitcoin-dev
Good morning DA, > Agreed, you cannot rely on a replacement transaction would somehow > invalidate a previous version of it, it has been spoken into the gossip > and exists there in mempools somewhere if it does, there is no guarantee > that anyone has ever heard of the replacement transaction

Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

2022-02-19 Thread ZmnSCPxj via bitcoin-dev
Good morning Peter and Jeremy, > Good morning Peter and Jeremy, > > > On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote: > > > > > > Necromancing might be a reasonable name for attacks that work by > > > > getting an > > > > out-of-date version of a tx mined. > > > > > > It's not an

Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts

2022-02-19 Thread ZmnSCPxj via bitcoin-dev
Good morning Peter and Jeremy, > On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote: > > > > Necromancing might be a reasonable name for attacks that work by getting > > > an > > > out-of-date version of a tx mined. > > > > It's not an "attack"? There is no such thing as an out-of-date

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-19 Thread ZmnSCPxj via bitcoin-dev
Good morning Billy, > > "fully" punitive channels also make large value channels more dangerous > >from the perspective of bugs causing old states to be published > > Wouldn't it be ideal to have the penalty be to pay for a single extra > transaction fee? That way there is a penalty so cheating

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > 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

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Erik, > > As I understand your counterproposal, it would require publishing one > > transaction per evicted participant. > > if you also pre-sign (N-2, N-3, etc), you can avoid this It also increases the combinatorial explosion. > > In addition, each participant has to store `N!`

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Erik, > hey, i read that whole thing, but i'm confused as to why it's necessary > > seems like N of N participants can pre-sign an on-chain transfer of funds for > each participant to a new address that consists of (N-1) or (N-1) > participants, of which each portion of the

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave, > On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote: > > > Whether [recursive covenants] is an issue or not precluding this sort > > of design or not, I defer to others. > > For reference, I believe the last time the merits of allowing recursive >

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
Good morning shymaa, > I just want to add an alarming info to this thread... > > There are at least 5.7m UTXOs≤1000 Sat (~7%),  > 8.04 m ≤1$ (10%),  > 13.5m ≤ 0.0001BTC (17%) > > It seems that bitInfoCharts took my enquiry seriously and added a main link > for dust analysis: >

[bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-17 Thread ZmnSCPxj via bitcoin-dev
`OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` == In late 2021, `aj` proposed `OP_TAPLEAFUPDATEVERIFY` in order to implement CoinPools and similar constructions. `Jeremy` observed that due to the use of Merkle tree paths, an `OP_TLUV`

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

2021-12-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > Another interesting point: if you use a musig key for your staking key that > is musig(a,b,c) you can sign with a until you equivocate once, then switch to > b, then c. Three strikes and you're out! IDK what that could be used for. You could say "oops, I made a mistake,

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains

2021-12-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > Today's post is pretty cool: it details how covenants like CTV can be used to > improve on-chain bitcoin signing oracles by solving the timeout/rollover > issue and solving the miner/oracle collusion issue on punishment. This issue > is similar to the Blockstream Liquid

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

2021-12-08 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > > ## Why would a "Smart" contract be "Smart"? > > > > A "smart" contract is simply one that somehow self-enforces rather than > > requires a third party to enforce it. > > It is "smart" because its execution is done automatically. > > There are no automatic executing

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

2021-12-07 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > > Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the > topic is why smart contracts (in extended form) may be a critical precursor > to securing Bitcoin's future rather than something we should do after making > the base layer more robust. *This*

  1   2   3   4   5   6   >