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

Ok, got it. Won't waste anyone's time on terminology pedantism. The model that I proposed above is simply what *any* correct timestamping service must do. If OTS does not follow that model, then I suspect whatever OTS is, is provably incorrect or, in this context, unreliable, even when servers

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

On Sun, Apr 17, 2022 at 01:57:28PM -0700, Jeremy Rubin wrote: > the 'lots of people' stuff (get confused, can't figure out what i'm > quoting, actually are reading this conversation) is an appeal to an > authority that doesn't exist. If something is unclear to you, let me know. > If it's unclear

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

the 'lots of people' stuff (get confused, can't figure out what i'm quoting, actually are reading this conversation) is an appeal to an authority that doesn't exist. If something is unclear to you, let me know. If it's unclear to a supposed existential person or set of persons, they can let me

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

On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote: > > nonsense marketing > > I'm sure the people who are confused about "blockchain schemes as \"world > computers\" and other nonsense > marketing" are avid and regular readers of the bitcoin devs mailing list so > I offer my sincerest

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

> nonsense marketing I'm sure the people who are confused about "blockchain schemes as \"world computers\" and other nonsense marketing" are avid and regular readers of the bitcoin devs mailing list so I offer my sincerest apologies to all members of the intersection of those sets who were

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

On Sun, Feb 20, 2022 at 08:29:00AM -0800, Jeremy Rubin wrote: > > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: > > > > As I said, it's a new kind of pinning attack, distinct from other types > > > of pinning attack. > > > > > > I think pinning is "formally defined" as sequences of

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

Morning! > > For the latter case, CPFP would work and already exists. > **Unless** you are doing something complicated and offchain-y and involves > relative locktimes, of course. > > The "usual" design I recommend for Vaults contains something that is like: { CSV CHECKSIG, CHECKSIG} or { CSV

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

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: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

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 really want a *specific*

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

-- @JeremyRubin On Sat, Feb 19, 2022 at 1:39 AM Peter Todd wrote: > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: > > > As I said, it's a new kind of pinning attack, distinct from other types > > of pinning attack. > > > > I think pinning is

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

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 really want a *specific*

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

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: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

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 as there is no consensus

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

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: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

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: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

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 transaction, if > you signed and broadcasted it in

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

> 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 transaction, if you signed and broadcasted it in the first place. You can't rely on the fact that a replacement

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

On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: > > As I said, it's a new kind of pinning attack, distinct from other types > of pinning attack. > > I think pinning is "formally defined" as sequences of transactions which > prevent or make it less likely for you to make any progress

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

> As I said, it's a new kind of pinning attack, distinct from other types of pinning attack. I think pinning is "formally defined" as sequences of transactions which prevent or make it less likely for you to make any progress (in terms of units of computation proceeding). Something that only

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

On Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote: > That's not really pinning; painning usually refers to pinning something to > the bottom of the mempool whereas these mechanisms make it easier to > guarantee that progress can be made on confirming the transactions you're > interested

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

Good Afternoon, Thank-you Jeremy for your work on this, it is valuable for the public consideration but unfortunately I disagree. The idea of being able to arbitrarily attach a fee to a transaction allows a miners-only attack in which all sponsored transactions are mined and the fee-rate can

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

That's not really pinning; painning usually refers to pinning something to the bottom of the mempool whereas these mechanisms make it easier to guarantee that progress can be made on confirming the transactions you're interested in. Often times in these protocols "the call is coming inside the

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

On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote: > Happy new years devs, > > I figured I would share some thoughts for conceptual review that have been > bouncing around my head as an opportunity to clean up the fee paying > semantics in bitcoin "for good". The design space

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

Thanks for the info. > you could "sponsor yourself" directly or through a cycle involving > 1 txn. Ah I see, because the sighash flags aren't used to create the TXID. I don't really see the problem with cycles tho. Could a cycle cause problems for anyone? Seems like it would be a harmless waste

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

SIGHASH_BUNDLE https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html By cycles I meant that if you commit to the sponsors by TXID from the witness, you could "sponsor yourself" directly or through a cycle involving > 1 txn. With OP_VER I was talking about the proposal I

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

Hmm, I don't know anything about SIGHASH_BUNDLE. The only references online I can find are just mentions (mostly from you). What is SIGHASH_BUNDLE? > unless you're binding a WTXID That could work, but it would exclude cases where you have a transaction that has already been partially signed and

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

Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE like proposals. For what you're discussing, I previously proposed https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html which is similar. The benefit of the OP_VER output is that SIGHASH_EXTERNAL

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

> because you make transactions third party malleable it becomes possible to bundle and unbundle transactions. What I was suggesting doesn't make it possible to malleate someone else's transaction. I guess maybe my proposal of using a sighash flag might have been unclear. Imagine it as a script

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

The issue with sighash flags is that because you make transactions third party malleable it becomes possible to bundle and unbundle transactions. This means there are circumstances where an attacker could e.g. see your txn, and then add a lot of junk change/inputs + 25 descendants and strongly

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

I see, its not primarily to make it cheaper to append fees, but also allows appending fees in cases that aren't possible now. Is that right? I can certainly see the benefit of a more general way to add a fee to any transaction, regardless of whether you're related to that transaction or not. How

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

Can you clarify what you mean by "improve the situation"? There's a potential mild bytes savings, but the bigger deal is that the API should be much less vulnerable to pinning issues, fix dust leakage for eltoo like protocols, and just generally allow protocol designs to be fully abstracted from

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

Do you have any back-of-the-napkin math on quantifying how much this would improve the situation vs existing methods (eg cpfp)? On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev < bitcoin-...@lists.linuxfoundation.org> wrote: > Happy new years devs, > > I figured I would share some