Nostr notes by eric at voskuil.org [ARCHIVE]

📅 Original date posted:2022-10-10 📝 Original message:> ...

2023-06-07T23:14:13Z

In reply to nevent1q…kcay
_________________________

📅 Original date posted:2022-10-10
📝 Original message:> -----Original Message-----
> From: Anthony Towns <aj at erisian.com.au>
> Subject: Re: [bitcoin-dev] Packaged Transaction Relay
> > > > > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > > > > BIPs are a courtesy in the first place.
> > > > I suppose if you felt that you were the authority then this would
> > > > be your perspective.
> > > You seem to think that I'm arguing courtesy is not a good thing, or
> > > that we couldn't use more of it?
> > That is neither what I said nor implied. You were clearly dismissing
> > the public process, not advocating for politeness.
>
> And that is neither what I said nor implied, nor something I believe. If
you
> think courtesy is something that can be ignored in a public process, I
don't
> think you should expect much success.

"BIPs are a courtesy in the first place."

> If you'd like to actually participate in public standards development,
please
> feel free to make some technical comments on my proposals, or others, or
> make your own proposal, either here or on github, or heck, anywhere else.

"RE: [bitcoin-dev] Packaged Transaction Relay"

> I mean, that's what I'd suggest anyway; I'm not your boss. I promise to at
> least be entertainingly surprised if you make any progress with your
current
> approach though.

Grow up Anthony.

e

📅 Original date posted:2022-10-09 📝 Original message:On ...

2023-06-07T23:14:12Z

In reply to nevent1q…ykp5
_________________________

📅 Original date posted:2022-10-09
📝 Original message:On Sat, Oct 08, 2022, Anthony Towns via bitcoin-dev wrote:
> > > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > > BIPs are a courtesy in the first place.
> > I suppose if you felt that you were the authority then this would be
> > your perspective.
>
> You seem to think that I'm arguing courtesy is not a good thing, or that
we
> couldn't use more of it?

That is neither what I said nor implied. You were clearly dismissing the
public process, not advocating for politeness.

> > The BIP process was created by Amir specifically because Bitcoin
> > standards were being discussed and developed behind closed doors.
>
> It definitely bothers me that Bitcoin development is not being discussed
out
> in the open as much as I would like, and to counter that, I try to
encourage
> people to post their ideas to this list, and write them up as a BIP; and
likewise
> try to do both myself as well.
>
> But how much value do you think anyone's actually getting from posting
their
> development ideas to this list these days? Do you really think people
reading
> your mail will be more inspired to discuss their ideas in the open, or
that
> they'll prefer to get in a room with their friends and allies, and close
the
> doors so they can work in peace?

My comments have nothing to do with posting to this list.

> > > There's no central authority to enforce some particular way of doing
> > > things.
> > As if reaching consensus with other people implies a singular authority.
>
> Reaching consensus with other people doesn't require putting a document in
> some particular github repo, either. Which is a good thing, or the people
in
> control of that repo would become that singular authority.

It is the public process that the community has clearly established. It has
been challenged at times, which anyone is free to do - creating their own if
they feel it becomes necessary. There is certainly no such issue in this
case, so it is not at all clear what you mean to imply here. Is this just a
blanket rejection of community standards development, or is it that you feel
this community is limited to "friends and allies"?

Developers of Bitcoin Core have stated countless times that they consider
Bitcoin Core to be the protocol documentation, implying that their internal
process is the process of arriving at community consensus. What was that you
said about "some particular github repo" becoming the "singular authority"?

> > > If you think that the version restriction should be part of the BIP,
> > > why not do a pull request? The BIP is still marked as "Draft".
> > I did not implement and ship a deviation from the posted proposal.
>
> You think BIP 155 is suboptimal, and would rather see it changed, no?

The Bitcoin Core developers who deployed the deviation apparently also
thought the BIP was suboptimal. Whether I agree with the change isn't
relevant.

> But if you won't put any effort into changing it (and how much effort do
you
> think a PR to change it document it as being gated by version 70016 would
> be?), why do you imagine the people who are happy with the BIP as it is
> would put any effort in?

Yes, that's it. I'm lazy. It's all about effort, not about the process
which, by your own measure, the owners of a single repo aim to be the
"singular authority".

> > > > I doubt that anyone who's worked with it is terribly fond of
> > > > Bitcoin's P2P protocol versioning. I've spent some time on a
> > > > proposal to update it, though it hasn't been a priority. If anyone
> > > > is interested in collaborating on it please contact me directly.
>
> "contact me directly" and wanting something other than standards "being
> discussed and developed behind closed doors" seems quite contradictory to
> me.

It's the public process that is at issue, and you of course know that -
hence your varied attempts here to make it about something else.

> > Your contributions notwithstanding, you are in no place to exhibit
> > such arrogance.
>
> I don't understand what you think is arrogant about posting a public
proposal
> about how I think things should work, even if I had only put
> 10 minutes thought into it. If that *is* arrogance, I guess I think we
could use
> more of it, as well as more courtesy...

As if I was referring to this.

"BIPs are a courtesy in the first place" says it all.

Best,
e

📅 Original date posted:2022-10-08 📝 Original message:> ...

2023-06-07T23:14:11Z

In reply to nevent1q…np25
_________________________

📅 Original date posted:2022-10-08
📝 Original message:> From: Anthony Towns <aj at erisian.com.au>
> On Wed, Oct 05, 2022 at 09:32:29PM -0700, Eric Voskuil via bitcoin-dev
wrote:
> > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
>
> BIPs are a courtesy in the first place.

I suppose if you felt that you were the authority then this would be your
perspective. However in the case of community software development, open
standards are a tool to preempt such centralization.

The BIP process was created by Amir specifically because Bitcoin standards
were being discussed and developed behind closed doors. That process was
being funded almost entirely by a corporate consortium (the Bitcoin
Foundation). It was also clear that one implementation leads directly to
this type of authority complex, which is why he also started libbitcoin.
It's not surprising to learn that you feel this way, and it's nice of you to
share those thoughts publicly.

> There's no central authority to enforce some particular way of doing
things.

As if reaching consensus with other people implies a singular authority.

> > - and it's not exactly a courtesy to keep yourself from getting dropped
by
> peers. It is not clear to me why such a comment would be accepted instead
> of specifying this properly.
>
> If you think that the version restriction should be part of the BIP, why
not do
> a pull request? The BIP is still marked as "Draft".

I did not implement and ship a deviation from the posted proposal. The
developers who did so spent almost as much time writing a comment about the
intentional deviation as they would have spent issuing a PR to the BIP.
Presumably, given that years have passed, there has been enough time to
correct that "mistake". At this point there are at least 5 implementations
operating on mainnet that are inconsistent with Core.

> > I doubt that anyone who's worked with it is terribly fond of Bitcoin's
P2P
> protocol versioning. I've spent some time on a proposal to update it,
though
> it hasn't been a priority. If anyone is interested in collaborating on it
please
> contact me directly.
>
> Bottlenecking a proposal on someone who doesn't see it as a priority
doesn't
> seem smart?

I didn't realize I was holding you up. As far as I've been able to gather,
it hasn't been a priority for anyone. Yet somehow, on the same day that I
posted the fact that I was working on it, it became your top priority.

> Here's what I think makes sense:
>
> https://github.com/ajtowns/bips/blob/202210-p2pfeatures/bip-
> p2pfeatures.mediawiki

Looks like you put about 10 minutes of thought into it. In your words, BIPs
are a courtesy - feel free to do what you want.

I'm well aware of your contributions to Bitcoin, but I find the arrogance
off-putting. I have spent many years contributing to Bitcoin development and
understanding, entirely on my own dime, even paying others to do so - as
well as raising donations for them. I do this intentionally, not because
I/we haven't had offers. Many corporate and state-funded Bitcoin Core
developers have repeatedly, aggressively, openly and self-servingly worked
to put a stop to such community efforts. To them the BIP process is a
"courtesy" - just sometimes documenting what they happen to be doing in the
protocols. And without actual alternatives, that's exactly what it is.

So I'll just leave you with this:

"MIT Digital Currency Initiative (DCI) announces research collaboration with
the Bank of England on central bank digital currency

The Bank of England announced an agreement to collaborate on a twelve-month
Central Bank Digital Currency (CBDC) research project with MIT Digital
Currency Initiative. The agreement supports and builds on DCI's ongoing
research into CBDC, while also contributing to the Bank of England's wider
research and exploration of central bank digital currencies. While no
decision has been made on whether or not to introduce a CBDC in the UK, the
work will investigate and experiment with potential CBDC technology designs
and approaches, and evaluate key tradeoffs, opportunities, and risks. This
type of research can help inform wider policy development by contributing
important technical ideas and questions.

As part of OpenCBDC, DCI's open-source codebase and research initiative, MIT
DCI aims to fill this gap by engaging technologists, user researchers,
central bankers, private sector leaders, and academics in service of a more
accessible, trusted, fair, and resilient economy. We don't yet know if or in
what contexts CBDCs can help improve the broader international monetary
system, or how they might be best designed to do so, but we believe engaging
in technical research is an important step in answering these questions."

https://dci.mit.edu/research/2022/3/31/mit-digital-currency-initiative-dci-a
nnounces-research-collaboration-with-the-bank-of-england-on-central-bank-dig
ital-currency

https://ras.mit.edu/finding-funding/find-funding/federal-funding

https://dci.mit.edu/anthony-aj-towns

Some might call this a conflict of interest. A widespread community of
independent implementations is not in the interest of those who both make
and must comply with regulatory diktat.

Then of course there's this:

"Joichi Ito, director of MIT's Media Lab, resigned Saturday (Sept. 7 [2019])
after The New Yorker published an investigation into his attempts to conceal
financial contributions from pedophile Jeffrey Epstein. Although Ito
stewarded MIT's lab, his work and legacy in the crypto community have
largely passed under the radar.

Ito established the Digital Currency Initiative (DCI) at MIT, helping
bitcoin survive some of its darkest days in 2015. That year, when the
Bitcoin Foundation, a nonprofit dedicated to the cryptocurrency's
development faced "funding constraints," the DCI welcomed bitcoin core
developers Gavin Andresen, Cory Fields, and Wladimir van der Laan in
full-time roles."

https://qz.com/1704325/revisiting-mits-digital-currency-initiative-after-joi
-ito-epstein/

DCI jumps in to "help Bitcoin survive some of its darkest days". What
exactly was dark about these days apart from the fact that this corporate
consortium fell apart? It fell apart due to widespread community rejection -
initially driven by Amir. What fell apart was the attempt at corporate
influence/control, with development largely driven by Gavin and Mike Hearn
on the payroll - both of whom eventually disgraced themselves.

Your contributions notwithstanding, you are in no place to exhibit such
arrogance.

Best,
e

> Cheers,
> aj

📅 Original date posted:2022-10-06 📝 Original ...

2023-06-07T23:14:10Z

In reply to nevent1q…t3g8
_________________________

📅 Original date posted:2022-10-06
📝 Original message:>> ...sendaddrv2 messages are only sent to nodes advertising version 70016 or later (same as wtxidrelay)

> I don’t see this constraint in BIP155. Do you mean that addrv2 support was
> released in Core at the same time as wtxidrelay, or that it is an
> undocumented version constraint implemented in Core?

I see that it is the latter:

// BIP155 defines addrv2 and sendaddrv2 for all protocol versions, but some
// implementations reject messages they don't know. As a courtesy, don't send
// it to nodes with a version before 70016, as no software is known to support
// BIP155 that doesn't announce at least that protocol version number.

https://github.com/bitcoin/bitcoin/pull/20564/files#diff-6875de769e90cec84d2e8a9c1b962cdbcda44d870d42e4215827e599e11e90e3R2366-R2370

The version string in the log message I posted implies it may not be a Core release. Yet it is BIP155 compliant.

Protocol cannot be defined on an ad-hoc basis as a "courtesy" - and it's not exactly a courtesy to keep yourself from getting dropped by peers. It is not clear to me why such a comment would be accepted instead of specifying this properly. A new protocol cannot define a message for "all versions", it can only assume that older versions will disregard all unknown message traffic - or that implementers will patch it in this ad-hoc matter.

I would suggest that authors update BIP155 and BIP330 (both still in Draft status), as well any pending proposals that may have picked up this pattern from BIP155.

I doubt that anyone who's worked with it is terribly fond of Bitcoin's P2P protocol versioning. I've spent some time on a proposal to update it, though it hasn't been a priority. If anyone is interested in collaborating on it please contact me directly.

e

📅 Original date posted:2022-10-04 📝 Original message:> ...

2023-06-07T23:14:09Z

In reply to nevent1q…f0rx
_________________________

📅 Original date posted:2022-10-04
📝 Original message:> Hi,
>
> Thanks for sharing your thoughts on packaged transaction relay.

Hello, thanks for the reply.

>> The sole objective, as expressed in the OP proposal, is to:
>> "Propagate transactions that are incentive-compatible to mine, even
>> if they don't meet minimum feerate alone."
>
> I actually do think there are additional goals we should include in any protocol
> change involving transaction relay, such as ensuring that we minimize
> bandwidth waste as much as possible (as I mentioned in a previous message
> in this thread).

Yes - there is always the presumption of an optimally-performing protocol (not limited to bandwidth), this is just a restatement from the OP.

The OP fails to eliminate orphan announcement, fails to prevent packages with insufficient fee from getting stuck in the same manner as txs (without explicitly re-announcing them again in an even larger package of higher feerate), and results in orphaned package announcements for the same reason (a static package is effectively just a larger tx).

Due to the resulting orphaning, a node must allow its peer to continue to broadcast unverifiable orphans to it, potentially chasing ancestry. So in addition to bandwidth waste, there is also an inherent problem of bandwidth DOS. These are problems specifically addressed by packaged relay.

[Regarding bandwidth waste: I've pointed out in years past that breaking the Bitcoin versioning scheme creates a requirement that any unknown message type be considered valid. Up until a recently-deployed protocol change, it had always been possible to validate messages by type. I noticed recently that validating nodes have been dropping peers at an increasing rate (a consequence of that deployment). Despite being an undocumented compatibility break, it is now unfortunately a matter of protocol that a peer must allow its peers to waste its bandwidth to remain compatible - something which we should eliminate.]

> While I understand your proposal seeks to improve on an idea of static
> packages in favor of dynamic package construction based on knowledge a
> node should have of its peers, I think the main drawback of your proposal is
> that it doesn't take into account the complexities of what a peer's "minimum
> feerate" might mean. The consequence of this is that it's not generally
> possible for a node to accurately guess whether a given transaction should
> be sent in a package to a given peer, or not, and so in addition to any
> "packaged transaction relay" mechanism that is implemented by a
> transaction announcer, we'd still need to add protocol support for a receiving
> peer to retrieve a package as well.

It is certainly possible that there is ambiguity in BIP133 (and BIPs that modify it). However it's not clear to me which such ambiguity you are referring to. There is no guessing proposed.

> First of all, a node's feerate is a dynamic value. BIP 133 allows for nodes to
> send feefilter messages at any time during the lifetime of a peer connection.
> If we were to compare the feerate of ancestors of a relayed transaction to
> the feerate in place at a peer as indicated by feefilter messages, and use that
> determine whether those ancestors would have been successfully relayed or
> not, then doing so accurately would seem to require caching relay success for
> each transaction, for each peer, at the time such transaction is relayed (or
> perhaps caching feefilter values that are received from a peer?). This seems
> likely to be undesirable,

This is a possible implementation. What makes it undesirable?

> and, at any rate, is more complex than merely comparing a pair of feerates.

There are no necessary protocol changes (though a new INV type is ideal), so the relative complexity you are implying could only arise from implementation. While implementation considerations are relevant, achieving simplicity in the protocol is presumably the priority. Further, implementation complexity must be considered from what is necessary to actually achieve the objectives, and not from the perspective of any given implementation.

Merely comparing a pair of feerates produces the problems described above, which includes not resolving the central problem, so this is an apples-to-oranges comparison. It's also more complex than doing nothing, but that also doesn't resolve the problem.

> But even more fundamental than feerates being dynamic is that feerate
> itself is not a well-defined concept when applied to arbitrary transaction
> (sub-)graphs, and this is at the crux of the difficulty in coming up with
> proposals that would meet the objective of ensuring that transactions which
> are incentive-compatible to mine all get relayed successfully across the
> network. Here are a couple examples that illustrate this:
>
> - Let A be a low feerate transaction (below any peer's minimum feerate). Let
> B and C be descendants of A (but are otherwise unrelated). Suppose these
> transactions are relayed to a node in the order A, B, C. In the algorithm you
> proposed, I believe the determination for whether C should be announced
> to a given peer as a package (A, C) or as a singleton would either (1) depend
> on whether the package (A, B) was sufficient to meet the peer's feerate,

Yes

> or (2) waste bandwidth by engaging in packaged relay whenever A was already
> successfully relayed as part of a package. Both of these approaches seem
> undesirable.
>
> - Let A be a high fee, but low feerate transaction.

Low feerate means low fee (as high/low can only be relative to size), it's not clear how these can both be true.

> Suppose B is a transaction
> that conflicts with A, has a high feerate, but lower total fee. In this situation,
> two different nodes that learned of these two transactions in opposite order
> [(A, B) vs (B, A)] might be expected to have differing mempools -- this at
> least would be the case in the BIP 125 algorithm (which requires that both
> feerate and total fee must increase when replacing an existing transaction),

As a node knows which txs it has relayed to its peer, order of arrival is inconsequential.

> and at any rate it's not obvious from the information given which would be
> more optimal to include in a block, as that depends on factors that go beyond
> just these two transactions.

Block inclusion in not pertinent, either may be included.

> Suppose further that a new transaction C is
> relayed on the network, which is a child of B and very high feerate, such that
> B + C have higher fee and higher feerate than A, when taken together. In
> this case we'd want our relay protocol to ensure that even nodes which saw
> A first should still have a chance to consider transaction C, but the packaging
> design you propose (which would compare transaction B's feerate to the
> peer's, and conclude packaging is unnecessary because B's feerate might
> already exceed the peer's feerate) would not facilitate this.

Given that A and B are conflicts, A and B+C are conflicts. This is no different than the original conflict of A and B, and decided based on the required BIP125 fee increment. If A arrives first, B must be an increment over A, and vice versa. Upon the arrival of C, given prior acceptance of both A and B, B+C must be an increment over A, as the conflict arises from A/B.

> To summarize, the point I'd make from these examples is that we should not
> expect that "feerate" (whatever that means) alone will be a sufficient
> predictor of what is in our peer's mempools.

Predicting a peer's set of confirmable transactions ("mempool") is not the objective or a requirement. As far as I can tell it is sufficient to achieve requirements to the extent there are no unpublished policies.

Upon startup and connection to a peer, a node may have an empty mempool. In this case there will be no orphan or redundant announcements from the peer.

A node with a populated mempool may connect to a peer. In that case the peer will receive announcements from the peer for txs which it may already have. This will also occur due to multiple peer connections. Redundancy is not within the scope of this or the OP proposals (there are other proposals for limiting this redundancy in both scenarios to the extent desirable).

Once a node has been connected to the network for some amount of time, there will be no orphans or connection-specific redundancies announced to it. This provides a basis for the node to drop non-conforming peers (that support packaged relay), improving protection against bandwidth-wasting peers.

Any node which implements unpublished policies can expect to receive orphan announcements. This raises the question of whether the protocol should incorporate a facility for such a node to chase down orphans in the case where it is orphaning them by deleting their ancestors, even though it publishes that it accepts them based on feerate/rbf. This would imply that there is some other discretionary aspect of transactions that, as a matter of protocol, should be considered for relay.

Any such aspect internal to a tx would be economically-irrational to consider (which includes censorship), in which case it would seem preferrable to let such nodes simply accept the fact that they are creating orphans for themselves.

Any such aspect external to the tx would also be economically-irrational (mining wants the greatest possible fee opportunity), but may be a consequence of resource limitations. Storing confirmable txs in RAM constrains such resources by orders of magnitude, and an assumption that an implementation must do this would be an error (some do not). Yet storage remains finite, so this remains a possible though marginal consideration given the presumption that all accepted txs are both confirmable and satisfy feerate/rbf policy. In the case where a node is discarding previously accepted and yet-unconfirmed txs, the node accepts the possibility that this will result in it receiving orphan announcements.

The rational way to reduce the size of the mempool is to raise the published feerate, discarding txs that no longer conform. While this was not specifically described in the fairly informal proposal, the receipt of a reduced peer feerate message can cause a node to update its state for that peer, eliminating the possibility of orphan announcements to it.

> So while there may be some
> situations where a transaction relayer might be able to usefully package up a
> transaction with its dependencies (perhaps in narrowly defined situations),
> there will also always be situations where this isn't possible, and what I
> conclude from that is that it should be helpful to add to the protocol some
> way for the recipient of a transaction to request the dependencies directly.

I don't think this has been shown, but finding such issues is of course why we discuss it.

> Taken together, I roughly understand Gloria's efforts here to be a
> combination of these two approaches: add some amount of packaged
> transaction relay for simple cases (ie where the transaction graph has been
> sufficiently narrowed, to minimize bandwidth waste while reducing latency),
> and also allow for a fallback mechanism where the recipient of a transaction
> can efficiently retrieve dependencies. There seems to be a tradeoff
> involving latency, bandwidth, and robustness of these two approaches (and
> maybe also implementation complexity), so I think it's natural to expect that
> it will take some discussion and understanding of what practices are common
> on the network and what behaviors wallet or other software might adopt,
> given potential protocol changes, to figure out how best to balance these
> ideas.

The problems that I see with static packaging are:

1) Does not fully resolve the problem - a static package itself can get stuck for the same reason as a tx.
2) Requires wallet formation of a static packages - to resolve what is fundamentally a network issue.
3) Adds a complex new protocol to achieve what can be accomplished with almost no protocol change.
4) Is not bandwidth optimal, as it continues to relay/chase orphans (singular and packaged).
5) Is not DOS optimal, as it requires allowance for orphans and redundancies.

Regarding complexity - searching and marking a DAG is basic CS, and there isn't much else to the necessary implementation. There are no new messages, just a version bump and a preferably a new INV type. In terms of performance and therefore any possible increase to relay latency, this is easily measured in terms of complexity. Whether this would be a latency increase or decrease in relation to the OP is unclear.

The complexity of the search for is linear in the size of the mempool subgraph (1) induced by the traversal of ancestors from the potential package's last tx, and (2) reduced by the set of txs known to the peer. (2) includes both txs sent to and received from the peer. This would appear to be a marginal cost.

A draft of the search algorithm is available here:

https://github.com/libbitcoin/libbitcoin-network/wiki/Iterative-Channel-Package-Computation

Best,
e

📅 Original date posted:2022-09-26 📝 Original message:> ...

2023-06-07T23:13:53Z

In reply to nevent1q…gp60
_________________________

📅 Original date posted:2022-09-26
📝 Original message:> Hi Eric,
>
>
> This email wasn't answered by anyone on mailing list however I did some
> research about packages yesterday including this email and below are my
> observations, questions etc.

Hello, thanks for the reply.

> > The sole objective, as expressed in the OP proposal, is to:
> >
> > "Propagate transactions that are incentive-compatible to mine, even if they
> don't meet minimum feerate alone."
>
> According to [bitcoinops][1]: Without package relay, it’s not possible to
> effectively CPFP fee bump a transaction that’s below the minimum feerate
> nodes accept.

Yes, the problem statement is not in question, just the mechanism of resolution. The problem of stuck txs arises from minimum fee rate policy, which is a necessary DOS guard.

A secondary issue is that of orphan relay. As a node must allow receipt of orphans, it has no means to differentiate a flood of unconfirmable txs from those that are confirmable.

> Matt Corallo's thoughts in a bitcoin core [issue][2]:
>
> "Matt Corallo recently wrote about an example on the bitcoin-dev mailing list
> involving lightning transactions, where pre-signed transactions might be
> broadcast to the blockchain long after they were generated, and thus not
> have been created with a fee that is sufficient to be confirmed quickly (or
> even be accepted to node mempools). In such situations, channel
> participants may need to use chained transactions (CPFP) in order to increase
> the confirmation speed of such transactions, and that implies we may need
> to introduce a mechanism for those parent transactions to be relayed along
> with their higher feerate children, even if the parent transaction would be
> rejected by itself."

While this is a valid scenario, the problems directly affect Bitcoin. Those problems propagate to layers, but are not unique to layering.

> 1)Is it possible to have multiple pre-signed transactions with different fee
> rates in a range? Example: PSBT1: 5 sat/vbyte, PSBT2: 10 sat/vbyte, PSBT3: 20
> sat/vbyte and PSBT4: 100 sat/vbyte

If by "range" you mean a connected tx subgraph, I don't see why not. But note that nodes only operate over signed txs. PSBT is a wallet workflow.

> 2)How would covenants affect this problem?

There are a good number of covenant proposals, though I assume they are all implemented within script. If a tx is confirmable and satisfies fee rate (for DOS protection), it is relayable. Covenants affect confirmability and should not have any unique impact on relay.

> 3)How often does it happen that a pre-signed tx gets rejected by nodes
> because it did not meet the minimum fee rate? Is it predictable and could be
> managed in a different way?

Always. Only signed transactions are accepted. But assuming you are referring to a transaction that has been produced by a pre-signing workflow, I'm not sure how this would be distinct from any other tx.

> After reading several links related to packages and bitcoin core pull requests,
> I found it anti-bitcoin to introduce so much complexity because its not
> possible to CPFP fee bump a tx below minimum fee rate.

I'm not sure I follow this, maybe you could reword it. But it seems that you are saying that CPFP fee-bumping is a problem scenario and the complexity of the proposed solutions are not justified by such scenarios.

I would say that the problem is real, and that the least complex option is generally preferred. There are always tradeoffs, and balancing these is part of protocol development. But as a rule, complexity within a protocol (communication) is to be avoided where possible.

> > Furthermore any tx that is "stuck" can be freed by simply sending another
> tx. The nodes at which the tx has become stuck will just package it up and
> relay it to peers. In other words, there is no impact on wallet implementation
> apart from raising the aggregate fee using a descendant transaction.
>
> It is easy to send another tx if there is only one user involved however
> packages are trying to fix issues in which multiple users and transaction pre-
> signed between them are involved. So, it will be difficult to coordinate and
> create new pre-signed transactions in some cases although it is possible for
> some use cases.

Given that nodes do not deal in presigned txs, this coordination difficulty could not be increased in any scenario.

A node produces sets of txs ("packages") dynamically to satisfy its peer's feerate. When a wallet broadcasts a tx/package to a node, it is operating as a peer on the p2p network. The wallet simply implements the same dynamic packaging algorithm as any peer - because it is a peer.

> > This is barely a protocol change - it's primarily implementation. All that
> should be required is an additional INV element type, such as
> MSG_TX_PACKAGE.
>
> > * All elements of MSG_TX_PACKAGE in one INV message MUST to be of
> the same package.
> > * A package MUST must define a set that can be mined into one block
> (size/sigops constraint).
> > * A package SHOULD not contain confirmed txs (a race may cause this).
> > * A package MUST minimally satisfy peer.feerate.
> > * A partial tx order, as in the manner of the block.txs ordering, MUST be
> imposed.
> > * A node SHOULD drop a peer that sends a package (or tx) below
> node.feerate.
> > * A node MAY drop a peer that sends a non-minimal package according to
> node.feerate.
>
> This makes sense particularly if multiple node implementations are used in
> future.

There are many node implementations used presently. And of course these are protocol proposals, which presumes more than one implementation.

> My other questions:
>
> a)If a package has tx1, tx2, tx3, tx4 and tx5 and miner just include tx1 and tx2
> in the block, how does this affect the projects considered for packages
> proposal?

I will leave that to authors of such proposals to answer. However in what I have proposed it just means tx3/4/5 get considered for subsequent block inclusion to the extent that fee rate policy is satisfied.

One of the several problems with static construction of packages is that they can still get stuck by fee rate policy. This is just kicking the can down the road while complicating the protocol.

> b)How does changing the order of txs in a package affect these transactions?

There is no impact. I proposed the partial ordering to facilitate fail fast.

The partial ordering in block txs is unnecessary (given the PoW DOS guard). This is a consequence of the order imposed by Satoshi's implementation and only serves to slow validation (order constrains concurrency).

> c)Do packages introduce more attack vectors in bitcoin for front running or
> MEV? MEV in bitcoin currently only affects the projects that are considered
> in packages proposal.

I don't consider this relevant to any protocol considerations. Miners should always be expected to select the most optimal set of txs available in the time available to do so.

> d)What if the package contains a transactions with sanctioned address?

One can consider this a policy, much like fee rate. Any policy that is applied to transactions and not known to its peers will result in the node receiving orphans. As such the node either must allow orphans or drop peers sending orphans under the assumption that the peer is expected to have implemented the same policy.

> e)Why would miners use packages if the existing scenario in terms of fees
> per block is beneficial for them?

The presumption is that the miner is only ever seeing txs that satisfy its fee rate policy, so this is just more opportunity.

I'd add that the problem of "pinning" is related, but exacerbated by opaque policy (internal to certain implementations). Any node that ejects txs from its pool of valid but unconfirmed txs that satisfy fee rate policy is going to see orphans and going to cause txs to get stuck. This is one of the many problems with placing an arbitrary bound on the size of this pool.

A subset of this problem is RBF policy. It is nice to see some movement toward generalizing RBF. The term is really a misnomer. Conflicting txs and subgraphs of txs are only problematic in the case of DOS, which is also resolved through advertised fee policy. Any node that imposes policy beyond this will also see orphans and cause txs to get stuck.

The scenario and therefore complexity consequences of an implementation-specific memory-constrained tx pool are becoming increasingly apparent. These are implementation issues, not protocol issues. This can be observed in a recent thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html

Over time we are likely to see that the only policies that remain in widespread application are those that are necessary for DOS protection (fee rate), as other restrictions are not economically rational and cannot be enforced. We've seen recent debate regarding dust policy, and op_return policy. "non-standard" txs are perfectly valid but get stuck very easily. I'll reiterate, any policy beyond what is published via the protocol will cause the above problems.

e

> /dev/fd0
>
> [1]: https://bitcoinops.org/en/topics/package-relay/
> [2]: https://github.com/bitcoin/bitcoin/issues/14895
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Thursday, June 9th, 2022 at 4:13 AM, Eric Voskuil via bitcoin-dev <bitcoin-
> dev at lists.linuxfoundation.org> wrote:
>
>
> > Hi Suhas/Gloria,
> >
> > Good questions. I've started a new thread because it became something
> else...
> >
> > Various ideas about packaging seem to be focused on the idea of an atomic
> message that is gossiped around the network like a transaction or block.
> From my perspective that seems to create a set of problems without good
> solutions, and it is not a proper analogy to those atomic structures. It may be
> worth taking the time to step back and take a close look at the underlying
> objective.
> >
> > The sole objective, as expressed in the OP proposal, is to:
> >
> > "Propagate transactions that are incentive-compatible to mine, even if they
> don't meet minimum feerate alone."
> >
> > Effectively producing this outcome with an atomic packaging approach
> while at the same time maintaining network invariants seems unlikely, if not
> impossible.
> >
> > Fees:
> >
> > A node knows what fee rate a peer will accept, and announces individual
> txs that satisfy peer.feerate. Similarly a node knows its own feerate, and
> SHOULD drop any peer that announces txs that do not satisfy node.feerate.
> >
> > Orphans:
> >
> > A node MAY drop a peer that announces txs that the node sees as orphans
> against its DAG. It SHOULD drop the orphan tx and MAY request missing
> ancestors. Presumably after some amount of time connected to peer, node
> does not expect to see any more orphans from that peer, so these choices
> could evolve with the channel. However, the design that can only consider
> each tx in isolation will continue to cause orphan announcements on the
> channel. A below peer.feerate tx does not get announced to peer, and later
> a descendant high peer.feerate does get announced to the peer - as an
> orphan.
> >
> > BIP133 (feefilter):
> >
> > "There could be a small number of edge cases where a node's mempool
> min fee is actually less than the filter value a peer is aware of and
> transactions with fee rates between these values will now be newly
> inhibited."
> >
> > https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
> >
> > Whether the problem is "small" or not depends on the disparity between
> node fee rates, which is not a matter of protocol. This is an existing problem
> that can and should be dealt with in packaging, as part of the above
> objective.
> >
> > Packaged Transaction Relay:
> >
> > One might instead think of packaging as a per-connection function,
> operating over its transaction (input->output) DAG and the feerate of its
> own node and that of the peer. Logically a "package" is nothing more than a
> set of transactions (optimized by announcement). Only a node can
> effectively determine the packaging required by each of its peers, since only
> the node is aware of peer.feerate.
> >
> >
> > The only way to avoid dead-ending packages (including individual
> transactions, as is the objective) is for a node to package txs for each peer.
> The origination of any package is then just a wallet peer doing what a node
> does - packaging transactions that satisfy peer.feerate (i.e. that of its node).
> >
> > Current transaction relay (txB->txA):
> >
> > ===============================
> > Node0
> > txA.feerate > node.feerate, and not orphaned (accept txA)
> >
> > txA.feerate > peer1.feerate (announce txA to peer1)
> >
> > txA.feerate < peer2.feerate (do not announce txA to peer2)
> > -----
> > txB.feerate > node.feerate (accept txB)
> >
> > txB.feerate > peer1.feerate (announce txB to peer1)
> >
> > txB.feerate > peer2.feerate (announce txB to peer2)
> >
> >
> > Node1
> > Sees/accepts txA and txB.
> >
> > Node2
> > Never sees txA, sees/rejects txB (as an orphan).
> >
> > Packaged transaction relay (txB->txA):
> >
> > ===============================
> > Node0
> > txA.feerate > node.feerate, and not orphaned (accept txA)
> >
> > txA.feerate > peer1.feerate (announce txA to peer1)
> >
> > txA.feerate < peer2.feerate (do not announce txA to peer2)
> > -----
> > txB.feerate > node1.feerate (accept txB)
> >
> > txB.feerate > peer1.feerate (announce txB to peer1)
> >
> > txB.feerate > peer2.feerate (do not announce txB to peer2) <== avoid
> > predictable orphan
> >
> > txA.feerate + txB.feerate > peer2.feerate (announce pkg(A, B) to
> > peer2) <= create minimal package
> >
> >
> > Node1
> > Sees/accepts txA and txB.
> >
> > Node2
> > pkg(A, B) > node2.feerate (accept txA, txB)
> >
> > txA.feerate > peer3.feerate (announce txA to peer3)
> >
> > txB.feerate > peer3.feerate (announce txB to peer3)
> >
> >
> > Sees/accepts pkg(A, B).
> >
> > Node3
> > Sees/accepts txA and txB. <= avoided unnecessary packaging
> >
> > Summary:
> >
> > In this design, any node that receives an announcement for a pkg (or tx)
> later determined to be less than node.feerate SHOULD drop the announcing
> peer. Unlike with existing tx relay, a node can become "current" and
> subsequently see few if any tx or pkg orphans, and MAY at some point
> decide to drop any peer that announces one. Notice that packages are
> created dynamically, and any package that doesn't need to be grouped gets
> trimmed down to individual transactions. Furthermore any tx that is "stuck"
> can be freed by simply sending another tx. The nodes at which the tx has
> become stuck will just package it up and relay it to peers. In other words,
> there is no impact on wallet implementation apart from raising the aggregate
> fee using a descendant transaction.
> >
> > This is barely a protocol change - it's primarily implementation. All that
> should be required is an additional INV element type, such as
> MSG_TX_PACKAGE.
> >
> > Additional constraints:
> >
> > * All elements of MSG_TX_PACKAGE in one INV message MUST to be of
> the same package.
> > * A package MUST must define a set that can be mined into one block
> (size/sigops constraint).
> > * A package SHOULD not contain confirmed txs (a race may cause this).
> > * A package MUST minimally satisfy peer.feerate.
> > * A partial tx order, as in the manner of the block.txs ordering, MUST be
> imposed.
> > * A node SHOULD drop a peer that sends a package (or tx) below
> node.feerate.
> > * A node MAY drop a peer that sends a non-minimal package according to
> node.feerate.
> >
> > The partial ordering of block.txs introduces an ordering constraint that
> precludes full parallelism in validating input attachment. This is an
> implementation artifact that made its way into consensus. However in the
> case of packaging, the set of txs is not presumed to be valid under the proof
> of work DoS guard. As such constraints should minimize the work/traffic
> required to invalidate the message. The partial order constraint ensures that
> the DAG can be built incrementally, dropping the attempt (and peer as
> desired) as soon as the first orphan is discovered. As a result the network
> traffic and work required is not materially different than with tx relay, with
> two exceptions.
> >
> > These are the two central aspects of this approach (Avoiding Predictable
> Orphans and Creating Minimal Packages). These are graph search algorithms,
> some basic computer science. Minimality requires only that the package does
> not introduce txs that are not necessary to reach the peer.feerate (as these
> can always be packaged separately). It does not require that nodes all
> generate the same packages. It does not require negotiation, package
> identity, cryptography, or hashing. As a graph search it should be O(n) where
> n is the unconfirmed ancestry of the package, but should typically be much
> lower, if not a single step.
> >
> > Sufficiently-low-fee nodes will see only single txs. Moderate-fee
> > nodes may cause partial breakup of packages. Sufficiently high fee
> > nodes will cause peers (having received and completed the acceptance
> > of a tx/pkg with pkg.feerate < peer.feerate) to navigate from each
> > tx/package external input until reaching txs above peer.feerate, or
> > confirmed (both of which the peer is presumed to already have). If the
> > pkg.feerate is sufficiently high to connect all external inputs to the
> > intervening txs, they are added to the package and it is announced to
> > the high fee peer. Note that the individual tx.feerate > peer.feerate
> > is insufficient to ensure that the peer should have the tx, as there
> > may be ancestor txs that do not, and for which the tx was insufficient
> > to cause them to be packaged. So a non-caching algorithm must be able
> > to chase each package external input to a confirmed tx (or cache the
> > unconfirmed ancestry fee rate at each tx). Note that fee rates are not
> > directly additive, both size/
> >
> > weight and fee are required for summation (and aggregate sigops should
> be considered).
> >
> > This makes no assumptions about current implementations. The design
> would call for maintenance of a transaction (input->output) DAG with
> tx.feerate on each tx. This could be the unconfirmed tx graph (i.e. "memory
> pool") though it does not require maintenance of anything more than the
> parameters necessary to confirm a set of validated txs within a block. It is
> very reasonable to require this of any participating node. A simple version
> negotiation can identify a package-accepting/sending nodes.
> >
> >
> > I have thought about this for some time, but have not implemented either
> the graph search, source code, or BIP. Just wrote this off the top of my head.
> So I am sure there are some things I have incorrect or failed to consider. But I
> think it's worth discussing it at this point.
> >
> > e
> >
> > > -----Original Message-----
> > > From: bitcoin-dev bitcoin-dev-bounces at lists.linuxfoundation.org On
> > > Behalf Of Suhas Daftuar via bitcoin-dev
> > > Sent: Wednesday, June 8, 2022 8:59 AM
> > > To: Bitcoin Protocol Discussion
> > > bitcoin-dev at lists.linuxfoundation.org
> > > Subject: Re: [bitcoin-dev] Package Relay Proposal
> > >
> > > Hi,
> > >
> > > Thanks again for your work on this!
> > >
> > > One question I have is about potential bandwidth waste in the case
> > > of nodes running with different policy rules. Here's my
> > > understanding of a scenario I think could happen:
> > >
> > > 1) Transaction A is both low-fee and non-standard to some nodes on
> > > the network.
> > > 2) Whenever a transaction T that spends A is relayed, new nodes will
> > > send INV(PKGINFO1, T) to all package-relay peers.
> > > 3) Nodes on the network that have implemented package relay, but do
> > > not accept A, will send getdata(PKGINFO1, T) and learn all of T's
> > > unconfirmed parents (~32 bytes * number of parents(T)).
> > > 4) Such nodes will reject T. But because of transaction
> > > malleability, and to avoid being blinded to a transaction
> > > unnecessarily, these nodes will likely still send getdata(PKGINFO1,
> > > T) to every node that announces T, in case someone has a transaction
> > > that includes an alternate set of parent transactions that would pass
> policy checks.
> > >
> > > Is that understanding correct? I think a good design goal would be
> > > to not waste bandwidth in non-adversarial situations. In this case,
> > > there would be bandwidth waste from downloading duplicate data from
> > > all your peers, just because the announcement doesn't commit to the
> > > set of parent wtxids that we'd get from the peer (and so we are
> > > unable to determine that all our peers would be telling us the same thing,
> just based on the announcement).
> > >
> > > Some ways to mitigate this might be to: (a) include a hash (maybe
> > > even just a 20-byte hash -- is that enough security?) of the package
> > > wtxids (in some canonical ordering) along with the wtxid of the
> > > child in the initial announcement; (b) limit the use of v1 packages
> > > to transactions with very few parents (I don't know if this is reasonable
> for the use cases we have in mind).
> > >
> > > Another point I wanted to bring up is about the rules around v1
> > > package validation generally, and the use of a blockhash in
> > > transaction relay specifically. My first observation is that it
> > > won't always be the case that a v1 package relay node will be able
> > > to validate that a set of package transactions is fully sorted
> > > topologically, because there may be (non-parent) ancestors that are
> > > missing from the package and the best a peer can validate is
> > > topology within the package -- this means that a peer can validly
> > > (under this
> > > BIP) relay transaction packages out of the true topological sort (if
> > > all ancestors were included).
> > >
> > > This makes me wonder how useful this topological rule is. I suppose
> > > there is some value in preventing completely broken implementations
> > > from staying connected and so there is no harm in having the rule,
> > > but perhaps it would be helpful to add that nodes SHOULD order
> > > transactions based on topological sort in the complete transaction
> > > graph, so that if missing-from-package ancestors are already known
> > > by a peer (which is the expected case when using v1 package relay on
> > > transactions that have more than one generation of unconfirmed
> > > ancestor) then the remaining transactions are already properly ordered,
> and this is helpful even if unenforceable in general.
> > >
> > > The other observation I wanted to make was that having transaction
> > > relay gated on whether two nodes agree on chain tip seems like an
> > > overly restrictive criteria. I think an important design principle
> > > is that we want to minimize disruption from network splits -- if
> > > there are competing blocks found in a small window of time, it's
> > > likely that the utxo set is not materially different on the two
> > > chains (assuming miners are selecting from roughly the same sets of
> > > transactions when this happens, which is typical). Having
> > > transaction relay bifurcate on the two network halves would seem to
> > > exacerbate the difference between the two sides of the split --
> > > users ought to be agnostic about how benign splits are resolved and
> would likely want their transactions to relay across the whole network.
> > >
> > > Additionally, use of a chain tip might impose a larger burden than
> > > is necessary on software that would seek to participate in
> > > transaction relay without implementing headers sync/validation. I
> > > don't know what software exists on the network, but I imagine there
> > > are a lot of scripts out there for transaction submission to the
> > > public p2p network, and in thinking about modifying such a script to
> > > utilize package relay it seems like an unnecessary added burden to first
> learn a node's tip before trying to relay a transaction.
> > >
> > > Could you explain again what the benefit of including the blockhash
> > > is? It seems like it is just so that a node could prioritize
> > > transaction relay from peers with the same chain tip to maximize the
> > > likelihood of transaction acceptance, but in the common case this
> > > seems like a pretty negligible concern, and in the case of a chain
> > > fork that persists for many minutes it seems better to me that we
> > > not partition the network into package-relay regimes and just risk a
> > > little extra bandwidth in one direction or the other. If we solve
> > > the problem I brought up at the beginning (of de-duplicating package
> > > data across peers with a package-wtxid-commitment in the
> > > announcement), I think this is just some wasted pkginfo bandwidth on
> > > a single-link, and not across links (as we could cache validation failure for a
> package-hash to avoid re-requesting duplicate pkginfo1 messages).
> > >
> > > Best,
> > > Suhas
> > >
> > > On Tue, Jun 7, 2022 at 1:57 PM Gloria Zhao via bitcoin-dev <bitcoin-
> > > dev at lists.linuxfoundation.org <mailto:bitcoin-
> > > dev at lists.linuxfoundation.org> > wrote:
> > >
> > > Hi Eric, aj, all,
> > >
> > > Sorry for the delayed response. @aj I'm including some paraphrased
> > > points from our offline discussion (thanks).
> > >
> > > > Other idea: what if you encode the parent txs as a short hash of
> > > > the wtxid (something like bip152 short ids? perhaps seeded per
> > > > peer so collisions will be different per peer?) and include that in the inv
> announcement?
> > > > Would that work to avoid a round trip almost all of the time,
> > > > while still giving you enough info to save bw by deduping parents?
> > >
> > > > As I suggested earlier, a package is fundamentally a compact block
> > > > (or
> > > > block) announcement without the header. Compact block (BIP152)
> > > > announcement is already well-defined and widely implemented...
> > >
> > > > Let us not reinvent the wheel and/or introduce accidental
> > > > complexity. I see no reason why packaging is not simply BIP152
> > > > without the 'header'
> > > > field, an
> > > > updated protocol version, and the following sort of changes to
> > > > names
> > >
> > > Interestingly, "why not use BIP 152 shortids to save bandwidth?" is
> > > by far the most common suggestion I hear (including offline feedback).
> > > Here's a full explanation:
> > >
> > > BIP 152 shortens transaction hashes (32 bytes) to shortids (6 bytes)
> > > to save a significant amount of network bandwidth, which is
> > > extremely important in block relay. However, this comes at the
> > > expense of computational complexity. There is no way to directly
> > > calculate a transaction hash from a shortid; upon receipt of a
> > > compact block, a node is expected to calculate the shortids of every
> > > unconfirmed transaction it knows about to find the matches (BIP 152:
> > > 1, Bitcoin Core: [2]). This is expensive but appropriate for block
> > > relay, since the block must have a valid Proof of Work and new
> > > blocks only come every ~10 minutes. On the other hand, if we require
> > > nodes to calculate shortids for every transaction in their mempools every
> time they receive a package, we are creating a DoS vector.
> > > Unconfirmed transactions don't need PoW and, to have a live
> > > transaction relay network, we should expect nodes to handle
> > > transactions at a high-ish rate (i.e. at least 1000s of times more
> > > transactions than blocks). We can't pre- calculate or cache shortids
> > > for mempool transactions, since the SipHash key depends on the block
> hash and a per-connection salt.
> > >
> > > Additionally, shortid calculation is not designed to prevent
> > > intentional individual collisions. If we were to use these shortids
> > > to deduplicate transactions we've supposedly already seen, we may
> > > have a censorship vector. Again, these tradeoffs make sense for
> > > compact block relay (see shortid section in BIP 152 [3]), but not package
> relay.
> > >
> > > TLDR: DoSy if we calculate shortids on every package and censorship
> > > vector if we use shortids for deduplication.
> > >
> > > > Given this message there is no reason to send a (potentially
> > > > bogus) fee rate with every package. It can only be validated by
> > > > obtaining the full set of txs, and the only recourse is dropping
> > > > (etc.) the peer, as is the case with single txs.
> > >
> > > Yeah, I agree with this. Combined with the previous discussion with
> > > aj (i.e. we can't accurately communicate the incentive compatibility
> > > of a package without sending the full graph, and this whole dance is
> > > to avoid downloading a few low-fee transactions in uncommon edge
> > > cases), I've realized I should remove the fee + weight information
> > > from pkginfo. Yay for less complexity!
> > >
> > > Also, this might be pedantic, but I said something incorrect earlier
> > > and would like to correct myself:
> > >
> > > > > In theory, yes, but maybe it was announced earlier (while our
> > > > > node was down?) or had dropped from our mempool or similar,
> > > > > either way we don't have those txs yet.
> > >
> > > I said "It's fine if they have Erlay, since a sender would know in
> > > advance that B is missing and announce it as a package." But this
> > > isn't true since we're only using reconciliation in place of
> > > flooding to announce transactions as they arrive, not for
> > > rebroadcast, and we're not doing full mempool set reconciliation. In
> > > any case, making sure a node receives the transactions announced
> > > when it was offline is not something we guarantee, not an intended use
> case for package relay, and not worsened by this.
> > >
> > > Thanks for your feedback!
> > >
> > > Best,
> > >
> > > Gloria
> > >
> > > 0152.mediawiki#cmpctblock
> > > [2]:
> > > https://github.com/bitcoin/bitcoin/blob/master/src/blockencodings.cp
> > > p#L49
> > > [3]: https://github.com/bitcoin/bips/blob/master/bip-
> > > 0152.mediawiki#short-transaction-id-calculation
> > >
> > > On Thu, May 26, 2022 at 3:59 AM <eric at voskuil.org
> > > mailto:eric at voskuil.org > wrote:
> > >
> > > Given that packages have no header, the package requires identity in
> > > a
> > > BIP152 scheme. For example 'header' and 'blockhash' fields can be
> > > replaced with a Merkle root (e.g. "identity" field) for the package,
> > > uniquely identifying the partially-ordered set of txs. And use of
> > > 'getdata' (to obtain a package by hash) can be eliminated (not a use
> > > case).
> > >
> > > e
> > >
> > > > -----Original Message-----
> > > > From: eric at voskuil.org mailto:eric at voskuil.org
> > > <eric at voskuil.org mailto:eric at voskuil.org >
> > > > Sent: Wednesday, May 25, 2022 1:52 PM
> > > > To: 'Anthony Towns' <aj at erisian.com.au
> > > mailto:aj at erisian.com.au >; 'Bitcoin Protocol Discussion'
> > > > <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-
> > > dev at lists.linuxfoundation.org> >; 'Gloria Zhao'
> > > > <gloriajzhao at gmail.com mailto:gloriajzhao at gmail.com >
> > > > Subject: RE: [bitcoin-dev] Package Relay Proposal
> > > >
> > > > > From: bitcoin-dev <bitcoin-dev-
> > > bounces at lists.linuxfoundation.org <mailto:bitcoin-dev-
> > > bounces at lists.linuxfoundation.org> > On
> > > > Behalf
> > > > > Of Anthony Towns via bitcoin-dev
> > > > > Sent: Wednesday, May 25, 2022 11:56 AM
> > > >
> > > > > So the other thing is what happens if the peer
> > > announcing packages to us
> > > > is
> > > > > dishonest?
> > > > >
> > > > > They announce pkg X, say X has parents A B C and the fee
> > > rate is
> > > garbage.
> > > > But
> > > > > actually X has parent D and the fee rate is excellent. Do
> > > we request the
> > > > > package from another peer, or every peer, to double
> > > check? Otherwise
> > > > we're
> > > > > allowing the first peer we ask about a package to censor
> > > that tx from
> > > us?
> > > > >
> > > > > I think the fix for that is just to provide the fee and weight
> > > when
> > > > announcing
> > > > > the package rather than only being asked for its info?
> > > Then if one peer
> > > > makes
> > > > > it sound like a good deal you ask for the parent txids from
> > > them,
> > > dedupe,
> > > > > request, and verify they were honest about the parents.
> > > >
> > > > Single tx broadcasts do not carry an advertised fee rate,
> > > however the'
> > > > feefilter' message (BIP133) provides this distinction. This
> > > should be
> > > > interpreted as applicable to packages. Given this message
> > > there is no
> > > reason
> > > > to send a (potentially bogus) fee rate with every package. It
> > > can only be
> > > > validated by obtaining the full set of txs, and the only
> > > recourse is
> > > > dropping (etc.) the peer, as is the case with single txs.
> > > Relying on the
> > > > existing message is simpler, more consistent, and more
> > > efficient.
> > > >
> > > > > >> Is it plausible to add the graph in?
> > > > >
> > > > > Likewise, I think you'd have to have the graph info from
> > > many nodes if
> > > > you're
> > > > > going to make decisions based on it and don't want
> > > hostile peers to be
> > > > able to
> > > > > trick you into ignoring txs.
> > > > >
> > > > > Other idea: what if you encode the parent txs as a short
> > > hash of the
> > > wtxid
> > > > > (something like bip152 short ids? perhaps seeded per
> > > peer so collisions
> > > > will
> > > > > be different per peer?) and include that in the inv
> > > announcement? Would
> > > > > that work to avoid a round trip almost all of the time,
> > > while still
> > > giving
> > > > you
> > > > > enough info to save bw by deduping parents?
> > > >
> > > > As I suggested earlier, a package is fundamentally a
> > > compact block (or
> > > > block) announcement without the header. Compact block
> > > (BIP152)
> > > > announcement
> > > > is already well-defined and widely implemented. A node
> > > should never be
> > > > required to retain an orphan, and BIP152 ensures this is not
> > > required.
> > > >
> > > > Once a validated set of txs within the package has been
> > > obtained with
> > > > sufficient fee, a fee-optimal node would accept the largest
> > > subgraph of
> > > the
> > > > package that conforms to fee constraints and drop any
> > > peer that provides a
> > > > package for which the full graph does not.
> > > >
> > > > Let us not reinvent the wheel and/or introduce accidental
> > > complexity. I
> > > see
> > > > no reason why packaging is not simply BIP152 without the
> > > 'header' field,
> > > an
> > > > updated protocol version, and the following sort of changes
> > > to names:
> > > >
> > > > sendpkg
> > > > MSG_CMPCT_PKG
> > > > cmpctpkg
> > > > getpkgtxn
> > > > pkgtxn
> > > >
> > > > > > For a maximum 25 transactions,
> > > > > >2324/2 = 276, seems like 36 bytes for a child-with-
> > > parents package.
> > > > >
> > > > > If you're doing short ids that's maybe 254B=100B
> > > already, then the
> > > above
> > > > is
> > > > > up to 36% overhead, I guess. Might be worth thinking
> > > more about, but
> > > > maybe
> > > > > more interesting with ancestors than just parents.
> > > > >
> > > > > >Also side note, since there are no size/count params,
> > > >
> > > > Size is restricted in the same manner as block and
> > > transaction broadcasts,
> > > > by consensus. If the fee rate is sufficient there would be no
> > > reason to
> > > > preclude any valid size up to what can be mined in one
> > > block (packaging
> > > > across blocks is not economically rational under the
> > > assumption that one
> > > > miner cannot expect to mine multiple blocks in a row).
> > > Count is
> > > incorporated
> > > > into BIP152 as 'shortids_length'.
> > > >
> > > > > > wondering if we
> > > > > >should just have "version" in "sendpackages" be a bit
> > > field instead of
> > > > > >sending a message for each version. 32 versions should
> > > be enough right?
> > > >
> > > > Adding versioning to individual protocols is just a reflection
> > > of the
> > > > insufficiency of the initial protocol versioning design, and
> > > that of the
> > > > various ad-hoc changes to it (including yet another
> > > approach in this
> > > > proposal) that have been introduced to compensate for it,
> > > though I'll
> > > > address this in an independent post at some point.
> > > >
> > > > Best,
> > > > e
> > > >
> > > > > Maybe but a couple of messages per connection doesn't
> > > really seem worth
> > > > > arguing about?
> > > > >
> > > > > Cheers,
> > > > > aj
> > > > >
> > > > >
> > > > > --
> > > > > Sent from my phone.
> > > > >
> > > _______________________________________________
> > > > > bitcoin-dev mailing list
> > > > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-
> > > dev at lists.linuxfoundation.org>
> > > > >
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-
> > > dev at lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-06-08 📝 Original message:Hi ...

2023-06-07T23:10:22Z

In reply to nevent1q…mdqu
_________________________

📅 Original date posted:2022-06-08
📝 Original message:Hi Suhas/Gloria,

Good questions. I've started a new thread because it became something else...

Various ideas about packaging seem to be focused on the idea of an atomic message that is gossiped around the network like a transaction or block. From my perspective that seems to create a set of problems without good solutions, and it is not a proper analogy to those atomic structures. It may be worth taking the time to step back and take a close look at the underlying objective.

The sole objective, as expressed in the OP proposal, is to:

"Propagate transactions that are incentive-compatible to mine, even if they don't meet minimum feerate alone."

Effectively producing this outcome with an atomic packaging approach while at the same time maintaining network invariants seems unlikely, if not impossible.

Fees:

A node knows what fee rate a peer will accept, and announces individual txs that satisfy peer.feerate. Similarly a node knows its own feerate, and SHOULD drop any peer that announces txs that do not satisfy node.feerate.

Orphans:

A node MAY drop a peer that announces txs that the node sees as orphans against its DAG. It SHOULD drop the orphan tx and MAY request missing ancestors. Presumably after some amount of time connected to peer, node does not expect to see any more orphans from that peer, so these choices could evolve with the channel. However, the design that can only consider each tx in isolation will continue to cause orphan announcements on the channel. A below peer.feerate tx does not get announced to peer, and later a descendant high peer.feerate does get announced to the peer - as an orphan.

BIP133 (feefilter):

"There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited."

https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki

Whether the problem is "small" or not depends on the disparity between node fee rates, which is not a matter of protocol. This is an existing problem that can and should be dealt with in packaging, as part of the above objective.

Packaged Transaction Relay:

One might instead think of packaging as a per-connection function, operating over its transaction (input->output) DAG and the feerate of its own node and that of the peer. Logically a "package" is nothing more than a set of transactions (optimized by announcement). Only a node can effectively determine the packaging required by each of its peers, since only the node is aware of peer.feerate.

The only way to avoid dead-ending packages (including individual transactions, as is the objective) is for a node to package txs for each peer. The origination of any package is then just a wallet peer doing what a node does - packaging transactions that satisfy peer.feerate (i.e. that of its node).

Current transaction relay (txB->txA):
===============================
Node0
txA.feerate > node.feerate, and not orphaned (accept txA)
txA.feerate > peer1.feerate (announce txA to peer1)
txA.feerate < peer2.feerate (do not announce txA to peer2)
-----
txB.feerate > node.feerate (accept txB)
txB.feerate > peer1.feerate (announce txB to peer1)
txB.feerate > peer2.feerate (announce txB to peer2)

Node1
Sees/accepts txA and txB.

Node2
Never sees txA, sees/rejects txB (as an orphan).

Packaged transaction relay (txB->txA):
===============================
Node0
txA.feerate > node.feerate, and not orphaned (accept txA)
txA.feerate > peer1.feerate (announce txA to peer1)
txA.feerate < peer2.feerate (do not announce txA to peer2)
-----
txB.feerate > node1.feerate (accept txB)
txB.feerate > peer1.feerate (announce txB to peer1)
txB.feerate > peer2.feerate (do not announce txB to peer2) <== avoid predictable orphan
txA.feerate + txB.feerate > peer2.feerate (announce pkg(A, B) to peer2) <= create minimal package

Node1
Sees/accepts txA and txB.

Node2
pkg(A, B) > node2.feerate (accept txA, txB)
txA.feerate > peer3.feerate (announce txA to peer3)
txB.feerate > peer3.feerate (announce txB to peer3)

Sees/accepts pkg(A, B).

Node3
Sees/accepts txA and txB. <= avoided unnecessary packaging

Summary:

In this design, any node that receives an announcement for a pkg (or tx) later determined to be less than node.feerate SHOULD drop the announcing peer. Unlike with existing tx relay, a node can become "current" and subsequently see few if any tx or pkg orphans, and MAY at some point decide to drop any peer that announces one. Notice that packages are created dynamically, and any package that doesn't need to be grouped gets trimmed down to individual transactions. Furthermore any tx that is "stuck" can be freed by simply sending another tx. The nodes at which the tx has become stuck will just package it up and relay it to peers. In other words, there is no impact on wallet implementation apart from raising the aggregate fee using a descendant transaction.

This is barely a protocol change - it's primarily implementation. All that should be required is an additional INV element type, such as MSG_TX_PACKAGE.

Additional constraints:

* All elements of MSG_TX_PACKAGE in one INV message MUST to be of the same package.
* A package MUST must define a set that can be mined into one block (size/sigops constraint).
* A package SHOULD not contain confirmed txs (a race may cause this).
* A package MUST minimally satisfy peer.feerate.
* A partial tx order, as in the manner of the block.txs ordering, MUST be imposed.
* A node SHOULD drop a peer that sends a package (or tx) below node.feerate.
* A node MAY drop a peer that sends a non-minimal package according to node.feerate.

The partial ordering of block.txs introduces an ordering constraint that precludes full parallelism in validating input attachment. This is an implementation artifact that made its way into consensus. However in the case of packaging, the set of txs is not presumed to be valid under the proof of work DoS guard. As such constraints should minimize the work/traffic required to invalidate the message. The partial order constraint ensures that the DAG can be built incrementally, dropping the attempt (and peer as desired) as soon as the first orphan is discovered. As a result the network traffic and work required is not materially different than with tx relay, with two exceptions.

These are the two central aspects of this approach (Avoiding Predictable Orphans and Creating Minimal Packages). These are graph search algorithms, some basic computer science. Minimality requires only that the package does not introduce txs that are not necessary to reach the peer.feerate (as these can always be packaged separately). It does not require that nodes all generate the same packages. It does not require negotiation, package identity, cryptography, or hashing. As a graph search it should be O(n) where n is the unconfirmed ancestry of the package, but should typically be much lower, if not a single step.

Sufficiently-low-fee nodes will see only single txs. Moderate-fee nodes may cause partial breakup of packages. Sufficiently high fee nodes will cause peers (having received and completed the acceptance of a tx/pkg with pkg.feerate < peer.feerate) to navigate from each tx/package external input until reaching txs above peer.feerate, or confirmed (both of which the peer is presumed to already have). If the pkg.feerate is sufficiently high to connect all external inputs to the intervening txs, they are added to the package and it is announced to the high fee peer. Note that the individual tx.feerate > peer.feerate is insufficient to ensure that the peer should have the tx, as there may be ancestor txs that do not, and for which the tx was insufficient to cause them to be packaged. So a non-caching algorithm must be able to chase each package external input to a confirmed tx (or cache the unconfirmed ancestry fee rate at each tx). Note that fee rates are not directly additive, both size/weight and fee are required for summation (and aggregate sigops should be considered).

This makes no assumptions about current implementations. The design would call for maintenance of a transaction (input->output) DAG with tx.feerate on each tx. This could be the unconfirmed tx graph (i.e. "memory pool") though it does not require maintenance of anything more than the parameters necessary to confirm a set of validated txs within a block. It is very reasonable to require this of any participating node. A simple version negotiation can identify a package-accepting/sending nodes.

I have thought about this for some time, but have not implemented either the graph search, source code, or BIP. Just wrote this off the top of my head. So I am sure there are some things I have incorrect or failed to consider. But I think it's worth discussing it at this point.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
> Behalf Of Suhas Daftuar via bitcoin-dev
> Sent: Wednesday, June 8, 2022 8:59 AM
> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Package Relay Proposal
>
> Hi,
>
> Thanks again for your work on this!
>
> One question I have is about potential bandwidth waste in the case of nodes
> running with different policy rules. Here's my understanding of a scenario I
> think could happen:
>
> 1) Transaction A is both low-fee and non-standard to some nodes on the
> network.
> 2) Whenever a transaction T that spends A is relayed, new nodes will send
> INV(PKGINFO1, T) to all package-relay peers.
> 3) Nodes on the network that have implemented package relay, but do not
> accept A, will send getdata(PKGINFO1, T) and learn all of T's unconfirmed
> parents (~32 bytes * number of parents(T)).
> 4) Such nodes will reject T. But because of transaction malleability, and to
> avoid being blinded to a transaction unnecessarily, these nodes will likely still
> send getdata(PKGINFO1, T) to every node that announces T, in case
> someone has a transaction that includes an alternate set of parent
> transactions that would pass policy checks.
>
> Is that understanding correct? I think a good design goal would be to not
> waste bandwidth in non-adversarial situations. In this case, there would be
> bandwidth waste from downloading duplicate data from all your peers, just
> because the announcement doesn't commit to the set of parent wtxids that
> we'd get from the peer (and so we are unable to determine that all our peers
> would be telling us the same thing, just based on the announcement).
>
> Some ways to mitigate this might be to: (a) include a hash (maybe even just a
> 20-byte hash -- is that enough security?) of the package wtxids (in some
> canonical ordering) along with the wtxid of the child in the initial
> announcement; (b) limit the use of v1 packages to transactions with very few
> parents (I don't know if this is reasonable for the use cases we have in mind).
>
> Another point I wanted to bring up is about the rules around v1 package
> validation generally, and the use of a blockhash in transaction relay
> specifically. My first observation is that it won't always be the case that a v1
> package relay node will be able to validate that a set of package transactions
> is fully sorted topologically, because there may be (non-parent) ancestors
> that are missing from the package and the best a peer can validate is
> topology within the package -- this means that a peer can validly (under this
> BIP) relay transaction packages out of the true topological sort (if all
> ancestors were included).
>
> This makes me wonder how useful this topological rule is. I suppose there is
> some value in preventing completely broken implementations from staying
> connected and so there is no harm in having the rule, but perhaps it would
> be helpful to add that nodes SHOULD order transactions based on topological
> sort in the complete transaction graph, so that if missing-from-package
> ancestors are already known by a peer (which is the expected case when
> using v1 package relay on transactions that have more than one generation
> of unconfirmed ancestor) then the remaining transactions are already
> properly ordered, and this is helpful even if unenforceable in general.
>
> The other observation I wanted to make was that having transaction relay
> gated on whether two nodes agree on chain tip seems like an overly
> restrictive criteria. I think an important design principle is that we want to
> minimize disruption from network splits -- if there are competing blocks
> found in a small window of time, it's likely that the utxo set is not materially
> different on the two chains (assuming miners are selecting from roughly the
> same sets of transactions when this happens, which is typical). Having
> transaction relay bifurcate on the two network halves would seem to
> exacerbate the difference between the two sides of the split -- users ought
> to be agnostic about how benign splits are resolved and would likely want
> their transactions to relay across the whole network.
>
> Additionally, use of a chain tip might impose a larger burden than is necessary
> on software that would seek to participate in transaction relay without
> implementing headers sync/validation. I don't know what software exists on
> the network, but I imagine there are a lot of scripts out there for transaction
> submission to the public p2p network, and in thinking about modifying such a
> script to utilize package relay it seems like an unnecessary added burden to
> first learn a node's tip before trying to relay a transaction.
>
> Could you explain again what the benefit of including the blockhash is? It
> seems like it is just so that a node could prioritize transaction relay from
> peers with the same chain tip to maximize the likelihood of transaction
> acceptance, but in the common case this seems like a pretty negligible
> concern, and in the case of a chain fork that persists for many minutes it
> seems better to me that we not partition the network into package-relay
> regimes and just risk a little extra bandwidth in one direction or the other. If
> we solve the problem I brought up at the beginning (of de-duplicating
> package data across peers with a package-wtxid-commitment in the
> announcement), I think this is just some wasted pkginfo bandwidth on a
> single-link, and not across links (as we could cache validation failure for a
> package-hash to avoid re-requesting duplicate pkginfo1 messages).
>
> Best,
> Suhas
>
>
> On Tue, Jun 7, 2022 at 1:57 PM Gloria Zhao via bitcoin-dev <bitcoin-
> dev at lists.linuxfoundation.org <mailto:bitcoin-
> dev at lists.linuxfoundation.org> > wrote:
>
>
> Hi Eric, aj, all,
>
> Sorry for the delayed response. @aj I'm including some paraphrased
> points from our offline discussion (thanks).
>
>
> > Other idea: what if you encode the parent txs as a short hash of the
> wtxid (something like bip152 short ids? perhaps seeded per peer so collisions
> will be different per peer?) and include that in the inv announcement?
> Would that work to avoid a round trip almost all of the time, while still giving
> you enough info to save bw by deduping parents?
>
>
> > As I suggested earlier, a package is fundamentally a compact block
> (or
> > block) announcement without the header. Compact block (BIP152)
> announcement
> > is already well-defined and widely implemented...
>
>
>
> > Let us not reinvent the wheel and/or introduce accidental
> complexity. I see
> > no reason why packaging is not simply BIP152 without the 'header'
> field, an
> > updated protocol version, and the following sort of changes to
> names
>
> Interestingly, "why not use BIP 152 shortids to save bandwidth?" is
> by far the most common suggestion I hear (including offline feedback).
> Here's a full explanation:
>
> BIP 152 shortens transaction hashes (32 bytes) to shortids (6 bytes)
> to save a significant amount of network bandwidth, which is extremely
> important in block relay. However, this comes at the expense of
> computational complexity. There is no way to directly calculate a transaction
> hash from a shortid; upon receipt of a compact block, a node is expected to
> calculate the shortids of every unconfirmed transaction it knows about to
> find the matches (BIP 152: [1], Bitcoin Core: [2]). This is expensive but
> appropriate for block relay, since the block must have a valid Proof of Work
> and new blocks only come every ~10 minutes. On the other hand, if we
> require nodes to calculate shortids for every transaction in their mempools
> every time they receive a package, we are creating a DoS vector.
> Unconfirmed transactions don't need PoW and, to have a live transaction
> relay network, we should expect nodes to handle transactions at a high-ish
> rate (i.e. at least 1000s of times more transactions than blocks). We can't pre-
> calculate or cache shortids for mempool transactions, since the SipHash key
> depends on the block hash and a per-connection salt.
>
> Additionally, shortid calculation is not designed to prevent intentional
> individual collisions. If we were to use these shortids to deduplicate
> transactions we've supposedly already seen, we may have a censorship
> vector. Again, these tradeoffs make sense for compact block relay (see
> shortid section in BIP 152 [3]), but not package relay.
>
> TLDR: DoSy if we calculate shortids on every package and censorship
> vector if we use shortids for deduplication.
>
> > Given this message there is no reason
> > to send a (potentially bogus) fee rate with every package. It can
> only be
> > validated by obtaining the full set of txs, and the only recourse is
> > dropping (etc.) the peer, as is the case with single txs.
>
>
> Yeah, I agree with this. Combined with the previous discussion with
> aj (i.e. we can't accurately communicate the incentive compatibility of a
> package without sending the full graph, and this whole dance is to avoid
> downloading a few low-fee transactions in uncommon edge cases), I've
> realized I should remove the fee + weight information from pkginfo. Yay for
> less complexity!
>
>
> Also, this might be pedantic, but I said something incorrect earlier
> and would like to correct myself:
>
> >> In theory, yes, but maybe it was announced earlier (while our
> node was down?) or had dropped from our mempool or similar, either way
> we don't have those txs yet.
>
> I said "It's fine if they have Erlay, since a sender would know in
> advance that B is missing and announce it as a package." But this isn't true
> since we're only using reconciliation in place of flooding to announce
> transactions as they arrive, not for rebroadcast, and we're not doing full
> mempool set reconciliation. In any case, making sure a node receives the
> transactions announced when it was offline is not something we guarantee,
> not an intended use case for package relay, and not worsened by this.
>
> Thanks for your feedback!
>
> Best,
>
> Gloria
>
> [1]: https://github.com/bitcoin/bips/blob/master/bip-
> 0152.mediawiki#cmpctblock
> [2]:
> https://github.com/bitcoin/bitcoin/blob/master/src/blockencodings.cpp#L49
> [3]: https://github.com/bitcoin/bips/blob/master/bip-
> 0152.mediawiki#short-transaction-id-calculation
>
> On Thu, May 26, 2022 at 3:59 AM <eric at voskuil.org
> <mailto:eric at voskuil.org> > wrote:
>
>
> Given that packages have no header, the package requires
> identity in a
> BIP152 scheme. For example 'header' and 'blockhash' fields
> can be replaced
> with a Merkle root (e.g. "identity" field) for the package,
> uniquely
> identifying the partially-ordered set of txs. And use of
> 'getdata' (to
> obtain a package by hash) can be eliminated (not a use case).
>
> e
>
> > -----Original Message-----
> > From: eric at voskuil.org <mailto:eric at voskuil.org>
> <eric at voskuil.org <mailto:eric at voskuil.org> >
> > Sent: Wednesday, May 25, 2022 1:52 PM
> > To: 'Anthony Towns' <aj at erisian.com.au
> <mailto:aj at erisian.com.au> >; 'Bitcoin Protocol Discussion'
> > <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-
> dev at lists.linuxfoundation.org> >; 'Gloria Zhao'
> > <gloriajzhao at gmail.com <mailto:gloriajzhao at gmail.com> >
> > Subject: RE: [bitcoin-dev] Package Relay Proposal
> >
> > > From: bitcoin-dev <bitcoin-dev-
> bounces at lists.linuxfoundation.org <mailto:bitcoin-dev-
> bounces at lists.linuxfoundation.org> > On
> > Behalf
> > > Of Anthony Towns via bitcoin-dev
> > > Sent: Wednesday, May 25, 2022 11:56 AM
> >
> > > So the other thing is what happens if the peer
> announcing packages to us
> > is
> > > dishonest?
> > >
> > > They announce pkg X, say X has parents A B C and the fee
> rate is
> garbage.
> > But
> > > actually X has parent D and the fee rate is excellent. Do
> we request the
> > > package from another peer, or every peer, to double
> check? Otherwise
> > we're
> > > allowing the first peer we ask about a package to censor
> that tx from
> us?
> > >
> > > I think the fix for that is just to provide the fee and weight
> when
> > announcing
> > > the package rather than only being asked for its info?
> Then if one peer
> > makes
> > > it sound like a good deal you ask for the parent txids from
> them,
> dedupe,
> > > request, and verify they were honest about the parents.
> >
> > Single tx broadcasts do not carry an advertised fee rate,
> however the'
> > feefilter' message (BIP133) provides this distinction. This
> should be
> > interpreted as applicable to packages. Given this message
> there is no
> reason
> > to send a (potentially bogus) fee rate with every package. It
> can only be
> > validated by obtaining the full set of txs, and the only
> recourse is
> > dropping (etc.) the peer, as is the case with single txs.
> Relying on the
> > existing message is simpler, more consistent, and more
> efficient.
> >
> > > >> Is it plausible to add the graph in?
> > >
> > > Likewise, I think you'd have to have the graph info from
> many nodes if
> > you're
> > > going to make decisions based on it and don't want
> hostile peers to be
> > able to
> > > trick you into ignoring txs.
> > >
> > > Other idea: what if you encode the parent txs as a short
> hash of the
> wtxid
> > > (something like bip152 short ids? perhaps seeded per
> peer so collisions
> > will
> > > be different per peer?) and include that in the inv
> announcement? Would
> > > that work to avoid a round trip almost all of the time,
> while still
> giving
> > you
> > > enough info to save bw by deduping parents?
> >
> > As I suggested earlier, a package is fundamentally a
> compact block (or
> > block) announcement without the header. Compact block
> (BIP152)
> > announcement
> > is already well-defined and widely implemented. A node
> should never be
> > required to retain an orphan, and BIP152 ensures this is not
> required.
> >
> > Once a validated set of txs within the package has been
> obtained with
> > sufficient fee, a fee-optimal node would accept the largest
> subgraph of
> the
> > package that conforms to fee constraints and drop any
> peer that provides a
> > package for which the full graph does not.
> >
> > Let us not reinvent the wheel and/or introduce accidental
> complexity. I
> see
> > no reason why packaging is not simply BIP152 without the
> 'header' field,
> an
> > updated protocol version, and the following sort of changes
> to names:
> >
> > sendpkg
> > MSG_CMPCT_PKG
> > cmpctpkg
> > getpkgtxn
> > pkgtxn
> >
> > > > For a maximum 25 transactions,
> > > >23*24/2 = 276, seems like 36 bytes for a child-with-
> parents package.
> > >
> > > If you're doing short ids that's maybe 25*4B=100B
> already, then the
> above
> > is
> > > up to 36% overhead, I guess. Might be worth thinking
> more about, but
> > maybe
> > > more interesting with ancestors than just parents.
> > >
> > > >Also side note, since there are no size/count params,
> >
> > Size is restricted in the same manner as block and
> transaction broadcasts,
> > by consensus. If the fee rate is sufficient there would be no
> reason to
> > preclude any valid size up to what can be mined in one
> block (packaging
> > across blocks is not economically rational under the
> assumption that one
> > miner cannot expect to mine multiple blocks in a row).
> Count is
> incorporated
> > into BIP152 as 'shortids_length'.
> >
> > > > wondering if we
> > > >should just have "version" in "sendpackages" be a bit
> field instead of
> > > >sending a message for each version. 32 versions should
> be enough right?
> >
> > Adding versioning to individual protocols is just a reflection
> of the
> > insufficiency of the initial protocol versioning design, and
> that of the
> > various ad-hoc changes to it (including yet another
> approach in this
> > proposal) that have been introduced to compensate for it,
> though I'll
> > address this in an independent post at some point.
> >
> > Best,
> > e
> >
> > > Maybe but a couple of messages per connection doesn't
> really seem worth
> > > arguing about?
> > >
> > > Cheers,
> > > aj
> > >
> > >
> > > --
> > > Sent from my phone.
> > >
> _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-
> dev at lists.linuxfoundation.org>
> > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-
> dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2022-05-25 📝 Original message:Given ...

2023-06-07T23:09:51Z

In reply to nevent1q…gwt7
_________________________

📅 Original date posted:2022-05-25
📝 Original message:Given that packages have no header, the package requires identity in a
BIP152 scheme. For example 'header' and 'blockhash' fields can be replaced
with a Merkle root (e.g. "identity" field) for the package, uniquely
identifying the partially-ordered set of txs. And use of 'getdata' (to
obtain a package by hash) can be eliminated (not a use case).

e

> -----Original Message-----
> From: eric at voskuil.org <eric at voskuil.org>
> Sent: Wednesday, May 25, 2022 1:52 PM
> To: 'Anthony Towns' <aj at erisian.com.au>; 'Bitcoin Protocol Discussion'
> <bitcoin-dev at lists.linuxfoundation.org>; 'Gloria Zhao'
> <gloriajzhao at gmail.com>
> Subject: RE: [bitcoin-dev] Package Relay Proposal
>
> > From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
> Behalf
> > Of Anthony Towns via bitcoin-dev
> > Sent: Wednesday, May 25, 2022 11:56 AM
>
> > So the other thing is what happens if the peer announcing packages to us
> is
> > dishonest?
> >
> > They announce pkg X, say X has parents A B C and the fee rate is
garbage.
> But
> > actually X has parent D and the fee rate is excellent. Do we request the
> > package from another peer, or every peer, to double check? Otherwise
> we're
> > allowing the first peer we ask about a package to censor that tx from
us?
> >
> > I think the fix for that is just to provide the fee and weight when
> announcing
> > the package rather than only being asked for its info? Then if one peer
> makes
> > it sound like a good deal you ask for the parent txids from them,
dedupe,
> > request, and verify they were honest about the parents.
>
> Single tx broadcasts do not carry an advertised fee rate, however the'
> feefilter' message (BIP133) provides this distinction. This should be
> interpreted as applicable to packages. Given this message there is no
reason
> to send a (potentially bogus) fee rate with every package. It can only be
> validated by obtaining the full set of txs, and the only recourse is
> dropping (etc.) the peer, as is the case with single txs. Relying on the
> existing message is simpler, more consistent, and more efficient.
>
> > >> Is it plausible to add the graph in?
> >
> > Likewise, I think you'd have to have the graph info from many nodes if
> you're
> > going to make decisions based on it and don't want hostile peers to be
> able to
> > trick you into ignoring txs.
> >
> > Other idea: what if you encode the parent txs as a short hash of the
wtxid
> > (something like bip152 short ids? perhaps seeded per peer so collisions
> will
> > be different per peer?) and include that in the inv announcement? Would
> > that work to avoid a round trip almost all of the time, while still
giving
> you
> > enough info to save bw by deduping parents?
>
> As I suggested earlier, a package is fundamentally a compact block (or
> block) announcement without the header. Compact block (BIP152)
> announcement
> is already well-defined and widely implemented. A node should never be
> required to retain an orphan, and BIP152 ensures this is not required.
>
> Once a validated set of txs within the package has been obtained with
> sufficient fee, a fee-optimal node would accept the largest subgraph of
the
> package that conforms to fee constraints and drop any peer that provides a
> package for which the full graph does not.
>
> Let us not reinvent the wheel and/or introduce accidental complexity. I
see
> no reason why packaging is not simply BIP152 without the 'header' field,
an
> updated protocol version, and the following sort of changes to names:
>
> sendpkg
> MSG_CMPCT_PKG
> cmpctpkg
> getpkgtxn
> pkgtxn
>
> > > For a maximum 25 transactions,
> > >23*24/2 = 276, seems like 36 bytes for a child-with-parents package.
> >
> > If you're doing short ids that's maybe 25*4B=100B already, then the
above
> is
> > up to 36% overhead, I guess. Might be worth thinking more about, but
> maybe
> > more interesting with ancestors than just parents.
> >
> > >Also side note, since there are no size/count params,
>
> Size is restricted in the same manner as block and transaction broadcasts,
> by consensus. If the fee rate is sufficient there would be no reason to
> preclude any valid size up to what can be mined in one block (packaging
> across blocks is not economically rational under the assumption that one
> miner cannot expect to mine multiple blocks in a row). Count is
incorporated
> into BIP152 as 'shortids_length'.
>
> > > wondering if we
> > >should just have "version" in "sendpackages" be a bit field instead of
> > >sending a message for each version. 32 versions should be enough right?
>
> Adding versioning to individual protocols is just a reflection of the
> insufficiency of the initial protocol versioning design, and that of the
> various ad-hoc changes to it (including yet another approach in this
> proposal) that have been introduced to compensate for it, though I'll
> address this in an independent post at some point.
>
> Best,
> e
>
> > Maybe but a couple of messages per connection doesn't really seem worth
> > arguing about?
> >
> > Cheers,
> > aj
> >
> >
> > --
> > Sent from my phone.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-05-25 📝 Original message:> ...

2023-06-07T23:09:51Z

In reply to nevent1q…t2yw
_________________________

📅 Original date posted:2022-05-25
📝 Original message:> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
Behalf
> Of Anthony Towns via bitcoin-dev
> Sent: Wednesday, May 25, 2022 11:56 AM

> So the other thing is what happens if the peer announcing packages to us
is
> dishonest?
>
> They announce pkg X, say X has parents A B C and the fee rate is garbage.
But
> actually X has parent D and the fee rate is excellent. Do we request the
> package from another peer, or every peer, to double check? Otherwise we're
> allowing the first peer we ask about a package to censor that tx from us?
>
> I think the fix for that is just to provide the fee and weight when
announcing
> the package rather than only being asked for its info? Then if one peer
makes
> it sound like a good deal you ask for the parent txids from them, dedupe,
> request, and verify they were honest about the parents.

Single tx broadcasts do not carry an advertised fee rate, however the'
feefilter' message (BIP133) provides this distinction. This should be
interpreted as applicable to packages. Given this message there is no reason
to send a (potentially bogus) fee rate with every package. It can only be
validated by obtaining the full set of txs, and the only recourse is
dropping (etc.) the peer, as is the case with single txs. Relying on the
existing message is simpler, more consistent, and more efficient.

> >> Is it plausible to add the graph in?
>
> Likewise, I think you'd have to have the graph info from many nodes if
you're
> going to make decisions based on it and don't want hostile peers to be
able to
> trick you into ignoring txs.
>
> Other idea: what if you encode the parent txs as a short hash of the wtxid
> (something like bip152 short ids? perhaps seeded per peer so collisions
will
> be different per peer?) and include that in the inv announcement? Would
> that work to avoid a round trip almost all of the time, while still giving
you
> enough info to save bw by deduping parents?

As I suggested earlier, a package is fundamentally a compact block (or
block) announcement without the header. Compact block (BIP152) announcement
is already well-defined and widely implemented. A node should never be
required to retain an orphan, and BIP152 ensures this is not required.

Once a validated set of txs within the package has been obtained with
sufficient fee, a fee-optimal node would accept the largest subgraph of the
package that conforms to fee constraints and drop any peer that provides a
package for which the full graph does not.

Let us not reinvent the wheel and/or introduce accidental complexity. I see
no reason why packaging is not simply BIP152 without the 'header' field, an
updated protocol version, and the following sort of changes to names:

sendpkg
MSG_CMPCT_PKG
cmpctpkg
getpkgtxn
pkgtxn

> > For a maximum 25 transactions,
> >23*24/2 = 276, seems like 36 bytes for a child-with-parents package.
>
> If you're doing short ids that's maybe 25*4B=100B already, then the above
is
> up to 36% overhead, I guess. Might be worth thinking more about, but maybe
> more interesting with ancestors than just parents.
>
> >Also side note, since there are no size/count params,

Size is restricted in the same manner as block and transaction broadcasts,
by consensus. If the fee rate is sufficient there would be no reason to
preclude any valid size up to what can be mined in one block (packaging
across blocks is not economically rational under the assumption that one
miner cannot expect to mine multiple blocks in a row). Count is incorporated
into BIP152 as 'shortids_length'.

> > wondering if we
> >should just have "version" in "sendpackages" be a bit field instead of
> >sending a message for each version. 32 versions should be enough right?

Adding versioning to individual protocols is just a reflection of the
insufficiency of the initial protocol versioning design, and that of the
various ad-hoc changes to it (including yet another approach in this
proposal) that have been introduced to compensate for it, though I'll
address this in an independent post at some point.

Best,
e

> Maybe but a couple of messages per connection doesn't really seem worth
> arguing about?
>
> Cheers,
> aj
>
>
> --
> Sent from my phone.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-05-18 📝 Original message:Good ...

2023-06-07T23:08:48Z

In reply to nevent1q…ldnx
_________________________

📅 Original date posted:2022-05-18
📝 Original message:Good evening ZmnSCPxj,

Sorry for the long delay...

> 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 in exchange. This is of course the nature of lending, as a period
> > without one's capital incurs an opportunity cost that must be offset (by
> > interest).
> >
> > The borrower's "use" of the principal is what is being overlooked. To
> > generate income from capital one must produce something and sell it.
> > Production requires both capital and time. Borrowing the principle for the
> > period allows the borrower to produce goods, sell them, and return the
> > "profit" as interest to the lender. Use implies that the borrower is spending
> > the principle - trading it with others. Eventually any number of others end up
> > holding the principle. At maturity, the coin is returned to the lender (by
> > covenant). At that point, all people the borrower traded with are bag holders.
> > Knowledge of this scam results in an imputed net present zero value for the
> > borrowed principal.
>
> But in this scheme, the principal is not being used as money, but as a billboard
> for an advertisement.
>
> Thus, the bitcoins are not being used as money due to the use of the fidelity
> bond to back a "you can totally trust me I am not a bot!!" assertion.
> This is not the same as your scenario --- the funds are never transferred,
> instead, a different use of the locked funds is invented.
>
> As a better analogy: I am borrowing a piece of gold, smelting it down to make
> a nice shiny advertisement "I am totally not a bot!!", then at the end of the
> lease period, re-smelting it back and returning to you the same gold piece
> (with the exact same atoms constituting it), plus an interest from my business,
> which gained customers because of the shiny gold advertisement claiming "I
> am totally not a bot!!".
>
> That you use the same piece of gold for money does not preclude me using
> the gold for something else of economic value, like making a nice shiny
> advertisement, so I think your analysis fails there.
> Otherwise, your analysis is on point, but analyses something else entirely.

Ok, so you are suggesting the renting of someone else's proof of "burn" (opportunity cost) to prove your necessary expense - the financial equivalent of your own burn. Reading through the thread, it looks like you are suggesting this as a way the cost of the burn might be diluted across multiple uses, based on the obscuration of the identity. And therefore identity (or at least global uniqueness) enters the equation. Sounds like a reasonable concern to me.

It appears that the term "fidelity bond" is generally accepted, though I find this an unnecessarily misleading analogy. A bond is a loan (capital at risk), and a fidelity bond is also capital at risk (to provide assurance of some behavior). Proof of burn/work, such as Hash Cash (and Bitcoin), is merely demonstration of a prior expense. But in those cases, the expense is provably associated. As you have pointed out, if the burn is not associated with the specific use, it can be reused, diluting the demonstrated expense to an unprovable degree.

I can see how you come to refer to selling the PoB as "lending" it, because the covenant on the underlying coin is time constrained. But nothing is actually lent here. The "advertisement" created by the covenant (and its presumed exclusivity) is sold. This is also entirely consistent with the idea that a loan implies capital at risk. While this is nothing more than a terminology nit, the use of "fidelity bond" and the subsequent description of "renting" (the fidelity bond) both led me down another path (Tamas' proposal for risk free lending under covenant, which we discussed here years ago).

In any case, I tend to agree with your other posts on the subject. For the burn to be provably non-dilutable it must be a cost provably associated to the scenario which relies upon the cost. This provides the global uniqueness constraint (under cryptographic assumptions of difficulty).

Best,
e

> Regards,
> ZmnSCPxj

📅 Original date posted:2022-05-04 📝 Original message:Good ...

2023-06-07T23:08:47Z

In reply to nevent1q…raps
_________________________

📅 Original date posted:2022-05-04
📝 Original message: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 in exchange. This is of course the nature of lending, as a period without one's capital incurs an opportunity cost that must be offset (by interest).

The borrower's "use" of the principal is what is being overlooked. To generate income from capital one must produce something and sell it. Production requires both capital and time. Borrowing the principle for the period allows the borrower to produce goods, sell them, and return the "profit" as interest to the lender. Use implies that the borrower is spending the principle - trading it with others. Eventually any number of others end up holding the principle. At maturity, the coin is returned to the lender (by covenant). At that point, all people the borrower traded with are bag holders. Knowledge of this scam results in an imputed net present zero value for the borrowed principal.

While the lack of usability is a cost to the lender, it is not a benefit to the borrower. The lender incurs no risk, and will obtain no reward - as the loan is of no value. Failure to deploy capital is an opportunity cost, and locking it up is not deployment.

Now, even if we accept the generous (economically irrational) assumption that money must increase in price (i.e. trades from more goods) over any given period, we are still left with the observation that the presumed appreciation would accrue to the lender absent lending, making it pointless.

e

> -----Original Message-----
> From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Sent: Tuesday, May 3, 2022 7:37 PM
> To: Eric Voskuil <eric at voskuil.org>
> Cc: Chris Belcher <belcher at riseup.net>; Bitcoin Protocol Discussion <bitcoin-
> dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for
> BIP39 seeds
>
> 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 fidelity bond coin (value Y) for N blocks.
> * Landlord gets the entire fidelity bond amount (Y) back.
>
> Thus, the landlord gets X + Y satoshis, earning X satoshis, at the cost of having Y
> satoshis locked for N blocks.
>
> So I do not understand why the value of this, to the landlord, would be 0.
> Compare to a simple HODL strategy, where I lock Y satoshis for N blocks and
> get Y satoshi back.
> Or are you saying that a simple HODL strategy is of negative value and that
> "zero value" is the point where you actively invest all your savings?
> Or are you saying that HODL strategy is of some value since it still allows you
> to spend funds freely in the N blocks you are HODLing them, and the option to
> spend is of value, while dedfinitely locking the value Y for N blocks is equal to
> the value X of the rent paid (and thus net zero value)?
>
> Regards,
> ZmnSCPxj

📅 Original date posted:2022-01-20 📝 Original message:> ...

2023-06-07T23:02:34Z

In reply to nevent1q…pux7
_________________________

📅 Original date posted:2022-01-20
📝 Original message:> BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so characterization one way or another is moot IMO.

For a selective definition of “based” you can draw any conclusion you desire. However I was very clear, as was Luke, and the history on this issue is equally clear, that the *only* material distinction (and the one that we are discussing) is activation with or without majority hash power support. BIP9/ST requires this support, BIP8 does not. The characterization is not moot. It is the central issue and always has been. There was no compromise on this question made in Taproot.

e

From: Billy Tetrud <billy.tetrud at gmail.com>
Sent: Thursday, January 20, 2022 7:23 AM

Thank you Eric for pointing out the factual errors in LukeJr's mention and implications around BIP8. The fact is that the ST pull request was described as <https://github.com/bitcoin/bitcoin/pull/21377>; "BIP9-based". TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so characterization one way or another is moot IMO. In any case, I also agree with Michael that this isn't the place to have a long discussion about activation method. That discussion should be kept separate. I'd go so far to say that BIPs should not advocate for any particular activation method, but should only go so far as to mention what types of activation methods are possible (if some types aren't possible for some reason). Separation of concerns would be very useful on that front to reduce noise in conversations.

Thanks,

BT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/05477ab0/attachment.html>;

📅 Original date posted:2022-01-18 📝 Original message:> ...

2023-06-07T23:02:32Z

In reply to nevent1q…pltt
_________________________

📅 Original date posted:2022-01-18
📝 Original message:> -----Original Message-----
> From: Luke Dashjr <luke at dashjr.org>
> Sent: Tuesday, January 18, 2022 2:10 PM
> To: eric at voskuil.org
> Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 eric at voskuil.org wrote:
> > The only material distinction between BIP9 and BIP8 is that the latter
> > may activate without signaled support of hash power enforcement.
> >
> > As unenforced soft forks are not "backward compatible" they produce a
> > chain split.
>
> Enforcement of the Bitcoin consensus protocol is by users, not miners.

Given that I stated "hash power enforcement" it is quite clear that this is
in fact only produced by mining. You are misrepresenting my statement to
make an emotional appeal. Without "hash power enforcement", a soft fork is
NOT backward compatible.

"[enforcement of] consensus protocol" is of course by merchants, but that is
not the question at hand. The question is explicitly compatibility. Anyone
can activate a soft fork at any time, but without "hash power enforcement"
soft forks are NOT backward compatible.

> Softforks never produce a chain split. Miners can, and might try to do it
to cause disruption in retaliation, but the softfork itself does not.

Maybe you are trying to split hairs given the fact that blocks are produced
only by miners, so only miners can "cause" a split.

But through not intention ("disruption in retaliation") whatsoever by
mining, a soft fork will result in those activating the rule being split off
the original chain unless majority hash power enforces the rule. The fact
that doing nothing apart from deploying the rule will result in a split is
the very definition of NOT compatible.

I assume you will argue that the original chain is not "valid" and therefore
irrelevant (as if no chain split occurred). But again the point is about
compatibility. The appearance of multiple chains, which appear valid
according to either the previous or new rules, is obviously the
incompatibility.

I shouldn't have to point this out, but observed chain splits have occurred
in more the one large scale soft fork deployment. These splits have only
been resolved through hash power enforcement. In 2010 it took 51 blocks
before the current chain took the lead. In 2012 minority chains persisted
for months. The deployment of soft forks caused these splits, NOT the
actions of miners. And unless majority hash power eventually enforces it,
the soft fork branch necessarily dies.

> > It was for this reason alone that BIP8 never gained sufficient
> > support.
>
> BIP 8 in fact achieved consensus for Taproot activation.

Please define "achieved consensus", because by any definition I can imagine,
this is simply untrue.

> > This is one of the most misleading statements I've seen here. It's not
> > technically a lie, because it states what "should" happen. But it is
> > clearly intended to lead people to believe that BIP8 was actually used
> > ("again") - it was not. ST was some technical tweaks to BIP9.
>
> BIP 8 was used to activate Taproot.

No, it wasn't. I find it hard to imaging how you rationalize such grossly
misleading statements.

> > The outright deception around this one topic has led to significant
> > unnecessary conflict in the community. Make your argument, but make it
> > honestly.
>
> You are the one attempting to deceive here.

That is for others to decide. I appreciate your responses above, since they
certainly help clarify what is happening here.

e

📅 Original date posted:2022-01-18 📝 Original message:I ...

2023-06-07T23:02:31Z

In reply to nevent1q…uq5q
_________________________

📅 Original date posted:2022-01-18
📝 Original message:I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.

The only material distinction between BIP9 and BIP8 is that the latter may
activate without signaled support of hash power enforcement.

As unenforced soft forks are not "backward compatible" they produce a chain
split. It was for this reason alone that BIP8 never gained sufficient
support.

Taproot activation was in no way a compromise between enforced and
unenforced activation. Unenforced activation was wholly rejected.

> BIP 9 at this point represents developers attempting to disregard and
impose their will over community consensus, as well as an attempt to force a
miner veto backdoor/vulnerability on deployment. It should never be used
again."

This appears to be the start of another marketing campaign, an attempt to
reclaim Taproot activation as some sort of "win" over the "miner backdoor".
The same sort of misleading campaign was waged in the wake of segwit, and
led directly to the conflict around Taproot activation.

The differences between ST and BIP9 are inconsequential in this regard. The
criticism you are making of BIP9 above applies equally to ST.

> As with Taproot, any future deployments should use BIP 8 again

This is one of the most misleading statements I've seen here. It's not
technically a lie, because it states what "should" happen. But it is clearly
intended to lead people to believe that BIP8 was actually used ("again") -
it was not. ST was some technical tweaks to BIP9.

I am making no statement whatsoever on what "should" happen. My interest is
in providing accurate information so that people can make informed
decisions.

The outright deception around this one topic has led to significant
unnecessary conflict in the community. Make your argument, but make it
honestly.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
Behalf
> Of Luke Dashjr via bitcoin-dev
> Sent: Tuesday, January 18, 2022 1:19 PM
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] CTV BIP review
>
> tl;dr: I don't think CTV is ready yet (but probably close), and in any
case
> definitely not worth reviving BIP 9 with its known flaws and
vulnerability.
...
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
>
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should never be used again.
>
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed
> prior to or in parallel), but using BIP 9 would destroy this.
>
> As with Taproot, any future deployments should use BIP 8 again, until a
better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
>
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to get released as "Bitcoin Core", makes it all the more important that
the
> community firmly rejects any further action to force this regression.
>
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all

📅 Original date posted:2021-10-26 📝 Original message:Agree ...

2023-06-07T23:00:18Z

In reply to nevent1q…mtyc
_________________________

📅 Original date posted:2021-10-26
📝 Original message:Agree ZmnSCPxj

Hi lisa,

I'm all for removing it from memory. :) Did that a while ago. We just call it the transaction pool.

There will always be unconfirmed transactions floating around (even just from reorgs). Best to store them somewhere. Disk is cheap, block distribution (e.g. compact) works better if you have them already prevalidated, even if you aren't going to mine on them.

How you get them technically is not so important. There will always be a set of unconfirmed transactions, it's conceptual. But above all, anonymity is very important - on both ends. This is why transactions have integral fees. Anyone can get paid to mine, just need the txs.

Mining may be semi-restricted set is today, it may not be tomorrow. Imagine China everywhere, just like financial controls already are. That's when you see what Bitcoin can do from a security standpoint.

Treating miners as someone else is a poor security architecture. Everyone should look like a potential miner on the network, and a potential spender.

I think you are thinking of it a bit backwards. A node is a big pool of connected transactions. Block headers come along occasionally, and impose order on a subset of them.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf
> Of ZmnSCPxj via bitcoin-dev
> Sent: Tuesday, October 26, 2021 1:02 AM
> To: lisa neigut <niftynei at gmail.com>; Bitcoin Protocol Discussion <bitcoin-
> dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
>
>
> Good morning lisa,
>
> > Hi all,
> >
> > In a recent conversation with @glozow, I had the realization that the
> mempool is obsolete and should be eliminated.
> >
> > Instead, users should submit their transactions directly to mining pools,
> preferably over an anonymous communication network such as tor. This can
> easily be achieved by mining pools running a tor onion node for this express
> purpose (or via a lightning network extension etc)
> >
> > Mempools make sense in a world where mining is done by a large number
> of participating nodes, eg where the block template is constructed by a
> majority of the participants on the network. In this case, it is necessary to
> socialize pending transaction data to all participants, as you don’t know which
> participant will be constructing the winning block template.
> >
> > In reality however, mempool relay is unnecessary where the majority of
> hashpower and thus block template creation is concentrated in a semi-
> restricted set.
> >
> > Removing the mempool would greatly reduce the bandwidth requirement
> for running a node, keep intentionality of transactions private until
> confirmed/irrevocable, and naturally resolve all current issues inherent in
> package relay and rbf rules. It also resolves the recent minimum relay
> questions, as relay is no longer a concern for unmined transactions.
> >
> > Provided the number of block template producing actors remains beneath,
> say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can
> independently + directly submit their transactions to. In fact, merely allowing
> users to select their own list of endpoints to use alternatively to the mempool
> would be a low effort starting point for the eventual replacement.
> >
> > On the other hand, removing the mempool would greatly complicate solo
> mining and would also make BetterHash proposals, which move the block
> template construction away from a centralized mining pool back to the
> individual miner, much more difficult. It also makes explicit the target for DoS
> attacks.
>
> Unfortunately, this requires that miners have a persistent identity by which
> they can be contacted.
> While pseudonymity is possible, we all know that in practice, it can be easily
> pierced.
> For instance, consider that the injunction against address reuse is a
> recognition that a persistent pseudonym is a privacy leak.
>
> Ideally, the mining set should be as anonymous as possible, as some attacks
> are possible with sufficient hashpower, and making the miners keep a
> persistent identity by which they can be found may enable easier state co-
> option of mines.
> The strongest man on Earth cannot destroy his enemy if he does not know
> who and where his enemy is; so with enemies of Bitcoin and the miners of
> Bitcoin.
> (granted, near every darned mining pool self-identifies, sigh, wtf)
>
> Ideally, the set of relaying nodes hides the miners.
> Of course, in practice we can have a good guess of which relaying nodes are
> miners and which are not -- those who get blocks earlier are probably miners.
> Against this, we should note that this method of identification is probabilistic
> and not absolute (whereas miners advertising their services so they can be
> contacted and given unconfirmed transactions are a *definite* flag "I am a
> miner").
> And there is always the chance, however slim, that some node that has not
> been getting blocks "early" suddenly decides to buy a mining rig and start
> mining.
>
> In short: what you propose is to switch to side fee markets (as I understand it).
> Non-side fees are simply an anonymity layer, by which neither the miner nor
> the transactor need to know the identity of each other, they simply broadcast
> to the wider world.
> This anonymity layer remains important, however, as they help maintain the
> fee market: https://github.com/libbitcoin/libbitcoin-system/wiki/Side-Fee-
> Fallacy
>
>
> Ultimately, my objection here is simply that this requires miners to identify
> themselves.
> In practice, miners already identify themselves (even though they really,
> really should not), so this objection may be moot at this point.
>
> (Not to mention: something like P2Pool, as-is, would not work well in that
> model; you would need to implement a mempool for those as well)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-07-09 📝 Original message:> ...

2023-06-07T22:56:49Z

In reply to nevent1q…7wcz
_________________________

📅 Original date posted:2021-07-09
📝 Original message:> Good morning e,

Good afternoon Z.

> > Any expectation of interest implies borrowing, in other words, a loan to
> the bank.
>
> Perhaps this is the key point of contention?

I'm not sure, but from my observations it's long been a point of confusion in Bitcoiner understanding of banking.

To put a finer point on it, Rothbard's criteria is a vague in a couple ways. Earnings that offset fees are also "interest" in the economic context - in which he writes. So even a zero-interest account (or negative up to the full cost of maintaining the account) qualifies under this criterion. Yet he is careful to say "implies". The arrangement may of course be explicit, in which case one no longer relies on implied contract, one relies on explicit contract. Finally, one may "expect" no interest, and even pay fees, but it may nonetheless be a loan. This is what contracts are for.

If one contracts for warehousing service, such Safe Deposit, as opposed to a time deposit, such as Certificate of Deposit, Savings Account, or Checking Account, then one gets a warehousing service - full fees and a contractual obligation to maintain 100% of the deposit. There are also money transmission services that move money around for a fee. The inability to distinguish money from credit (including money substitutes) and warehousing from investment (including "banking") leads directly to false conclusions regarding money and banking. Unfortunately a good number of self-described "Austrians" perpetuate these errors.

> In cases where Bitcoin is given over to an exchange, there is no expectation
> of interest, at least in the sense that there is no expectation that the number
> of Bitcoins deposited in the exchange *increase* over time.
> (There may be an expectation of an increase in the number of green-ink
> historical commemoration papers it can buy, but the point is that the number
> of Bitcoins held in behalf of the user is not expected to change)
>
> The expectation is that exchanges earn money from the difference between
> buy-price and sell-price, and the money-warehousing service they provide is
> simply provided for free to facilitate their *main* business (i.e. brokers for
> *exchange*).
> Thus, the expectation is that the exchange provides a warehouse service,
> not a bank service, and this service is provided for free since it enables their
> *real* business of earning from bid-ask spreads.

I'm not aware of what are people's expectations, nor would I judge what qualifies as someone's "real" business, but a warehouse that facilitates trades for a fee is of course a possible business model. PayPal's intended (real?) business model was to earn from the float. That didn't pan out, because people didn't retain money in their transmitter service.

Exchanges that deal in monopoly money must move this through traditional finance. This incurs all manner of risk. When someone sends them monopoly money, there is no crypto-surety possible. This is part of their "reserve" just as is the other side of trades.

What matters is what people contract for - agree to, voluntarily.

> On the other hand, not your keys not your coins, so anyone who uses such a
> warehouse has whatever happens to the funds coming for them...

One of the essential benefits of Bitcoin being that you can be your own warehouse, and be your own money transmitter.

But all production requires investment, which inherently entails letting go of your money, producing something with it, and selling it to people for other money. All investment is from someone's "reserve". Full reserve investment (including banking) is an oxymoron. So whether through exchanges or otherwise, there will be production, risk, loss and earnings. Otherwise there will be nothing at all to buy, and all money will be worthless. This idea of assuring that money is fully reserved applies only to that which one does not invest (one's hoard); it does not apply to banks, or the capital of any other companies. If it can help people feel better about their Safe Deposit (warehousing), I'm all for it. But if one wants a 20% bitcoin reserve, one can certainly place 20% into cold storage.

> And of course exchanges need not earn money *just* from bid-ask spreads
> *in practice*, so they are unlikely to provide proof-of-reserves either.

If they did not earn money as a bank, the explicit cost of their services would be that much higher. Which people prefer is of course entirely up to them. I don't know which is more likely.

> Indeed, money warehousing may very well be provided by means other than
> proof-of-reserves, such as by using multisig the way Green wallet does, with
> better security.

Right, this is an aspect of using your own wallet.

> Perhaps "pure exchanges" would be more amenable to such a scheme
> rather than proof-of-reserves.

Or simply pairing traders, which is of course an existing model.

Best,
e

> Regards,
> ZmnSCPxj

📅 Original date posted:2021-07-06 📝 Original message:> ...

2023-06-07T22:56:42Z

In reply to nevent1q…haj8
_________________________

📅 Original date posted:2021-07-06
📝 Original message:> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this

Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.

> more than enough.

Arbitrary and subjective.

A business raises money (investment) so that it can spend more than it
previously had. This is net "insolvency" until (and assuming) it produces
and earns over time an amount sufficient to cover its capitalization and
time value.

These sort of schemes are relevant only to what Rothbard calls a money
"warehouse" (a literal vault), which is explicitly not a "bank" (banks
lend). Warehousing Bitcoin is a strange idea to start with. And given that
they are so larded with trust and race conditions it's hardly an improvement
over holding your own keys.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud <billy.tetrud at gmail.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proof of reserves - recording
>
> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proof
>
> to be honest, if any exchange supported that proof, it would be more than
> enough.
>
> there's really no way to prevent a smash-and-grab, but this does prevent a
> slow-leak
>
>
> On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev <bitcoin-
> dev at lists.linuxfoundation.org> wrote:
> >
> > I had the idea recently for proof of reserves done in a way that can be
used
> to verify reserves are sufficient on an ongoing basis. I'm curious if
there are
> any current approaches out there to proof of reserves that are similar.
> >
> > The idea is to have users create actual private keys using a seed in
pretty
> much the normal way. Users would generate a public key from this seed to
> represent their account, and would give the public key to the custodian to
> represent their account in a public record of account balances.
> >
> > When a user's account is credited, the custodian would update a map of
> addresses (created from the public key of each account) to balances - this
> map could be structured into a merkle tree in the usual "merkle approach".
> The custodian would also store funds on one or more HD wallets (each with
> many addresses) and create a proof that they own each HD wallet. The proof
> could be as simple as a single signature created with the xpub for the
wallet,
> which would be sufficient for proving ownership over the whole list/tree
of
> addresses.
> >
> > These two structures (the map and the HD wallet) would be combined and
> hashed, and the hash published in an on chain transaction (possibly along
> with a URI where the full data can be found), on something like a daily
basis.
> Software for each user could continuously validate that their account has
a
> balance that matches what it's supposed to have, and could also verify
that
> owned addresses have funds that have at least as many coins as promised to
> accounts. If these things aren't verifiable (either because the balances
total
> to more than the HD wallet contains, or because of data unavailability),
> people can raise hell about it.
> >
> > To give user's additional proving ability, a receipt system could be
added.
> Users could request a receipt for any balance update. Eg the user would
> create a message with a timestamp, their custodial "address", and the new
> balance. The user would sign this receipt and send it to the custodian,
who
> would also sign it and send it back. This way, if something goes wrong, a
user
> can use this signed receipt to show that the custodian did in fact promise
a
> new updated balance at a particular time (which would cover the case that
> the custodian records the wrong value in their map). Conversely, the
receipt
> would be useful to honest custodians as well, since they could show the
> user's signed receipt request in the case a user is trying to lie about
what
> balance they should have. There is still the case that the custodian
simply
> refuses to return a signed receipt, in which case the user's only recourse
is to
> yell about it immediately and demand a receipt or a refund.
> >
> > Why record it on chain? Doing that gives a clear record of proof of
reserves
> that can be verified later by anyone in the future. It prevents a
custodian
> from being able to change history when it suits them (by creating a new
> records with false timestamps in the past). Many of these records could be
> aggregated together and recorded in the same transaction (with a single
> hash), so a single transaction per day could record the records of all
> participating custodians. If all custodians are using a standard system,
one can
> cross verify that addresses claimed by one custodian aren't also claimed
by
> another custodian.
> >
> > Even tho the user is responsible for their keys in order to properly
verify,
> losing the keys isn't that big of a deal, since they could simply create a
new
> seed and give a new public key to the custodian - who would have other
> identifying information they could use to validate that they own the
account.
> So it places less responsibility on the user, while still introducing
people, in a
> light-weight way, to self custody of keys.
> >
> > Having a record like this every day would reduce the possibility of
> shenanigans like taking a short term loan of a large amount of
> cryptocurrency. Sure, they could take a 10 minute loan once per day, but
it
> would also be possible to trace on-chain transactions so you could tell if
such
> a thing was going on. I wonder if there would be some way to include the
> ability to prove balances held on the lightning network, but I suspect
that
> isn't generally possible.
> >
> > In any case, I'm curious what people think of this kind of thing, and if
> systems with similar properties are already out there.
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-06-30 📝 Original message:Hi ...

2023-06-07T22:55:41Z

In reply to nevent1q…d8uc
_________________________

📅 Original date posted:2021-06-30
📝 Original message:Hi Prayank,

> So majority hash power not following the consensus rules can result in chain split?

Any two people on different rules implies a chain split. That’s presumably why rule changes are called forks. There is no actual concept of “the rules” just one set of rules or another.

> Why would majority of miners decide to mine a chain that nobody wants to use?

I don’t presume to know why people prefer one thing over another, or what people want to use, nor does economics.

> What are different things possible in this case based on game theory?

I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. People throw the words around quite a bit, but I can’t give you an answer because I have found no evidence of a valid game theoretic model applicable to Bitcoin. It’s not a game, it’s a market.

> Do miners and mining pools participate in discussions before signaling for a soft fork begins?

Who knows, I don’t get invited to round table meetings.

> Can they still mine something else post activation even if signaling readiness for soft fork?

A person can mine whatever they want. Signaling does not compel a miner to enforce. Each block mined is anonymous. But each miner seeing the signals of others, unless they are coordinating, would presumably assume that others will enforce.

> Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?

A node (software) doesn’t enforce anything. Merchants enforce consensus rules when they reject trading for something that they don’t consider money. Every time two people trade both party validates what they receive (not what they trade away). Those receiving Bitcoin are economically relevant and their power is a function of how much they are doing so.

Miners censor, which is inconsequential unless enforced. Majority miners can enforce censorship by simply not building on any non-censoring blocks. This is what soft fork enforcement is.

> Is soft fork signaling same as voting?

I don’t see that it needs a label apart from signaling. There are many kinds of voting. It would be hard to equate signaling with any of them. It’s a public signal that the miner who mined a given block miner intends to censor, that’s all.

> According to my understanding, miners follow the consensus rules enforced by full nodes and get (subsidy + fees) for their work.

Miners mine a chain, which ever one they want. There are many. They earn the block reward.

> Signaling is not voting although lot of people consider it voting including some mining pools and exchanges.

What people consider it is inconsequential. It has clearly defined behavior.

e

From: Prayank <prayank at tutanota.de>
Sent: Sunday, June 27, 2021 5:01 AM
To: eric at voskuil.org
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork

Hello Eric,

I have few questions:

> Without majority hash power support, activation simply means you are off on a chain split.

So majority hash power not following the consensus rules can result in chain split? Why would majority of miners decide to mine a chain that nobody wants to use? What are different things possible in this case based on game theory?

> And activation without majority hash power certainly does not “ensure” this.

Do miners and mining pools participate in discussions before signaling for a soft fork begins? Can they still mine something else post activation even if signaling readiness for soft fork?

> If one wants to enforce a soft fork (or otherwise censor) this is accomplished by mining (or paying others to do so). Anyone can mine, so everyone gets a say. Mining is trading capital now for more later. If enough people want to do that, they can enforce a soft fork. It’s time Bitcoiners stop thinking of miners as other people. Anyone can mine, and that’s your vote.

Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?

Is soft fork signaling same as voting?

According to my understanding, miners follow the consensus rules enforced by full nodes and get (subsidy + fees) for their work. Signaling is not voting although lot of people consider it voting including some mining pools and exchanges.

--

Prayank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/92f211f5/attachment-0001.html>;

📅 Original date posted:2021-06-30 📝 Original message:> ...

2023-06-07T22:55:38Z

In reply to nevent1q…ey4c
_________________________

📅 Original date posted:2021-06-30
📝 Original message:> From: Jorge Timón <jtimon at jtimon.cc>

>> "Soft forks aren’t compatible without miner enforcement"
> Compatible with what?

There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

"Backward compatibility
As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features."

The explanation is however incomplete. If majority hash power does not enforce the new rules, the above is incorrect. Granted the word "operate" is vague, but clearly what is intended is that "non-upgraded" nodes will not be on a different coin. But in fact they would be. The underlying presumption is that BIP141 is not only signaled, but enforced by majority hash power.

>> "Soft forks without miner support cause splits".
> No, what causes splits are 3 things:
>
> 1) bugs
> 2) coordination mistakes
> 3) people wanting different rules.

#3 (and possibly #4) is what we're talking about, so it's not at all clear why you said "no".

People change their rules, because #3. If majority hash power does not enforce this (soft) change, it's a chain split.

> Let me give an example. Let's say all users want change A.
>
> Only 60% miners want it.
> When it activates with LOT=true, will this cause a split?

No, regardless of percentage adoption. You've proposed that it' is majority hash power enforced.

Furthermore, the term compatibility (see above) implies that not everyone (your impossible presumption of 100%) is aligned.

This is not a debatable subject as far as I'm concerned, but it's worth discussion for those who aren't familiar.

e

📅 Original date posted:2021-06-30 📝 Original message:All ...

2023-06-07T22:55:36Z

In reply to nevent1q…w209
_________________________

📅 Original date posted:2021-06-30
📝 Original message:All good questions.

> Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants?

It’s important that people understand that “economic” does not refer to people interested in, HODLing, coding, or selling Bitcoin. It is only those who are *presently accepting* it. We refer to these as “economic nodes”. Those are the people with the economic power to reject coin that they consider invalid. Only their validation is of any economic consequence in the event of a split. I see no reason to assume that the economy is any less centralized than mining is pooled. Today the support of the economy would be best measured by meeting with exchange operators. If they did not go along, any unenforced soft fork (split) would isolate everyone who thought they could continue to trade their coin on exchanges.

I’d also question the use of the term “majority”. It applies to hash power, by design, but not to the economy. A split of any size is possible, requiring no majority. All it requires is other people to trade with.

Exchanges are highly regulated and compliant institutions. Mining operations are heavily pooled. Neither of these is inherently better than the other. Everyone can have a say by being a miner or being a merchant. Subeconomies can split, majority hash power can censor (which is the exact mechanism of soft fork enforcement). These ideas are straightforward and hardly worthy of debate. The interesting question is how one gets others to go along with his new coin. Make no mistake, any rule change (soft or hard) is a new coin. If hash power doesn’t enforce the new rules of a soft fork, the chain is split just as if it was a hard fork.

I’m sure people will continue to try and devise ways to figure out who wants to come along, to try and convince people (including exchanges and miners) to do so, to reassure them that everyone else will “have to”, and to mislead them about the actual behavior and risks. We’ve seen permanent splits, and we’ve seen hash power enforced soft forks. We’re likely to see more of both. But as core devs we have a responsibility to inform people, honestly, and let them decide. My only beef with this whole process has been that a widespread belief had formed, supported by far too many core devs (and even embedded in the text of deployed BIPs), that soft forks are inherently “backward compatible”. This is unequivocally not true. The only such compatibility is majority hash power enforcement of a soft fork. This is not a matter of opinion, it’s the core innovation of Bitcoin. Proof of Work settles the question of who has authority to order transactions. Majority hash power has that authority. Merchants can split again and again, but their miners will still have that authority. If one wants a say, one can mine.

e

From: Billy Tetrud <billy.tetrud at gmail.com>
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric at voskuil.org>
Cc: Jorge Timón <jtimon at jtimon.cc>; Luke Dashjr <luke at dashjr.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

@Jorge

>I don't think we should avoid splits at all costs.

I absolutely agree that we shouldn't avoid splits at all costs. There are some costs too high to pay to avoid a split. If an economic majority started wanting to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard fork away from that mess with a minority chain.

> I don't think we should avoid splits when possible,

I want to see why exactly we disagree about avoiding chain splits "when possible". Are you really saying that we should just hard fork every time instead of soft fork? Should we even bother to get widespread buy in at all, or should we just release the software, hardfork away, and let anyone that wants to follow us follow us later? Are you not at all worried about the costs associated with an increased orphan rate and reorg rate? Are you not worried that an update might happen too fast and that a significant fraction of people that could have come along with us to the new update might be left behind because they didn't have time to evaluate the changed rules?

Do you agree that, in a conversation about rule changes, some people want it their way no matter what and will hardfork to get the rules they want, and some people want it their way, but only if enough other people agree to follow those rules too? Some people might want a rule change, but aren't willing to follow, say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people exist?

If you do, then I don't understand why you disagree that we should avoid chain splits even "when possible". Maybe you could elaborate as to what you mean there.

@Luke

Are you in agreement with Jorge here that we should not even attempt to avoid chain splits?

> The only alternative to a split in the problematic scenarios are 1) concede centralised miner control over the network, and 2) have inconsistent enforcement of rules by users who don't agree on what the correct rules are, again leading to centralised miner control over the network.

There is not simply a binary "do or do not". There is also timing. Non-contentious changes can happen fast. Contentious changes need more time for discussion, preparation, or coordination, even if the eventual outcome is the same. Do you disagree that timing issues can be important, that delays can be useful and help to avoid chain splits? Do you agree that miners have a (large) incentive to follow the economic majority? Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants? Will that mechanism continue to be accurate into the future?

I'm asking these questions to try and figure out why we disagree here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/cdb30f7e/attachment.html>;

📅 Original date posted:2021-04-07 📝 Original message:You ...

2023-06-07T22:51:26Z

In reply to nevent1q…04zg
_________________________

📅 Original date posted:2021-04-07
📝 Original message:You may activate any time you want.

e

From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of Claus Ehrenberg via bitcoin-dev
Sent: Wednesday, April 7, 2021 6:42 AM
To: Rusty Russell <rusty at rustcorp.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

As a user, I think it's very important for me to know if Taproot is eventually coming or not. So why not make it so that if _either_ miners _or_ users decide for Taproot, it will activate no matter what. Accepting a chain split is imo the fairest way to 'resolve the conflict' (it can't be resolved anyway).

That would probably mean running ST and and UASF concurrently.

The upside would be that we've got a safe date for Taproot, except neither users nor miners want it.

Cheers,

Claus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210407/dafd545f/attachment.html>;

📅 Original date posted:2021-03-08 📝 Original message:One ...

2023-06-07T18:30:02Z

In reply to nevent1q…uscx
_________________________

📅 Original date posted:2021-03-08
📝 Original message:One should not assume that those trying to avoid a chain split are against Taproot.

There is a concerning widespread misperception in the community at large that soft forks are inherently “backward compatible”. To many people this seems to mean that, even without hash power enforcement, activation will not create a chain split. This is no doubt reinforced by loose wording in past proposals, such as the unqualified, “As a soft fork, older software will continue to operate without modification.” (BIP141). If operating means not crashing, then hard forks also qualify. Many people do not understand that hash power enforcement is also required for a soft fork to avoid a chain split.

This misperception has also been fed by devs who should know better claiming that BIP16 was not signaled by supermajority hash power before it was activated. The only distinction being that an *automated* activation method had not yet been developed. Starting with BIP16 *all active soft forks* have been activated by supermajority hash power signaling. I was told publicly by someone who should certainly know better that SegWit missed its BIP9 activation window and that BIP9 failed. Yet SegWit activated under BIP9 2.5 months before its activation window closed. It never entered its FAILED state and remains in its ACTIVE state (BIP90 being presumed to be merely a code optimization). This type of misinformation is a root cause of much of the conflict.

Yes, some people threatened to split themselves off with BIP148, and yes miners used BIP91 to accelerate SegWit enforcement, preventing that split well before the SegWit the activation window was set to expire. So those people claim BIP9 failed. It’s a false narrative. BIP9 could have failed, but did not. Soft fork activation could be unsupported by miners, but to date no such activation attempt has failed. No doubt it will someday. But why are people picking a fight where there isn’t one.

This should not about who gets to “decide the rules”, but that is exactly what it has become. It’s the only explanation for the conflict. Otherwise there does not appear to be any whatsoever. Miner activation is used if at all possible because it avoids a chain split. It’s as simple as that. Anyone can of course decide what rules they run. But telling them that they can do so without splitting is flatly irresponsible. If it comes to that, inform people properly and let them decide.

The reason for BIP8 is clearly to codify activation without hash power support. You are right that BIP8(LOT=false) is just BIP9. The other differences are immaterial. Given that there are other differences, it seems advisable to use what has already been coded, tested, deployed, and successful in the past. It’s also understandable that many devs no not want to be responsible for shipping code to large numbers of people who are misinformed about its behavior, potentially causing a chain split and loss of both money and faith in the system.

If one needs to consider this a question of who gets to decide, it’s not clear to me why one would side with exchanges over miners given that the latter are able to prevent a chain split. HODLer nodes are non-economic, to the extent they even exist. This isn’t a David vs. Goliath scenario, and even if it was, the supposed giant appears to overwhelmingly support Taproot.

e

From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of Jorge Timón via bitcoin-dev
Sent: Monday, March 8, 2021 4:52 AM
To: Anthony Towns <aj at erisian.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

Concept nack.

This has no advantage over bip8(true).

Bip9(false) is just bip9.

Thr only reasonable argument against bip8(true) is "some people may do bip8(false) instead", which is a stypid argument applyable to any activation method.

People against taproot should want code to forbid its activation rather than limiting themselves to suport bip9/bip8(false) and hope it doesn't get activated it.

Some other arguments seem to be based on the wrong assumption that miners should decide the rules.

Thisproposal solves nothing, just adds to the noise and thus is really disappointing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210308/8f977f39/attachment-0001.html>;

📅 Original date posted:2021-03-01 📝 Original message:On ...

2023-06-07T18:29:39Z

In reply to nevent1q…zspk
_________________________

📅 Original date posted:2021-03-01
📝 Original message:On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:

> Only headers need to be downloaded sequentially so downloading relevant blocks from one node is totally possible with gaps in between.

In fact this is exactly how libbitcoin v4 works. We download and store blocks in parallel. In the case of a restart block gaps are repopulated. Given that headers are validated, we go after the most responsive nodes. Based on standard deviation, we drop the slowest peers and rebalance load to new/empty channels. We make ordered but not necessarily sequential requests. There is no distinction between “initial” block download, a restart, or a single or few blocks at the top. So it’s referred to as continuous parallel block download.

But we don’t prune. Personally I consider this counterproductive. Apart from the complexity, it’s not healthy. And the chain grows linearly with storage cost falling exponentially, leading to a straightforward conclusion.

e

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/568af3cd/attachment.html>;

📅 Original date posted:2021-03-03 📝 Original message:> ...

2023-06-07T18:29:35Z

In reply to nevent1q…xvum
_________________________

📅 Original date posted:2021-03-03
📝 Original message:> and all transactions should be open to the scrutiny of an honest government.

>From what do you derive the moral judgement “should” in this context?

> The value proposition is … because people will trust the system?

So, it’s valuable because it’s trusted? Trusted to do what exactly? What that government money doesn’t already do, specifically.

> If it is not necessary to maintain consensus then what is consensus?

Nothing is “necessary”. Consensus is an agreement among people. It’s voluntary. Any person can choose to leave, create or join another consensus, or stay where they are.

> BCH exists in addition to BTC Bitcoin.

Exactly, people are free to do what they want. Nobody “should” do anything except that which they want to do. This and this alone is the “highest value” if one accepts the moral principle of non-aggression. You do not appear to, and I’m afraid that may be well outside the consensus view among core bitcoin developers (the people you are talking to).

e

From: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>
Sent: Tuesday, March 2, 2021 6:55 PM
To: Eric Voskuil <eric at voskuil.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: Ariel Lorenzo-Luaces <arielluaces at gmail.com>
Subject: Re: [bitcoin-dev] Taproot NACK

Good Afternoon,

All people are entitled to privacy in their purse, and all transactions should be open to the scrutiny of an honest government. You can debate whether any government is honest. Mixing does not remove the record from the public ledger, where it is possible to see that any Bitcoin has transferred from an UTXO to some Pay-To address even with some amount of transaction in between them. The value proposition is the same <https://www.youtube.com/watch?v=l9jOJk30eQs>; https://www.youtube.com/watch?v=l9jOJk30eQs - because people will trust the system; people trust the existing consensus.

Let us dispense with the screen and deal with the issue only. If it is not necessary to maintain consensus then what is consensus?

The intrinsic value of Bitcoin is because of the existing consensus. Even if any proposal gains consensus there is no objective way to show it improves the intrinsic value without trialing and the possibility of failure and so protecting the existing consensus should be the highest value. This understanding is the reason BCH exists in addition to BTC Bitcoin.

KING JAMES HRMH

Great British Empire

Regards,

The Australian

LORD HIS EXCELLENCY JAMES HRMH (& HMRH)

of Hougun Manor & Glencoe & British Empire

MR. Damian A. James Williamson

Wills

et al.

Willtech

www.willtech.com.au

www.go-overt.com

and other projects

earn.com/willtech

linkedin.com/in/damianwilliamson

m. 0487135719

f. +61261470192

This email does not constitute a general advice. Please disregard this email if misdelivered.

_____

From: Eric Voskuil <eric at voskuil.org <mailto:eric at voskuil.org> >
Sent: Tuesday, 2 March 2021 9:37 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Cc: Ariel Lorenzo-Luaces <arielluaces at gmail.com <mailto:arielluaces at gmail.com> >
Subject: Re: [bitcoin-dev] Taproot NACK

To be clear, is this a NACK because Taproot reduces “transparency” (increases privacy) on the chain (“maintaining consensus” is obviously an argument against any protocol change, so that’s a red herring)?

And is it your theory that only an “honest” (statute abiding) person should have privacy, and not against the state, and/or that mixers are sufficient privacy?

Personally, I’m not moved by such an argument. What do you think is the value proposition of Bitcoin?

e

On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:

Good Afternoon,

I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.

My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.

The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.

My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.

<ip.bitcointalk.org.png>

[ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer

<https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw>; &t=622&c=gTi7r1cfh-yynw

from this thread https://bitcointalk.org/index.php?topic=5267588

The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,

https://github.com/jambler-io/bitcoin-mixer

The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.

https://jambler.io/become-partner.php

I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.

If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.

KING JAMES HRMH

Great British Empire

Regards,

The Australian

LORD HIS EXCELLENCY JAMES HRMH (& HMRH)

of Hougun Manor & Glencoe & British Empire

MR. Damian A. James Williamson

Wills

et al.

Willtech

www.willtech.com.au <http://www.willtech.com.au>;

www.go-overt.com <http://www.go-overt.com>;

and other projects

earn.com/willtech

linkedin.com/in/damianwilliamson

m. 0487135719

f. +61261470192

This email does not constitute a general advice. Please disregard this email if misdelivered.

_____

From: Ariel Lorenzo-Luaces <arielluaces at gmail.com <mailto:arielluaces at gmail.com> >
Sent: Monday, 1 March 2021 12:07 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK

Hello LORD HIS EXCELLENCY JAMES HRMH

I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com <http://www.go-overt.com>;

At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.

Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.

Cheers

Ariel Lorenzo-Luaces

On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:

Good Evening,

Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin>; on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.

Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.

The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.

KING JAMES HRMH

Great British Empire

Regards,

The Australian

LORD HIS EXCELLENCY JAMES HRMH (& HMRH)

of Hougun Manor & Glencoe & British Empire

MR. Damian A. James Williamson

Wills

et al.

Willtech

www.willtech.com.au

www.go-overt.com

and other projects

earn.com/willtech

linkedin.com/in/damianwilliamson

m. 0487135719

f. +61261470192

This email does not constitute a general advice. Please disregard this email if misdelivered.

_____

From: Jeremy <jlrubin at mit.edu>
Sent: Sunday, 28 February 2021 3:14 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK

I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.

Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.

Do you have a source on your reporting?

You may wish to rescind your nack.

--
@JeremyRubin <https://twitter.com/JeremyRubin>;

On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:

Good Afternoon,

It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.

If that is the case I offer a full NACK and let me explain.

A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.

I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.

KING JAMES HRMH

Great British Empire

Regards,

The Australian

LORD HIS EXCELLENCY JAMES HRMH (& HMRH)

of Hougun Manor & Glencoe & British Empire

MR. Damian A. James Williamson

Wills

et al.

Willtech

www.willtech.com.au <http://www.willtech.com.au>;

www.go-overt.com <http://www.go-overt.com>;

and other projects

earn.com/willtech <http://earn.com/willtech>;

linkedin.com/in/damianwilliamson <http://linkedin.com/in/damianwilliamson>;

m. 0487135719

f. +61261470192

This email does not constitute a general advice. Please disregard this email if misdelivered.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_____

bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

<ip.bitcointalk.org.png>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/3091d805/attachment-0001.html>;

📅 Original date posted:2021-03-03 📝 Original message:> ...

2023-06-07T18:29:26Z

In reply to nevent1q…ch5l
_________________________

📅 Original date posted:2021-03-03
📝 Original message:> consensus requires the ledger to be honest does not prove that it is honest.

Actually, that’s exactly what it does. A logical/mathematical requirement (necessity) is also called a proof.

e

From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
Sent: Tuesday, March 2, 2021 7:06 PM
To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>; Daniel Edgecumbe <email at esotericnonsense.com>
Subject: Re: [bitcoin-dev] Taproot NACK

"Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured."

Good Afternoon,

Requiring little argument I concur, privacy allows that you do not have snoops and researchers following you around looking in your purse as you transact. For the general public, how much you carry in your purse and where you get it from is none of their business. However, your employer is required to report to the government a record of pay, or at least maintain that record, and the store where you made a purchase similarly to keep records so that taxes can be paid. From their perspective, you do not need to know how much they keep in their drawer. Bitcoin directly allows your purse to be private and for the transaction ledger to take the scrutiny anyone should be able to apply to prove the ledger is honest. Maintaining an argument that consensus requires the ledger to be honest does not prove that it is honest.

KING JAMES HRMH

Great British Empire

Regards,

The Australian

LORD HIS EXCELLENCY JAMES HRMH (& HMRH)

of Hougun Manor & Glencoe & British Empire

MR. Damian A. James Williamson

Wills

et al.

Willtech

www.willtech.com.au <http://www.willtech.com.au>;

www.go-overt.com <http://www.go-overt.com>;

and other projects

earn.com/willtech

linkedin.com/in/damianwilliamson

m. 0487135719

f. +61261470192

This email does not constitute a general advice. Please disregard this email if misdelivered.

_____

From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Daniel Edgecumbe via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK

Any "transparency" in the blockchain, beyond that required for a participant to determine valid ownership, can only reasonably be thought of as a bug.

Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured.

Bitcoin is digital cash.

Daniel Edgecumbe | esotericnonsense
email at esotericnonsense.com <mailto:email at esotericnonsense.com> | https://esotericnonsense.com

On Mon, Mar 1, 2021, at 22:37, Eric Voskuil via bitcoin-dev wrote:
> To be clear, is this a NACK because Taproot reduces “transparency”
> (increases privacy) on the chain (“maintaining consensus” is obviously
> an argument against any protocol change, so that’s a red herring)?
>
> And is it your theory that only an “honest” (statute abiding) person
> should have privacy, and not against the state, and/or that mixers are
> sufficient privacy?
>
> Personally, I’m not moved by such an argument. What do you think is the
> value proposition of Bitcoin?
>
> e
>
> > On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> >
> >
> > Good Afternoon,
> >
> > I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
> >
> > My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
> >
> > The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
> >
> > My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
> > <ip.bitcointalk.org.png>
> >
> > [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> > <https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw>; &t=622&c=gTi7r1cfh-yynw
> > from this thread https://bitcointalk.org/index.php?topic=5267588
> >
> >
> > The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
> > https://github.com/jambler-io/bitcoin-mixer
> >
> > The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
> > https://jambler.io/become-partner.php
> >
> > I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
> >
> > If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
> >
> > KING JAMES HRMH
> > Great British Empire
> >
> > Regards,
> > The Australian
> > LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > of Hougun Manor & Glencoe & British Empire
> > MR. Damian A. James Williamson
> > Wills
> >
> > et al.
> >
> >
> > Willtech
> > www.willtech.com.au <http://www.willtech.com.au>;
> > www.go-overt.com <http://www.go-overt.com>;
> > and other projects
> >
> > earn.com/willtech
> > linkedin.com/in/damianwilliamson
> >
> >
> > m. 0487135719
> > f. +61261470192
> >
> >
> > This email does not constitute a general advice. Please disregard this email if misdelivered.
> > *From:* Ariel Lorenzo-Luaces <arielluaces at gmail.com <mailto:arielluaces at gmail.com> >
> > *Sent:* Monday, 1 March 2021 12:07 AM
> > *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
> > *Subject:* Re: [bitcoin-dev] Taproot NACK
> >
> > Hello LORD HIS EXCELLENCY JAMES HRMH
> >
> > I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com <http://www.go-overt.com>;
> >
> > At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
> >
> > Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
> >
> > Cheers
> > Ariel Lorenzo-Luaces
> > On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> >> Good Evening,
> >>
> >> Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin>; on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
> >>
> >> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
> >>
> >> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
> >>
> >> KING JAMES HRMH
> >> Great British Empire
> >>
> >> Regards,
> >> The Australian
> >> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> >> of Hougun Manor & Glencoe & British Empire
> >> MR. Damian A. James Williamson
> >> Wills
> >>
> >> et al.
> >>
> >>
> >> Willtech
> >> www.willtech.com.au <http://www.willtech.com.au>;
> >> www.go-overt.com <http://www.go-overt.com>;
> >> and other projects
> >>
> >> earn.com/willtech
> >> linkedin.com/in/damianwilliamson
> >>
> >>
> >> m. 0487135719
> >> f. +61261470192
> >>
> >>
> >> This email does not constitute a general advice. Please disregard this email if misdelivered.
> >> *From:* Jeremy <jlrubin at mit.edu <mailto:jlrubin at mit.edu> >
> >> *Sent:* Sunday, 28 February 2021 3:14 AM
> >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
> >> *Subject:* Re: [bitcoin-dev] Taproot NACK
> >>
> >> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
> >>
> >> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
> >>
> >> Do you have a source on your reporting?
> >>
> >> You may wish to rescind your nack.
> >>
> >>
> >> --
> >> @JeremyRubin <https://twitter.com/JeremyRubin>; <https://twitter.com/JeremyRubin>;
> >>
> >>
> >> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> >>> Good Afternoon,
> >>>
> >>> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
> >>>
> >>> If that is the case I offer a full NACK and let me explain.
> >>>
> >>> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
> >>>
> >>> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
> >>>
> >>> KING JAMES HRMH
> >>> Great British Empire
> >>>
> >>> Regards,
> >>> The Australian
> >>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> >>> of Hougun Manor & Glencoe & British Empire
> >>> MR. Damian A. James Williamson
> >>> Wills
> >>>
> >>> et al.
> >>>
> >>>
> >>> Willtech
> >>> www.willtech.com.au <http://www.willtech.com.au>;
> >>> www.go-overt.com <http://www.go-overt.com>;
> >>> and other projects
> >>>
> >>> earn.com/willtech
> >>> linkedin.com/in/damianwilliamson
> >>>
> >>>
> >>> m. 0487135719
> >>> f. +61261470192
> >>>
> >>>
> >>> This email does not constitute a general advice. Please disregard this email if misdelivered.
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > <ip.bitcointalk.org.png>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/51f2aabd/attachment-0001.html>;

📅 Original date posted:2020-11-30 📝 Original message:Hi ...

2023-06-07T18:27:37Z

In reply to nevent1q…mqnu
_________________________

📅 Original date posted:2020-11-30
📝 Original message:Hi Sebastian,

It's important to consider here that anonymity is the reason fees are incorporated into transactions. One must generally trust the party with whom one transacts. But since integral fees are paid to any miner, this does not apply to fees. In paying fees externally one must find another way to associate a fee with its transaction. This of course increases the possibility of taint, as you describe in part here:

> Miners that included a transaction need a way to authenticate when claiming the bounty.

It is also the case that the "bounty" must be associated with the transaction. Even with miner and payer mutual anonymity, the fee inputs and outputs will be associated with the transaction inputs and outputs by the miner, rendering the proposal counterproductive.

Total transaction sizing is not reduced by paying fees externally, in fact it would be increased. The only possible reduction would come from aggregation of fees. Yet it is not clear how that aggregation would occur privately in less overall block space. At least with integral fees, it's *possible* to spend and pay a fee with a single input and output. That is not the case with externalized fees.

e

-----Original Message-----
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of Sebastian Geisler via bitcoin-dev
Sent: Monday, November 30, 2020 3:03 PM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: [bitcoin-dev] Out-of-band transaction fees

Hi all,

the possibility of out of band transaction fee payments is a well known fact. Yet it has been mostly discussed as an annoying inevitability that can be problematic if on-chain fees are to be used as a consensus parameter. The potential use cases have seen little interest though (please correct me if I'm wrong).

One such use case is sending UTXOs "intact". Let's assume we get to a point where Bitcoin is primarily a settlement layer for L2 systems.
These L2 systems might want to protect their privacy and keep UTXOs of a common sizes (e.g. 1 BTC, 10 BTC, …). For certain settlement applications these can be transferred as a whole, but currently fee requirements force the system to add another input for fees which will introduce taint (because it's used repeatedly). If instead a fee could be paid out of band in a privacy preserving way the TXO chain would leak little about the intermediate holders.

Taking this concept even further CoinJoin-like protocols could also be used to introduce further ambiguity without leaking that a certain entity took part in the CJ (which fee inputs/reused "toxic waste"
inevitably do afaik). Such a mechanism would probably also make CJ transactions much smaller as _no_ fee inputs had to be provided (assuming the inputs already have the right size).

Out-of-band transaction "accelerators" already exist and taking fee payment out-of-band can not be effectively prevented. So even though any such proposal will probably have slight centralizing effects I believe that having a standard for it is preferable to having every pool implement their own API making it harder for small pools to get into the market.

Imo the central questions are:
* how to build such a out-of-band "transaction bounty" system
* how to standardized it
* how can the centralizing effects from it be mitigated

Imo fees are small enough to not really care about counter party risk that much. It's more important that it is easy to run so that there is some choice for users and miners. In that sense I consider single-operator services providing both standardized user and miner APIs as well as an optional UI suitable. I would still take into account that this could change and might consider the needs of federated services in the protocol.

Each such service would need to announce which means of payment it supports and allow users and miners to choose when paying/redeeming fees. Users should be able to submit transactions and either be presented with a single payment method dependent "invoice" or one per input (for the CoinJoin use case). As soon as all invoices are paid the bounty goes live and is visible to miners through an API.

Miners that included a transaction need a way to authenticate when claiming the bounty. One possibility would be to optionally include a unique public key e.g. in the coinbase scriptsig after the height push (is this feasible?). This could be used to claim any bounties after 100, 120, or even a user-defined confirmation threshold is met. If the key is unique for every block there won't be a problem with pool accountability which might become a risk down the road (so this should also be enforced at least in the bounty protocol to avoid lazy implementations leading to dangerous precedents).

Any feedback is welcome :)

tl;dr Out-of-band fee payment services are inevitable and useful, so we should at least standardize them and mitigate negative effects as much as possible.

Best,
Sebastian

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev