Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys

ies on the spend, but this is obviously >*very* suboptimal. > > > Both issues are solvable with covenants. > > Antoine Poinsot > ------- Original Message --- > Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation

[bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys

In the discussion around James' OP_VAULT proposal, it was implied that precomputed vaults must use ephemeral keys that must be deleted as part of the vaulting protocol, like Bryan Bishop's proposal . Looking around, I

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

>> It would usually be prudent to store this recovery address with every key to the vault, ... > Worth noting now that in OP_VAULT the recovery path can be optionally gated by an arbitrary scriptPubKey. Gating by a scriptPubKey solves the problem I was talking about there. However, thinking about

Re: [bitcoin-dev] Using OP_VAULT to improve DLCs

That's an interesting mechanism. Since the goal of OP_VAULT was to avoid being another general covenant proposal, that avenue could be blocked by requiring that for a transaction spending a utxo with a script using OP_UNVAULT, the script (or taproot tree) must *only* contain that one opcode call

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

I like the proposal of a targeted wallet vault opcode. It keeps things constrained, limiting objections to those of the form "but if we had X it would do all this and more so why add this complexity when it will be obsoleted in the future?" > An idealized vault > no existing vault design meets

Re: [bitcoin-dev] Pseudocode for robust tail emission

> In Bitcoin "the show must go on" and someone must pay for it. Active [and/or] passive users I certainly agree. > or more precisely: tiny inflation  > Right now security comes from almost fully from ~1.8% inflation. Best I could find, fees make up about 13% of miner revenue

Re: [bitcoin-dev] Pseudocode for robust tail emission

> is surely better than not delaying it. I might agree, but I don't think it really solves the problem well enough to be worth it. Any solution that would solve the problem better would make delaying halvings unnecessary. > there is non-zero risk that people will hoard it more and more,

Re: [bitcoin-dev] Pseudocode for robust tail emission

If the idea is to ensure that a catastrophic miner exodus doesn't happen, the "difference" you're calculating should only care about downward differences. Upward differences indicate more mining activity and so shouldn't cause a halving skip. But I don't think any scheme like this that only acts

Re: [bitcoin-dev] Merkleize All The Things

Re Verkle trees, that's a very interesting construction that would be super useful as a tool for something like Utreexo. A potentially substantial downside is that it seems the cryptography used to get those nice properties of Verkle trees isn't quantum safe

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

I think it might be a good idea to record something that can directly connect the list of labels with the correct wallet. Imagine someone backs up a bunch of label files and then forgets which wallet they apply to. Sure you could probably look through the list of transactions, addresses, etc and

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

@Ali Thats some good well thought through and well articulated feedback. I have one point of contention > it's important that unnecessary types are kept out of the format. People are known to leave files lying around on their computer that they don't need anymore, so these files can find their

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

> I would like to note it's real work for the organizers in terms of time and energy: finding a common date making consensus, an acceptable host country (i.e respecting the travel policy of the widest... I was actually not thinking one large central in-person meeting, but many smaller

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

@vjudeu > Miners can game this system by moving their own coins in 100% fees transactions, just to produce more coins. You have one million BTC? No problem, just move them as fees, and you just created 100k BTC out of thin air, just because you are a wealthy miner. Hmm, I believe you're right

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

While constant tail emission does in fact converge to 0 inflation over time (which bitcoin's halvings do as well mind you), tail emission does *not* solve the potential problem of mining rewards, it only delays it. A tail emission of 200,000 btc/year (~1% of the current supply) would be equivalent

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

I agree with Peter, it seems like we don't need a dust limit with full blocks. And we should expect blocks to remain full indefinitely. However, if we were to still have a dust limit, it shouldn't be a simple constant. It should be determined by the mempool environment. Eg one could define the

Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor

@Dmitry > various software might start to use extra indexes in a tuple for their own non-standard purposes This will be true regardless of whether the spec allows or doesn't allow tuples of length more than 2. In fact, any other tuple other than <1;2> will be nonstandard. We can't prevent people

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

@Antoine I very much like your proposal of an open decentralized process for investigating the problem and solution spaces. IRC sounds like a reasonable place for this kind of thing to happen. I also agree with Ryan Grant's comment about in-person cut-through (ie cut through the BS and resolve

Re: [bitcoin-dev] Bitcoin covenants are inevitable

@Peter Todd > The fact of the matter is that the present amount of security is about 1.7% of the total coin supply/year That's on the order of what I calculated : ~0.5%. I'm curious

Re: [bitcoin-dev] Bitcoin covenants are inevitable

@vjudeu > better to allow transaction joining.. to make fees more smoothly I'm not familiar with RSK transaction joining. However, I don't think this addresses the issues Corey brought up - which is that the appropriate amount of security (ie miner revenue) isn't linked with any bitcoin market

Re: [bitcoin-dev] Bitcoin covenants are inevitable

@Corey > Currently there is zero feedback in the Bitcoin system between what we might think is the optimum amount of security and what actually exists. I basically agree with this. The pedantic part of my mind does want to point out that the link between block subsidy and bitcoin's price does

Re: [bitcoin-dev] Bitcoin covenants are inevitable

to enact that ideal. On Wed, Jun 29, 2022 at 3:44 AM Kate Salazar < mercedes.catherine.sala...@gmail.com> wrote: > Hey > > On Tue, Jun 28, 2022 at 10:43 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> @Eric >> > Peo

Re: [bitcoin-dev] Bitcoin covenants are inevitable

@Eric > People who transact are realizing the benefit of money - the avoidance of barter costs. I'm very confident you're incorrect that holders don't receive any benefit and you're certainly not correct that every spend is receiving the same benefit. As I'm sure you're aware, one of the primary

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4

> two aspects to consensus Well, consensus isn't just one thing with two aspects. There are many things one might ask for consensus about, and many groups you might ask for it from. There's miner consensus about transaction ordering, miner consensus about soft fork signaling, developer

Re: [bitcoin-dev] Bitcoin covenants are inevitable

n't include alicexbt or yourself as a "technical folk", do you? > > > On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Wholeheartedly agree with you alicexbt. There are no technical issues >> t

Re: [bitcoin-dev] Bitcoin covenants are inevitable

Wholeheartedly agree with you alicexbt. There are no technical issues that have been shown that I'm aware of. Once the non-technical folks have time to discuss it and realize that, I'm hopeful things will move forward. Perhaps we can learn from this and figure out how to better catch the attention

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4

That sounds like an interesting mechanism to help measure consensus - and a good way to do that would help bitcoin significantly I think. I don't quite see what the similarity is between Trust Metric and bitcoin tho. How would you propose "building it into" bitcoin? >From my limited searching, it

[bitcoin-dev] Soliciting more discussion for OP_CONSTRAINDESTINATION (a covenant opcode)

Hi all, Since there's recently been a lot more interest in discussing covenants and alternative covenant proposals because of CTV, I figured I'd bring up my own proposed covenant opcode again while the urge is still fresh. To be clear upfront, this opcode has a spec, but nothing else. No tests.

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

@alicexbt > I think 'support' and 'opposition' can be replaced with readiness. Miners should not consider signaling as voting. I agree that it isn't voting, its signaling. But whether or not you call it 'readiness' or 'support', some miners will use it to signal 'support' and will refuse to

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

@Antoine > it's also hard to predict in advance the liquidity needs of the sub-pools. Definitely. Better than not being able to use the pool at all when someone's offline tho. > this fan-out transaction could interfere with the confirmation of the simple withdraw transactions > So there is an

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

@Jorge & Zmn > A recursive covenant guarantees that the same thing will happen in the future. Just a clarification: a recursive covenant does not necessarily guarantee any particular thing will happen in the future. Both recursives and a non-recursive covenant opcodes *can* be used to guarantee

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

I think this is a useful proposal. There are certainly things about BIP9 that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but a BIP spec was never produced for it afaik. A possibly unhelpful comment: > minimum_activation_height I think a minor improvement would be to

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

Unless governments can mandate > that you generate these addresses AND force you to accept funds bound by > them for your services**, I don't actually see how this is a real concern. > > *This requires good wallet tooling and standards but that isn't materially > different than w

Re: [bitcoin-dev] Wallet policies for descriptor wallets

I took a look at the spec for the wallet descriptor format, and I like the concept of having placeholder variables for keys. It reduces the size of the descriptor, makes it substantially easier for a human to read/verify, especially in the future when we have more complex scripts, and provides a

Re: [bitcoin-dev] Working Towards Consensus

> it is easier to get everyone to agree when everyone has something to gain That's unquestionably true. It doesn't really sound like what you said originally tho. > most users are either apathetic or trusting in the developers that initiated it being activated. This is a dangerous dynamic to

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

> This requires *recursive* covenants. Actually, for practical use, any walled-garden requires *dynamic* covenants, not recursive covenants. CTV can get arbitrarily close to recursive covenants, because you can have an arbitrarily long string of covenants. But this doesn't help someone implement

Re: [bitcoin-dev] Working Towards Consensus

John, > The path to consensus is to propose things that everyone needs. If there's an insight here, it isn't clear what it is to me. As stated, this is something I can only 100% disagree with. Its possible that literally nothing about bitcoin is something that "everyone needs". Its pretty clear

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

> If a QC is able overnight to spend a large fraction of the supply, your coins in your super non-QC vulnerable-bare-CTV-covenant (that would eventually become vulnerable when trying to use it) are worthless.[1] I know this has been debated to death, but I really don't think this argument is

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

Hi Antoine, 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 agree to a new state,

Re: [bitcoin-dev] Multiple ways to do bitcoin covenants

I've been thinking about writing something about covenant proposals from the viewpoint of wallet vaults specifically (mostly because that's the use case I care most about). CTV is basically the minimal covenant opcode you can do that doesn't have malleability. Everything else either introduces

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

> if you are perfectly rational, you can certainly imagine a "what if" where your goal is different from your current goal and figure out what you would do ***if*** that were your goal instead. I see what you're saying, and I'm a lot more on board with that. I still think "rational" can't mean

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

+1 alicexbt We of course want knowledgeable bitcoiners who aren't knowledgeable about a certain proposal to be skeptical. But what we don't want is for that natural skepticism-from-ignorance to be interpreted as opposition, or really a strong signal of any kind. Any thoughts from ignorance,

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

(which can even be hot on your phone etc). > > Both approaches are valid, one gets you more security while the other gets > you more convenience. And there is of course a whole range of options that > can be chosen in between that gets you some of both. > > shesek > >

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

@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 are not the same people. They have

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

@Keagan > we have to have a way (formalized or not) of deciding when the "lesser experts" in aggregate have better judgement. I agree. Its certainly convenient for development speed to limit the number of cooks in the kitchen. But for the largest cryptocurrency in the world, we're going to have

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

@Felipe > the consensus should follow the current line: discussions and tests carried out by experts. We all know that the most important devs have the most weight in discussions. And that's how it should be We have up til this point been miraculously lucky that the vast majority of prominent

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

with 100 >> bitcoins each - a total of 1 million BTC. I don't think anyone would say >> that even if those 1 million people, for example, thought that we should >> increase the number of bitcoins via perpetual inflation it would be a good >> idea to listen to it however t

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

> A transaction signaling in the affirmative MUST NOT be included in a block that does not signal in the affirmative I feel like I've heard this idea somewhere before. Its an interesting idea. It should be noted that there is a consequence of this: holders wouldn't have much say. People that

Re: [bitcoin-dev] Speedy Trial

@Erik > can we all agree that this verbal and social wrangling and chest pounding seems, right now, to remain the best system of achieving consensus? or can we do better? I would love to see more people interested in discussing this. Social wrangling is certainly the best we have, but is it the

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)

> the hot wallet can only spend a certain amount from the hot wallet spend and the rest would .. be sent back That would definitely be the way to do it. The ability to steal from the hot wallet in my opinion shouldn't really be a "concern" about CTV, but rather an understood tradeoff of a CTV

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

@Russell > OP_PUBKEY, and OP_PUBKEYHASH as wildcards Ah I see. Very interesting. Thanks for clarifying. @Nadav > You can have a CTV vault where the hot key signer is a multisig to get the advantages of both. Yes, you can create a CTV vault setup where you unvault to a multisig wallet, but you

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

@Matt > both of which are somewhat frustrating limitations, but not security limitations, only practical ones. So I think the first limitation you mentioned (that if your hot wallet's key gets stolen you need) can be legitimately considered a security limitation. Not because you need to rotate

Re: [bitcoin-dev] What to expect in the next few weeks

> 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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

> If an attacker steals the hot key, then they have the option to simply wait for the user to unvault their funds This is definitely true. Its kind of a problem with most vault proposals. Its one of the primary reasons I designed an alternative proposal

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

@Zac > More use cases means more blockchain usage which increases the price of a transaction for *everyone*. This is IMO a ridiculous opposition. Anything that increases the utility of the bitcoin network will increase usage of the blockchain and increase the price of a transaction on average.

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

Hi Michael, I'm sympathetic to the idea of allowing time for the community to absorb, review, analyze, discuss, etc any new substantial change to bitcoin, especially consensus changes. I certainly think that over time the frequency of soft forks should generally go down on average, with

Re: [bitcoin-dev] Speedy Trial

> I am not trying to convince you If that's really true then you're wasting my and everyone's time here. > Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics They can and will do politics regardless of why misunderstandings about signaling. This

Re: [bitcoin-dev] Speedy Trial

> Many users, miners and exchanges still think its voting Why do you care what they think? Why does it matter if they misunderstand? > it is not an imaginary group of people If the people aren't imaginary, then its their importance that's imaginary. > One example of a mining pool This isn't

Re: [bitcoin-dev] Speedy Trial

@Pushd > Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner

Re: [bitcoin-dev] Speedy Trial

could be constructed in > the same way (also, as long as the transaction creator keeps those > commitments as a secret, there is no way to get them; that means you can > add them later if needed and easily pretend that "it was always possible"). > > > On 2022-03-

Re: [bitcoin-dev] Speedy Trial

Good Evening ZmnSCPxj, > I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request. You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a

Re: [bitcoin-dev] Improving RBF Policy

@Antoine > B overrides A and starts to replace package A in the network mempools nearest to Alice. I think those peers won't have bandwidth saving from adopting a replacement staggering strategy. That's an interesting point, but even with that fact, the method would be effective at limiting

Re: [bitcoin-dev] Speedy Trial

@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 for each UTXO they want to respond to the poll

Re: [bitcoin-dev] Speedy Trial

@Aj Your steps seem reasonable. I definitely agree step one (talking to each other) is obviously the ideal solution, when it works. Step 2 (futures market) is the option I would say I understand the least. In any case, a futures market seems like it only incorporates the opinions/predictions of

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

> The constants table would be part of the SCRIPT puzzle Ah I see what you're saying now. You're not talking about referencing inputs from the spender, but rather constants for the script writer to parameterize a jet with. TBH I think both would be useful, and both could potentially be done in

Re: [bitcoin-dev] Improving RBF Policy

Hi Gloria, It seems you're responding to what I wrote on github. Happy to respond, but perhaps we should keep it there so the conversation is kept linearly together? I'm curious what you think of my thoughts on what you brought up most recently in this thread about rate limiting / staggered

Re: [bitcoin-dev] Speedy Trial

> If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude

Re: [bitcoin-dev] Improving RBF Policy

In reading through more of the discussion, it seems the idea I presented above might basically be a reformulation of t-bast's rate-limiting idea presented in this comment . Perhaps he

Re: [bitcoin-dev] Speedy Trial

Thanks for pointing out that PR @pushd. Looks like pretty good evidence for what the status of consensus was around BIP8 in the last 2 years. @Jorge, I tried to engage with you on the topic of activation rules last year. This is where we left it

Re: [bitcoin-dev] Improving RBF Policy

Hi Gloria, > 1. Transaction relay rate limiting I have a similar concern as yours, that this could prevent higher fee-rate transactions from being broadcast. > 2. Staggered broadcast of replacement transactions: within some time interval, maybe accept multiple replacements for the same

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

> 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. > How large is the critical mass needed? Well it

Re: [bitcoin-dev] Speedy Trial

> BIP 8 did in fact have broad consensus I hear you claim this often Luke, but claiming its so does not make it so. Do you think BIP8 still has broad consensus? If that's the case, maybe all that's needed is to gather some evidence and present it.

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

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 no DOS vector. Doesn't adding extra

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

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 without requiring all nodes to upgrade to new relay rules. Probably. This would give upgraded nodes

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

> Are new jets consensus critical? > Do I need to debate `LOT` *again* if I want to propose a new jet? New jets should never need a consensus change. A jet is just an optimization - a way to both save bytes in transmission as well as save processing power. Anything that a jet can do can be done

Re: [bitcoin-dev] BIP Draft Submission

If you're serious about this, you should write up considerations around using the satoshi as a unit. That unit has none of the problems you describe. Satoshis is already a well accepted unit, and is likely to be a very practical one that might match within an order of magnitude of (the current

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

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 scripts that can't use jets, which

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

> "these sidechains are terrible" on Monday and then "these sidechains are so good they will replace the mainchain" on Tuesday Your premise is that a sidechain might come to dominate bitcoin, and that this would be better than an altcoin dominating bitcoin. Did I misunderstand you? Not quite sure

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

@Paul > I believe that money has very strong network effects. ... users will "clump up" and get "stuck". I'm of the same opinion. > This entire issue is avoided completely, if all the chains --decentralized and centralized-- and in the same monetary unit. Then, the monetary network effects never

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

@Paul > I think largeblock sidechains should be reconsidered: > * They are not a blocksize increase. This is short sighted. They would absolutely be a blocksize increase for those following a large block sidechain. While sure, it wouldn't affect bitcoin users who don't follow that sidechain, its

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

> If Drivechains are bad for whatever reason, we should not add recursive covenants. Bad "for who" was the crux of my question to you. Even if drivechains are always bad for their users, I don't think that's a good enough reason to block things that could allow people to build user-space

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

> m is how much people want to kill a sidechain, 0 = everybody would be sad if it died and would rather burn all their BTC forever than continue living Math is brutal On Sat, Feb 26, 2022, 01:39 ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Good morning Paul, > >

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

@ZmnSCPxj > we have already rejected Drivechains I also think this is kind of dubious. I don't remember consensus being to "reject" drivechains, as much as consensus was that it wasn't a priority and there wasn't a lot of interest in doing on it from many people (I'm sure Paul could comment

Re: [bitcoin-dev] Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user

The crux of the type of situation you're talking about is where a source that might revert their payment by rbf double spending sends you money. You mentioned this situation is "not unlikely". What kind of prevalence does this happen with today? Also my question is, if you've been paid by someone

Re: [bitcoin-dev] Draft-BIP: Ordinal Numbers

> El Gamal commitments, for example, are perfectly binding but only computationally hiding. That's very interesting. I stand corrected in that respect. Thanks for the information Adam! On Fri, Feb 25, 2022, 05:17 AdamISZ wrote: > > I really don't see a world where bitcoin goes that route.

Re: [bitcoin-dev] Draft-BIP: Ordinal Numbers

I think the proposal is interesting in that it could be an interesting way to solve the dust problem. While most solutions to dust focus on reducing how much are created and encouraging consolidating utxos to avoid them becoming dust, this proposal could utilize dust for valuable purposes. Why use

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

> look at how lightning ate up fees to keep bitcoin stable, we can't "scale" too quickly either I strongly disagree with this. We should be scaling Bitcoin as fast as we can. There is no reason to delay scaling for the purposes of keeping fees high. If we need fees to be higher, we can lower the

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

Thanks for the clarification ZmnSCPxj! On Sat, Feb 19, 2022 at 5:41 AM ZmnSCPxj wrote: > 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

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

> "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 attempts aren't free (for

Re: [bitcoin-dev] Thoughts on fee bumping

> the validity of a sponsor txn is "monotonically" true at any point after the inclusion of the sponsored txn in a block. Oh I see his point now. If sponsors were valid at any point in the future, not only would a utxo index be needed but an index of all transactions. Yeah, that wouldn't be

Re: [bitcoin-dev] Thoughts on fee bumping

@Jeremy > there are technical reasons for sponsors to not be monotone. Mostly that it requires the maintenance of an additional permanent TX-Index, making Bitcoin's state grow at a much worse rate What do you mean by monotone in the context of sponsor transactions? And when you say tx-index, do

Re: [bitcoin-dev] Thoughts on fee bumping

> If you wish to fee-bump transaction X with sponsor, how can you be sure that transaction isn't present in the majority of network nodes, and X has _not_ been dropped since your last broadcast ? You're right that you can't assume your target transaction hasn't been dropped. However, I assume

Re: [bitcoin-dev] Thoughts on fee bumping

With respect to the disagreement/misunderstanding about the "<1vMB in the mempool" case, I think it's important to be clear about what the goals of relay policy are. Should the goal be to only relay transactions that increase miner revenue? Sure ideally, because we want to minimize load on the

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

> in the case of a multisig/non-consensus based system, exit from that restriction is still possible But why do we care if someone reduces the value of coins they own by permanently encumbering them in some way? Burning coins permanently encumbers them so much they can't be spent at all. If the

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

> every lightning network transaction adds one dust UTXO Could you clarify what you mean here? What dust do lightning transactions create? I do think that UTXO set size is something that will need to be addressed at some point. I liked the idea of utreexo or some other accumulator as the

Re: [bitcoin-dev] PathCoin

this finesse: we still count it as trustless even though we >> are using penalties as disincentive, because the penalty *consists of a >> payment directly from the attacker to the attacked, and that payment is >> larger than the amount stolen*. I claim that that *is* stab

Re: [bitcoin-dev] PathCoin

> Notice that Lightning has the same model (in LN-Penalty), as long as > 'claiming the whole channel capacity' is enough to be larger than what is > stolen (see: channel reserves etc.). > > Sent with ProtonMail <https://protonmail.com/> Secure Email. > > > ‐‐‐ Original

Re: [bitcoin-dev] PathCoin

There was a protocol someone mentioned a while back called Sabu that had the same goals. As i recall, it had some pretty promising constructs, but would have a critical vulnerability that could be exploited by miners. This is the write up:

Re: [bitcoin-dev] CTV BIP review

> the **only** material distinction (and the one that we are discussing) is activation with or without majority hash power support I agree that characterization specifically is not moot. But its also orthogonal to the topic of the CTV opcode itself. On Thu, Jan 20, 2022 at 4:03 PM wrote: > >

Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

> Bitcoin doesn't have a strong single concept of a 'parent' I'm using the term "parent" loosely in context here to mean a relationship where an input has constraints applied to an output (or outputs). > verify the secure hash chain from its parent to itself so that it knows what the parent

Re: [bitcoin-dev] CTV BIP review

I'm curious to hear clarification on most of Luke's non-activation related comments. > I would ideally like to see fully implemented BIPs for at least one of these While that would be interesting, I think that's a heavy burden to be placed on this BIP. More in depth exploration would be helpful,

  1   2   >