Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

[Eric Voskuil via bitcoin-dev]

Hi John,Honest is a misnomer, which is underpinning the concept. There is nothing dishonest about such payments. The downside is that the payer forgoes anonymity relative to the miner, but this is not dishonest, nor is mining one’s own transactions (where the represented “fee” implies nothing). Assuming a “sufficient fraction” of one of several economically rational behaviors is a design flaw.eOn Dec 28, 2023, at 13:19, jlspc  wrote:Hi Eric,I agree that users can pay miners offchain and miners can create blocks where the difference between inputs and outputs exceeds the fees paid (by mining their own transactions). I model that behavior as dishonest mining. Onchain fees seem to reflect congestion for now, but it's true that FDTs rely on having a sufficient fraction of honest miners.Regards,John






Sent with Proton Mail secure email.



On Friday, December 22nd, 2023 at 8:09 PM, Eric Voskuil  wrote:

The fees paid to mine the set of transactions in a given block are known only to the miner that produced the block. Assuming that tx inputs less outputs represents an actual economic force is an error.eOn Dec 22, 2023, at 09:24, jlspc via bitcoin-dev  wrote:Hi Antoine,

Thanks for your thoughtful response.

Comments inline below:

> Hi John,

> While the idea of using sliding reaction window for blockchain congestion
> detection has been present in the "smart contract" space at large [0] and
> this has been discussed informally among Lightning devs and covenant
> designers few times [1] [2], this is the first and best formalization of
> sliding-time-locks in function of block fee rates for Bitcoin I'm aware
> off, to the best of my knowledge.

Thanks!

> Here my understanding of the feerate-dependent timelock proposal.

> A transaction cannot be included in a block:
> - height-based or epoch-based absolute or relative timelocks are not
> satisfied according to current consensus rules (bip68 and bip 113 and
> implementation details)
> - less than `block_count` has a block median-feerate above the
> median-feerate of the `window_size` period

It's a little bit different from that.
The transaction cannot be included in the blockchain until after an aligned window W of window_size blocks where:
1) W starts no sooner than when the height-based or epoch-based absolute and/or relative timelocks have been satisfied, and
2) W contains fewer than block_count blocks with median feerate greater than feerate_value_bound.

Note that the aligned window cannot start until the absolute and/or relative timelocks have been satisfied and the transaction itself has to come after the aligned window.
However, once such an aligned window exists in the blockchain, the transaction can appear at any later time (and not just within a window that itself meets the block_count and feerate_value_bound limitations).

> A median feerate is computed for each block.
> (This is unclear to me if this is the feerate for half of the block's
> weight or the median feerate with all weight units included in the
> block as the sample)

A feerate F is the median feerate of a block B if F is the largest feerate such that the total size of the transactions in B with feerate greater or equal to F is at least 2 million vbytes.

> From then, you have 3 parameters included in the nSequence field.
> - feerate_value_bound
> - window_size
> - block_count

> Those parameters can be selected by the transaction builder (and
> committed with a signature or hash chain-based covenant).
> As such, off-chain construction counterparties can select the
> feerate_value_bound at which their time-sensitive transaction
> confirmation will be delayed.

> E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage
> HTLC transactions are pre-signed with feerate_value_bound at 100 sat /
> vbytes.
> The window_size selected is 100 blocks and the block_count is 70 (this
> guarantees tampering-robustness of the feerate_value_bound in face of
> miners coalitions).

> There is 1 BTC offered HTLC pending with expiration time T, from Alice to Bob.

> If at time T, the per-block median feerate of at least 70 blocks over
> the latest 100 block is above 100 sat / vbytes, any Alice's
> HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain.

The rules are actually:
1) wait until time T, then
2) wait until the start of a full aligned window W with 100 consecutive blocks that starts no earlier than T and that has fewer than 70 blocks with median feerate above 100 sats/vbyte.
(The values 100, 70, and 100 cannot actually be selected in the implementation in the paper, but that's a technical detail and could be changed if the FDT is specified in the annex, as you propose.)

> From my understanding, Feerate-Dependent Timelocks effectively
> constitute the lineaments of a solution to the "Forced Expiration
> Spam" as described in the LN paper.

Great!

> I think you have few design caveats to b

Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

[Eric Voskuil via bitcoin-dev]

The fees paid to mine the set of transactions in a given block are known only to the miner that produced the block. Assuming that tx inputs less outputs represents an actual economic force is an error.eOn Dec 22, 2023, at 09:24, jlspc via bitcoin-dev  wrote:Hi Antoine,

Thanks for your thoughtful response.

Comments inline below:

> Hi John,

> While the idea of using sliding reaction window for blockchain congestion
> detection has been present in the "smart contract" space at large [0] and
> this has been discussed informally among Lightning devs and covenant
> designers few times [1] [2], this is the first and best formalization of
> sliding-time-locks in function of block fee rates for Bitcoin I'm aware
> off, to the best of my knowledge.

Thanks!

> Here my understanding of the feerate-dependent timelock proposal.

> A transaction cannot be included in a block:
> - height-based or epoch-based absolute or relative timelocks are not
> satisfied according to current consensus rules (bip68 and bip 113 and
> implementation details)
> - less than `block_count` has a block median-feerate above the
> median-feerate of the `window_size` period

It's a little bit different from that.
The transaction cannot be included in the blockchain until after an aligned window W of window_size blocks where:
1) W starts no sooner than when the height-based or epoch-based absolute and/or relative timelocks have been satisfied, and
2) W contains fewer than block_count blocks with median feerate greater than feerate_value_bound.

Note that the aligned window cannot start until the absolute and/or relative timelocks have been satisfied and the transaction itself has to come after the aligned window.
However, once such an aligned window exists in the blockchain, the transaction can appear at any later time (and not just within a window that itself meets the block_count and feerate_value_bound limitations).

> A median feerate is computed for each block.
> (This is unclear to me if this is the feerate for half of the block's
> weight or the median feerate with all weight units included in the
> block as the sample)

A feerate F is the median feerate of a block B if F is the largest feerate such that the total size of the transactions in B with feerate greater or equal to F is at least 2 million vbytes.

> From then, you have 3 parameters included in the nSequence field.
> - feerate_value_bound
> - window_size
> - block_count

> Those parameters can be selected by the transaction builder (and
> committed with a signature or hash chain-based covenant).
> As such, off-chain construction counterparties can select the
> feerate_value_bound at which their time-sensitive transaction
> confirmation will be delayed.

> E.g let's say you have a LN-penalty Alice-Bob channel. Second-stage
> HTLC transactions are pre-signed with feerate_value_bound at 100 sat /
> vbytes.
> The window_size selected is 100 blocks and the block_count is 70 (this
> guarantees tampering-robustness of the feerate_value_bound in face of
> miners coalitions).

> There is 1 BTC offered HTLC pending with expiration time T, from Alice to Bob.

> If at time T, the per-block median feerate of at least 70 blocks over
> the latest 100 block is above 100 sat / vbytes, any Alice's
> HTLC-timeout or Bob's HTLC-preimage cannot be included in the chain.

The rules are actually:
1) wait until time T, then
2) wait until the start of a full aligned window W with 100 consecutive blocks that starts no earlier than T and that has fewer than 70 blocks with median feerate above 100 sats/vbyte.
(The values 100, 70, and 100 cannot actually be selected in the implementation in the paper, but that's a technical detail and could be changed if the FDT is specified in the annex, as you propose.)

> From my understanding, Feerate-Dependent Timelocks effectively
> constitute the lineaments of a solution to the "Forced Expiration
> Spam" as described in the LN paper.

Great!

> I think you have few design caveats to be aware off:
> - for current LN-penalty, the revokeable scripts should be modified to
> ensure the CSV opcode inspect the enforcement of FDT's parameters, as
> those revokeable scripts are committed by all parties

Yes, definitely.

> - there should be a delay period at the advantage of one party
> otherwise you still a feerate-race if the revocation bip68 timelock
> has expired during the FDT delay

> As such, I believe the FDT parameters should be enriched with another
> parameter : `claim_grace_period`, a new type of relative timelock of
> which the endpoint should be the `feerate_value_bound` itself.

I'm not sure I'm following your proposal.
Are you suggesting that the transaction with the FDT has to wait an additional claim_grace_period in order to allow conflicting transactions from the other party to win the race?
For example, assume the HTLC-success transaction has a higher feerate than the feerate_value_bound, and the conflicting HTLC-timeout transaction has an FDT with th

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

> -Original Message-
> From: Anthony Towns 
> 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

> From: Anthony Towns 
> 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
n

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

>> ...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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

>> [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.]
> 
> The only message listed as not being preceded by a bumped version number
> in:
> 
> https://github.com/libbitcoin/libbitcoin-network/wiki/Protocol-Versioning

Good find, still a work in progress.

> is addrv2 (though addrv2 is gated on mutual exchange of sendaddrv2, so
> it's presumably the sendaddrv2 message at issue),

addrv2 is listed as the BIP title, the message that would cause the break is 
sendaddrv2 (quoted text).

> however since [0]
> 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?

> ADDRV2 was introduced May 20 2020 after the
> 0.20 branch, and SENDADDRV2 gating was merged Dec 9 2020 and included
> from 0.21.0rc3 onwards.

To clarify, there was no Core release of addrv2 without sendaddrv2 apart from 
0.21 release candidates?

> [0] https://github.com/bitcoin/bitcoin/pull/20564
> 
> I'm only seeing "bytesrecv_per_msg.*other*" entries for nodes advertising
> a version of 0.17 and 0.18,

> which I presume is due to REJECT messages (for taproot txs, perhaps?).

Ideally you should not be seeing reject messages as protocol “other”, as these 
are valid messages as of protocol version 70002, and they are excluded by 
negotiated version before that. While there is no requirement to send them 
(BIP61 only defines a new message type), they remain defined messages until 
removed by a future protocol version.

> Otherwise, I don't think there are any unexpected
> messages you should be receiving when advertising version 70015 or lower.

Yet nodes with an advertised protocol version of 70013 are receiving 
sendaddrv2. I've removed the IP address from the log extract below.

17:53:45.022347 DEBUG [network] Peer [x.x.x.x:8333] protocol version (70016) 
user agent: /Satoshi:0.21.0()/
17:53:45.022377 DEBUG [network] Negotiated protocol version (70013) for 
[x.x.x.x.135:8333]
17:53:45.022767 INFO [network] Connected outbound channel [x.x.x.x.135:8333]
17:53:45.022913 DEBUG [node] Ask [x.x.x.x:8333] for headers after 
[0002e8c1c59fc86f721ba3a3294d2b1165597ddb910058e6]
17:53:45.023184 WARNING [network] Invalid sendaddrv2 payload from 
[x.x.x.x:8333] object does not exist
17:53:45.023317 DEBUG [network] Stop protocol version on [x.x.x.x:8333] object 
does not exist
17:53:45.023359 DEBUG [network] Outbound channel stopped [x.x.x.x:8333] success

To my knowledge the only other time we've seen consistent invalid message 
traffic on the network was during the work on BIP150 (withdrawn), at which 
point BIP150 nodes were being deployed on mainnet. I made comments here on the 
issue at the time, which as I recall were generally rejected in favor of 
forcing nodes to allow all invalid traffic. In any case BIP150 was withdrawn 
and BIP324 proposed, which fixes this particular issue (using a service bit).

Some argued at the time that allowance for invalid messages was a longstanding 
requirement in the protocol. I knew that this was not the case (except for 
BIP37, break documented in BIP60) because libbitcoin validates all messages, 
which led me to eventually document it. Recently I updated and posted that 
documentation (the github wiki link you found). This was a consequence of 
reviewing the Generic Package Relay proposal, which is also incompatible. In 
doing so I noticed this issue with BIP155 and BIP330 as well. This led us to 
check the logs for peer disconnects as a result of invalid messages, at which 
point the above was found to be an increasingly common occurrence.

Best,
e

> Cheers,
> aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

> 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

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

Thanks again for the feedback. Comments inline.

> On Sep 27, 2022, at 02:29, alicexbt  wrote:
> 
> Hi Eric,
> 
> 
>> 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.
> 
> Matt Corallo mentioned that pre-signed transactions created with low fee rate 
> become an issue when they are broadcasted after a long time and there is a 
> high demand for block space at that moment.

Yes, I understood this. There are many ways that a fee may be created which is 
too low for propagation.

> Example: 
> 
> Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte however 
> its taking hours/days to confirm the transaction with such low fee rate.
> 
> Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 
> sat/vbyte) for spending same inputs. She broadcasted PSBT3 which got 
> confirmed in a few minutes. 
> 
> 
>> 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.
> 
> 
> `minfeefilter` for all peers of my node was 0.1000 at the time of writing 
> this email. I am assuming nobody creates pre-signed transaction with fee rate 
> below 1 sat/vbyte. How often does it happen that `minfeefilter` is above this 
> default value?

I don’t consider node configuration relevant, regardless of its apparent 
consistency.

>> 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.
> 
> 
> Sorry that sentence was confusing. Yes complexity isn't justified for CPFP 
> fee-bumping txs below minimum fee rate.
> 
> 
>> There are many node implementations used presently. And of course these are 
>> protocol proposals, which presumes more than one implementation.
> 
> 
> Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) 
> however they aren't used by lot of nodes. Based on this [chart][1] 98% nodes 
> use bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin 
> core contributors and things could be different if even 30% nodes used other 
> implementations.

I don’t consider such a measure relevant. This is a protocol consideration. 
Also consider that many nodes are not visible, and aspects of nodes, such as 
for p2p communication, are embedded into applications such as wallets - which 
could easily exceed the number of visible nodes.

>> 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.
> 
> 
> Agree, miners should be expected to select most optimal set of txs. However, 
> according to one [comment][2] by Pieter Wuille, miners could affect the 
> security of some bitcoin projects with MEV.

This would be a deficiency in such projects, by assuming economic 
irrationality. The fact that fees will become a greater percentage of the block 
reward is a surprise to no one.

>> 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.
> 
> I completely agree with this.
> 
> 
> [1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
> [2]: 
> https://bitcoin.stackexchange.com/questions/107787/front-running-in-bitcoin#comment123441_107796
> 
> 
> /dev/fd0
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

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  d...@lists.linuxfoundation.org> wrote:
> 
> 
> > Hi Suhas/Gloria,
> >
> > Good questions. I've started a

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

[Eric Voskuil via bitcoin-dev]

If there’s no block reward, there’s no Bitcoin, so that’s moot. But setting 
that aside. The business model of the state is to preserve the reward it 
obtains from its own money. This is the reason for currency controls, which are 
common.

e

> On Jul 20, 2022, at 03:17, Peter via bitcoin-dev 
>  wrote:
> 
> >And therefore this reduces to the simple fact that tx fees are what 
> provides censorship resistance, whether you mine your own or others?.
> 
> 
> What's the business model of the person who mines with the intention to 
> censor transactions when there's no block reward?
> 
> 
> 
> Regards
> 
> Peter Kroll
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

> On Jul 18, 2022, at 14:14, Erik Aronesty via bitcoin-dev 
>  wrote:
> 
> 
>> 
>> subsidy to directly tie miner revenue to the total value of Bitcoin 
>> makes it not exactly how we want to incentivise a service that keeps 
>> 
> 
> again, this is meaningless.   if the fees aren't enough to keep  bitcoin 
> secure for large transactions, then large holders are incentivised to mine

Yes, this is another way to pay the tx fee - you mine at cost sufficient to 
overpower the censor. You are spending the block reward in getting your txs 
confirmed, and that’s your fee.

But unless you are mining full blocks of only your own transactions, this 
implies that you are accepting these higher fees on censored txs from others. 
Otherwise you are simply mining at a loss, which we cannot use as a rational 
basis for security.

And therefore this reduces to the simple fact that tx fees are what provides 
censorship resistance, whether you mine your own or others’.

e

> that's it.
> 
> it's not complicated
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]


> On Jul 10, 2022, at 07:17, alicexbt  wrote:
> Hi ZmnSCPxj,
> 
> 
>> Thus, we should instead prepare for a future where the block subsidy must be 
>> removed, possibly before the existing schedule removes it, in case a 
>> majority coalition of miner ever decides to censor particular transactions 
>> without community consensus.
>> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to 
>> deploy.
> 
> `consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can 
> be decreased to 195000. This will reduce the number of halvings from 34 to 14 
> and subsidy will be 0 when it becomes less than 0.01 although not sure if 
> this will be a soft fork.

Soft fork, though a bit aggressive, as it would invalidate all existing blocks 
above the first new halving height block which claimed more than the reduced 
reward.

Increasing the value would be a hard fork, as it would validate blocks that 
would previously have been invalid, as opposed to a soft fork, which 
invalidates blocks that would previously have been valid.

e

> I doubt there will be consensus for it because all the [projections and 
> predictability][2] about bitcoin(currency) would be affected by this change. 
> Maybe everyone can agree with this change if most of the miners start being 
> 'compliant' like one of the coinjoin implementation.
> 
> [1]: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L66
> [2]: https://en.bitcoin.it/wiki/Controlled_supply
> 
> 
> /dev/fd0
> 
> Sent with Proton Mail secure email.
> 
> --- Original Message ---
> On Saturday, July 9th, 2022 at 9:59 PM, ZmnSCPxj via bitcoin-dev 
>  wrote:
> 
> 
>> Good morning e, and list,
>> 
>>> Yet you posted several links which made that specific correlation, to which 
>>> I was responding.
>>> Math cannot prove how much coin is “lost”, and even if it was provable that 
>>> the amount of coin lost converges to the amount produced, it is of no 
>>> consequence - for the reasons I’ve already pointed out. The amount of 
>>> market production has no impact on market price, just as it does not with 
>>> any other good.
>>> The reason to object to perpetual issuance is the impact on censorship 
>>> resistance, not on price.
>> 
>> 
>> To clarify about censorship resistance and perpetual issuance ("tail 
>> emission"):
>> 
>> * Suppose I have two blockchains, one with a constant block subsidy, and one 
>> which had a block subsidy but the block subsidy has become negligible or 
>> zero.
>> * Now consider a censoring miner.
>> * If the miner rejects particular transactions (i.e. "censors") the miner 
>> loses out on the fees of those transactions.
>> * Presumably, the miner does this because it gains other benefits from the 
>> censorship, economically equal or better to the earnings lost.
>> * If the blockchain had a block subsidy, then the loss the miner incurs is 
>> small relative to the total earnings of each block.
>> * If the blockchain had 0 block subsidy, then the loss the miner incurs is 
>> large relative to the total earnings of each block.
>> * Thus, in the latter situation, the external benefit the miner gains from 
>> the censorship has to be proportionately larger than in the first situation.
>> 
>> Basically, the block subsidy is a market distortion: the block subsidy 
>> erodes the value of held coins to pay for the security of coins being moved.
>> But the block subsidy is still issued whether or not coins being moved are 
>> censored or not censored.
>> Thus, there is no incentive, considering only the block subsidy, to not 
>> censor coin movements.
>> Only per-transaction fees have an incentive to not censor coin movements.
>> 
>> 
>> Thus, we should instead prepare for a future where the block subsidy must be 
>> removed, possibly before the existing schedule removes it, in case a 
>> majority coalition of miner ever decides to censor particular transactions 
>> without community consensus.
>> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to 
>> deploy.
>> 
>> 
>> Regards,
>> ZmnSCPxj
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

In Bitcoin we use the term “supply“ as a reference to the number of coins 
minted. This colloquialism is commonly conflated with the economic concept of 
supply, and then injected into a supply/demand relation as if it had the same 
applicability. Economically supply refers to desire to sell, while demand 
refers to desire to buy.

e

> On Jul 9, 2022, at 08:24, Eric Voskuil  wrote:
> 
> To clarify, price inflation is not caused by market production. Attributing 
> the observed lack of inflation (eg fee %) to loss is an assumed relation.
> 
> Even if the amount of loss was known (which it is not), there remains an 
> assumption in the correlation of non-lost coins to price. Demand determines 
> price, not the amount of something in existence, hence the folly of S2F 
> (1/monetary-inflation).
> 
> e
> 
>> On Jul 9, 2022, at 08:15, Peter Todd  wrote:
>> On Sat, Jul 09, 2022 at 07:26:22AM -0700, Eric Voskuil wrote:
 Due to lost coins, a tail emission/fixed reward actually results in a 
 stable money supply. Not an (monetarily) inflationary supply.
>>> This observation is not a proof of lost coins, that is an assumption.
>> To be clear, are you claiming that there is no proof that coins are lost?
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

Yet you posted several links which made that specific correlation, to which I 
was responding.

Math cannot prove how much coin is “lost”, and even if it was provable that the 
amount of coin lost converges to the amount produced, it is of no consequence - 
for the reasons I’ve already pointed out. The amount of market production has 
no impact on market price, just as it does not with any other good.

The reason to object to perpetual issuance is the impact on censorship 
resistance, not on price.

e

> On Jul 9, 2022, at 08:31, Peter Todd  wrote:
> On Sat, Jul 09, 2022 at 08:24:51AM -0700, Eric Voskuil wrote:
>> To clarify, price inflation is not caused by market production. Attributing 
>> the observed lack of inflation (eg fee %) to loss is an assumed relation.
> 
> My article is a mathematical proof that has nothing to do with observations of
> inflation.
> 
> What I did is prove that if there is tail emission/fixed supply, the coin
> supply will converge towards a fixed amount because the coin supply dependant
> rate of coin loss balances out the fixed rate of coin production.
> 
> That proof has nothing to do with market dynamics and would happen in any
> system, economic or not, with similar underlying dynamics.
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org



signature.asc
Description: Binary data

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

To clarify, price inflation is not caused by market production. Attributing the 
observed lack of inflation (eg fee %) to loss is an assumed relation.

Even if the amount of loss was known (which it is not), there remains an 
assumption in the correlation of non-lost coins to price. Demand determines 
price, not the amount of something in existence, hence the folly of S2F 
(1/monetary-inflation).

e

> On Jul 9, 2022, at 08:15, Peter Todd  wrote:
> 
> On Sat, Jul 09, 2022 at 07:26:22AM -0700, Eric Voskuil wrote:
>>> Due to lost coins, a tail emission/fixed reward actually results in a 
>>> stable money supply. Not an (monetarily) inflationary supply.
>> 
>> This observation is not a proof of lost coins, that is an assumption.
> 
> To be clear, are you claiming that there is no proof that coins are lost?
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Binary data
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

> Due to lost coins, a tail emission/fixed reward actually results in a stable 
> money supply. Not an (monetarily) inflationary supply.

This observation is not a proof of lost coins, that is an assumption. It is the 
provable consequence of market, as opposed to monopoly, production.

https://github.com/libbitcoin/libbitcoin-system/wiki/Inflation-Principle

Mises’ unfortunate error in the application of the Cantillon Effect to gold 
perpetuates this misperception. One could imagine applying this theory to all 
goods, not just money, and conclude perpetual loss of value in everything 
produced, as a consequence of production. One might then be tempted to 
attribute the fact that this is not observable to 
loss/depreciation/consumption. While it is certainly possible that the amount 
of gold produced every year is offset by the amount lost, this of course 
implies that all of it is lost.

“Circulation” does not determine demand, all money is always held by someone. 
Changing hands only changes who owns the money, not its purchasing power. See 
Rothbard’s critique of monetary “velocity”.

e

> On Jul 9, 2022, at 05:47, Peter Todd via bitcoin-dev 
>  wrote:
> 
> New blog post:
> 
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
> 
> tl;dr: Due to lost coins, a tail emission/fixed reward actually results in a
> stable money supply. Not an (monetarily) inflationary supply.
> 
> ...and for the purposes of reply/discussion, attached is the article itself in
> markdown format:
> 
> ---
> layout: post
> title:  "Surprisingly, Tail Emission Is Not Inflationary"
> date:   2022-07-09
> tags:
> - bitcoin
> - monero
> ---
> 
> At present, all notable proof-of-work currencies reward miners with both a 
> block
> reward, and transaction fees. With most currencies (including Bitcoin) phasing
> out block rewards over time. However in no currency have transaction fees
> consistently been more than 5% to 10% of the total mining
> reward[^fee-in-reward], with the exception of Ethereum, from June 2020 to Aug 
> 2021.
> To date no proof-of-work currency has ever operated solely on transaction
> fees[^pow-tweet], and academic analysis has found that in this condition block
> generation is unstable.[^instability-without-block-reward] To paraphrase 
> Andrew
> Poelstra, it's a scary phase change that no other coin has gone 
> through.[^apoelstra-quote]
> 
> [^pow-tweet]: [I asked on 
> Twitter](https://twitter.com/peterktodd/status/1543231264597090304) and 
> no-one replied with counter-examples.
> 
> [^fee-in-reward]: [Average Fee Percentage in Total Block 
> Reward](https://bitinfocharts.com/comparison/fee_to_reward-btc-eth-bch-ltc-doge-xmr-bsv-dash-zec.html#alltime)
> 
> [^instability-without-block-reward]: [On the Instability of Bitcoin Without 
> the Block 
> Reward](https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf)
> 
> [^apoelstra-quote]: [From a panel at TABConf 
> 2021](https://twitter.com/peterktodd/status/1457066946898317316)
> 
> Monero has chosen to implement what they call [tail
> emission](https://www.getmonero.org/resources/moneropedia/tail-emission.html):
> a fixed reward per block that continues indefinitely. Dogecoin also has a 
> fixed
> reward, which they widely - and incorrectly - refer to as an "abundant" 
> supply[^dogecoin-abundant].
> 
> [^dogecoin-abundant]: Googling "dogecoin abundant" returns dozens of hits.
> 
> This article will show that a fixed block reward does **not** lead to an
> abundant supply. In fact, due to the inevitability of lost coins, a fixed
> reward converges to a **stable** monetary supply that is neither inflationary
> nor deflationary, with the total supply proportional to rate of tail emission
> and probability of coin loss.
> 
> Credit where credit is due: after writing the bulk of this article I found out
> that Monero developer [smooth_xmr](https://www.reddit.com/user/smooth_xmr/)
> also observed that tail emission results in a stable coin supply
> [a few years 
> ago](https://www.reddit.com/r/Monero/comments/4z0azk/maam_28_monero_ask_anything_monday/d6sixyi/).
> There's probably others too: it's a pretty obvious result.
> 
> 
> 
> # Contents
> {:.no_toc}
> 0. TOC
> {:toc}
> 
> 
> ## Modeling the Fixed-Reward Monetary Supply
> 
> Since the number of blocks is large, we can model the monetary supply as a
> continuous function $$N(t)$$, where $$t$$ is a given moment in time. If the
> block reward is fixed we can model the reward as a slope $$k$$ added to an
> initial supply $$N_0$$:
> 
> $$
> N(t) = N_0 + kt
> $$
> 
> Of course, this isn't realistic as coins are constantly being lost due to
> deaths, forgotten passphrases, boating accidents, etc. These losses are
> independent: I'm not any more or less likely to forget my passphrase because
> you recently lost your coins in a boating accident — an accident I probably
> don't even know happened. Since the number of individual coins (and their
> owners) is large — as with the number of 

Re: [bitcoin-dev] No Order Mnemonic

[Eric Voskuil via bitcoin-dev]

Without a performance requirement there is no reason you can’t store the BIP39 
words in any order you want. So it’s certainly possible, just brute force the 
recovery. If you have less than a second vs. a few days then it’s a different 
question.

e

> On Jul 7, 2022, at 18:48, Bram Cohen via bitcoin-dev 
>  wrote:
> 
> Part of the rules of my challenge is that the 'new' words need to be in the 
> same pool as the 'old' words, so any ordering is okay. Without that 
> requirement it's mathematically very straightforward.
> 
>> On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak  wrote:
>> There is. Just encode the index of permutation used to scramble the 
>> otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3 
>> words should be enough. 
>> 
>> Repetitions make this more difficult, though. 
>> 
>>> On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev 
>>>  wrote:
 On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev 
  wrote:
>>> 
 I made a python implementation for a different mnemonic encoding. The 
 encoding requires user to remember words but not the order of those words.
 The code is open (MIT license) at https://github.com/sancoder/noomnem
>>> 
>>> Thanks Anton. There's an interesting mathematical question of whether it's 
>>> possible to make a code like this which always uses the BIP-39 words for 
>>> the same key as part of its encoding, basically adding a few words as error 
>>> correction in case the order is lost or confused. If the BIP-39 contains a 
>>> duplicate you can add an extra word.
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> -- 
>> Best Regards / S pozdravom,
>> 
>> Pavol "stick" Rusnak
>> Co-Founder, SatoshiLabs
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil via bitcoin-dev]

>> These are the two factors, demand and time. Less demand implies more time to 
>> secure a given amount against double spend, and also implies a lower cost to 
>> subsidize a censorship regime. But the latter requires a differential in 
>> reward between the censor and non-censoring miners. While this could be paid 
>> in side fees, that is a significant anonymity issue.
>> 
>> e
>> 
>>>> On Jul 7, 2022, at 10:37, Erik Aronesty  wrote:
>>>> 
>>> 
>>> > > We should not imbue real technology with magical qualities.
>>> 
>>> > Precisely. It is economic forces (people), not technology, that provide 
>>> > security.
>>> 
>>> Yes, and these forces don't prevent double-spend / 51% attacks if the 
>>> amounts involved are greater than the incentives.
>>> 
>>> In addition to "utility", lowering the block size could help prevent this 
>>> issue as well... increasing fee pressure and double-spend security while 
>>> reducing the burden on node operators.
>>> 
>>> Changes to inflation are, very likely, off the table.
>>> 
>>>  
>>> 
>>>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev 
>>>>  wrote:
>>>> 
>>>> 
>>>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev 
>>>> >  wrote:
>>>> > 
>>>> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev 
>>>> > wrote:
>>>> >> Billy,
>>>> >> 
>>>> >> Proof of work and the difficulty adjustment function solve literally
>>>> >> everything you are talking about already.
>>>> > 
>>>> > Unfortunately you are quite wrong: the difficulty adjustment function 
>>>> > merely
>>>> > adjusts for changes in the amount of observable, non-51%-attacking, 
>>>> > hashing
>>>> > power. In the event of a chain split, the difficulty adjustment function 
>>>> > does
>>>> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
>>>> > against a censor, the difficulty adjustment does nothing.
>>>> 
>>>> Consider falling hash rate due to a perpetual 51% attack. Difficulty 
>>>> falls, possibly to min difficulty if all non-censors stop mining and with 
>>>> all censors collaborating (one miner). Yet as difficulty falls, so does 
>>>> the cost of countering the censor. At min difficulty everyone can CPU mine 
>>>> again.
>>>> 
>>>> Given the presumption that fees rise on unconfirmed transactions, there is 
>>>> inherent economic incentive to countering at any level of difficulty. 
>>>> Consequently the censor is compelled to subsidize the loss resulting from 
>>>> forgoing higher fee transactions that are incentivizing its competition.
>>>> 
>>>> With falling difficulty this incentive is compounded.
>>>> 
>>>> Comparisons of security in different scenarios presume a consistent level 
>>>> of demand. If that demand is insufficient to offset the censor’s subsidy, 
>>>> there is no security in any scenario.
>>>> 
>>>> Given that the block subsidy (inflation) is paid equally to censoring and 
>>>> non-censoring miners, it offers no security against censorship whatsoever. 
>>>> Trading fee-based block reward for inflation-based is simply trading 
>>>> censorship resistance for the presumption of double-spend security. But of 
>>>> course, a censor can double spend profitably in any scenario where the 
>>>> double spend value (to the censor) exceeds that of blocks orphaned (as the 
>>>> censor earns 100% of all block rewards).
>>>> 
>>>> Banks and state monies offer reasonable double spend security. Not sure 
>>>> that’s a trade worth making.
>>>> 
>>>> It’s not clear to me that Satoshi understood this relation. I’ve seen no 
>>>> indication of it. However the decision to phase out subsidy, once a 
>>>> sufficient number of units (to assure divisibility) had been issued, is 
>>>> what transitions Bitcoin from a censorable to a censorship resistant 
>>>> money. If one does not believe there is sufficient demand for such a 
>>>> money, there is no way to reconcile that belief with a model of censorship 
>>>> resistance.
>>>> 
>>>> > We 

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil via bitcoin-dev]

It’s not clear how reducing block size changes the fee aspect of the block 
reward. Assuming half the space implies twice the fee per avg tx the reward 
remains constant.

Any additional cost of processing more or less bytes would not matter, because 
of course this is just a cost that gets nulled out by difficulty — average 
profit (net income) is the cost of capital.

The reason for smaller vs. larger blocks is to ensure that individuals can 
afford to validate. That’s a threshold criteria.

Given unlimited size blocks, miners would still have to fix a point in time to 
mine, gathering as much fee as they can optimize in some time period presumably 
less than 10 minutes. The produces a limit to transaction volume, yet neither 
reward nor profit would be affected given the above assumptions. The difference 
would be in a tradeoff of per tx fee against the threshold.

Given Moore’s Law, that threshold is constantly decreasing, which will make it  
cheaper over time for more individuals to validate. But the difference for 
miners for smaller blocks is largely inconsequential relative to their other 
costs.

Increasing demand is the only thing that increases double spend security (and 
censorship resistance assuming fee-based reward). With rising demand there is 
rising overall hash rate, despite block reward and profit remaining constant. 
This makes the cost of attempting to orphan a block higher, therefore lowering 
the depth/time requirement implied to secure a given tx amount.

These are the two factors, demand and time. Less demand implies more time to 
secure a given amount against double spend, and also implies a lower cost to 
subsidize a censorship regime. But the latter requires a differential in reward 
between the censor and non-censoring miners. While this could be paid in side 
fees, that is a significant anonymity issue.

e

> On Jul 7, 2022, at 10:37, Erik Aronesty  wrote:
> 
> 
> > > We should not imbue real technology with magical qualities.
> 
> > Precisely. It is economic forces (people), not technology, that provide 
> > security.
> 
> Yes, and these forces don't prevent double-spend / 51% attacks if the amounts 
> involved are greater than the incentives.
> 
> In addition to "utility", lowering the block size could help prevent this 
> issue as well... increasing fee pressure and double-spend security while 
> reducing the burden on node operators.
> 
> Changes to inflation are, very likely, off the table.
> 
>  
> 
>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev 
>>  wrote:
>> 
>> 
>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev 
>> >  wrote:
>> > 
>> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev 
>> > wrote:
>> >> Billy,
>> >> 
>> >> Proof of work and the difficulty adjustment function solve literally
>> >> everything you are talking about already.
>> > 
>> > Unfortunately you are quite wrong: the difficulty adjustment function 
>> > merely
>> > adjusts for changes in the amount of observable, non-51%-attacking, hashing
>> > power. In the event of a chain split, the difficulty adjustment function 
>> > does
>> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
>> > against a censor, the difficulty adjustment does nothing.
>> 
>> Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, 
>> possibly to min difficulty if all non-censors stop mining and with all 
>> censors collaborating (one miner). Yet as difficulty falls, so does the cost 
>> of countering the censor. At min difficulty everyone can CPU mine again.
>> 
>> Given the presumption that fees rise on unconfirmed transactions, there is 
>> inherent economic incentive to countering at any level of difficulty. 
>> Consequently the censor is compelled to subsidize the loss resulting from 
>> forgoing higher fee transactions that are incentivizing its competition.
>> 
>> With falling difficulty this incentive is compounded.
>> 
>> Comparisons of security in different scenarios presume a consistent level of 
>> demand. If that demand is insufficient to offset the censor’s subsidy, there 
>> is no security in any scenario.
>> 
>> Given that the block subsidy (inflation) is paid equally to censoring and 
>> non-censoring miners, it offers no security against censorship whatsoever. 
>> Trading fee-based block reward for inflation-based is simply trading 
>> censorship resistance for the presumption of double-spend security. But of 
>> course, a censor can double spend profitably in any scenario where the 
>> double spend v

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil via bitcoin-dev]

> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev 
>  wrote:
> 
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev 
> wrote:
>> Billy,
>> 
>> Proof of work and the difficulty adjustment function solve literally
>> everything you are talking about already.
> 
> Unfortunately you are quite wrong: the difficulty adjustment function merely
> adjusts for changes in the amount of observable, non-51%-attacking, hashing
> power. In the event of a chain split, the difficulty adjustment function does
> nothing; against a 51% attacker, the difficulty adjustment does nothing;
> against a censor, the difficulty adjustment does nothing.

Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, 
possibly to min difficulty if all non-censors stop mining and with all censors 
collaborating (one miner). Yet as difficulty falls, so does the cost of 
countering the censor. At min difficulty everyone can CPU mine again.

Given the presumption that fees rise on unconfirmed transactions, there is 
inherent economic incentive to countering at any level of difficulty. 
Consequently the censor is compelled to subsidize the loss resulting from 
forgoing higher fee transactions that are incentivizing its competition.

With falling difficulty this incentive is compounded.

Comparisons of security in different scenarios presume a consistent level of 
demand. If that demand is insufficient to offset the censor’s subsidy, there is 
no security in any scenario.

Given that the block subsidy (inflation) is paid equally to censoring and 
non-censoring miners, it offers no security against censorship whatsoever. 
Trading fee-based block reward for inflation-based is simply trading censorship 
resistance for the presumption of double-spend security. But of course, a 
censor can double spend profitably in any scenario where the double spend value 
(to the censor) exceeds that of blocks orphaned (as the censor earns 100% of 
all block rewards).

Banks and state monies offer reasonable double spend security. Not sure that’s 
a trade worth making.

It’s not clear to me that Satoshi understood this relation. I’ve seen no 
indication of it. However the decision to phase out subsidy, once a sufficient 
number of units (to assure divisibility) had been issued, is what transitions 
Bitcoin from a censorable to a censorship resistant money. If one does not 
believe there is sufficient demand for such a money, there is no way to 
reconcile that belief with a model of censorship resistance.

> We should not imbue real technology with magical qualities.

Precisely. It is economic forces (people), not technology, that provide 
security.

e

>> Bitcoin does not need active economic governanance by devs or meddlers.
> 
> Yes, active governance would definitely be an exploitable mechanism. On the
> other hand, the status quo of the block reward eventually going away entirely
> is obviously a risky state change too.
> 
 There is also zero agreement on how much security would constitute such
>>> an optimum.
>>> 
>>> This is really step 1. We need to generate consensus on this long before
>>> the block subsidy becomes too small. Probably in the next 10-15 years. I
>>> wrote a paper
> 
> The fact of the matter is that the present amount of security is about 1.7% of
> the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also
> already an amount low enough that it's much smaller than economic volatility.
> 
> Obviously 0% is too small.
> 
> There's zero reason to stress about finding an "optimal" amount. An amount low
> enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5%
> would probably be fine; 0.1% would probably be fine.
> 
> Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax 
> on
> savings; 0.1% works out to be 7.2%
> 
> These are all amounts that are likely to be dwarfed by economic shifts.
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


signature.asc
Description: Binary data
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Eric Voskuil via bitcoin-dev]

> On Jun 21, 2022, at 12:28, Keagan McClelland via bitcoin-dev 
>  wrote:
> 
> 
> > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the
> value of BTC they hold; if Bitcoin blocks aren't reliably created the value of
> *all* BTC goes down. It doesn't make sense for the entire cost of that 
> security
> to be paid for on a per-tx basis.

Actually it does. People who transact are realizing the benefit of money - the 
avoidance of barter costs. Those who never transact, never realize any benefit.

> And there's a high chance paying for it on a
> per-tx basis won't work anyway due to lack of consistent demand.
> 
> FWIW I prefer the demurrage route. Having something with finite supply as a 
> means of measuring economic activity is unprecedented and I believe deeply 
> important. I'm sympathetic to the argument that the security of the chain 
> should not be solely the responsibility of transactors.

Chain security - censorship resistance (as opposed to individual double-spend 
security), is entirely dependent upon tx fees.

> We realize the value of money on receipt, hold *and* spend and it would be 
> appropriate for there to be a balance of fees to that effect.

There is zero point in saving if you never spend. You can instead just burn 
your coin.

> While inflation may be simpler to implement (just chop off the last few 
> halvings), I think it would be superior (on the assumption that such a hodl 
> tax was necessary) to keep the supply fixed and have people's utxo balances 
> decay, at least at the level of the UX.

A hoard decays naturally due to opportunity cost. Investing it requires 
transaction to invest, and transaction to earn (profit), and transaction to 
return it (interest).

> But also none of this should be reasons we don't improve Bitcoin's value (and 
> therefore demand)

Demand is the only reason we save, and eventually transacting is the only 
motivation for saving. No transacting implies no demand - and no security.

e

> Keagan
> 
>> On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev 
>>  wrote:
>> 
>> 
>>> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev 
>>>  wrote:
>>>  if we start seeing issues with block rewards being too low to maintain 
>>> acceptable security, we're going to have multiple solutions being 
>>> implemented for it, and definitely a hard fork to indefinitely maintain 
>>> some degree of block subsidy
>> 
>> if we failed to first try increasing block demand with advanced transaction 
>> support, it would seem like we were just throwing money and growth away to 
>> support one narrative (simplicty of function), while destroying another 
>> (finite supply) 
>> 
>> if stuff like covenant support and mweb gets us higher fees, with stuff like 
>> on-chain mixing protocols, vaults, and higher utility, it might be more than 
>> enough to sustain bitcoin on fees alone forever
>>  
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

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 

Re: [bitcoin-dev] Package Relay Proposal

[Eric Voskuil via bitcoin-dev]

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: e...@voskuil.org 
> Sent: Wednesday, May 25, 2022 1:52 PM
> To: 'Anthony Towns' ; 'Bitcoin Protocol Discussion'
> ; 'Gloria Zhao'
> 
> Subject: RE: [bitcoin-dev] Package Relay Proposal
> 
> > From: bitcoin-dev  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.
> > _

Re: [bitcoin-dev] Package Relay Proposal

[Eric Voskuil via bitcoin-dev]

> From: bitcoin-dev  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Package Relay Proposal

[Eric Voskuil via bitcoin-dev]

The set of txs is the graph. Anything else would just reproduce the tx graph 
which must be traversed in any case.

Similarly the set of txs is the fee, the sigops, the size, and the weight. The 
only information required by packaging is the association of the txs with each 
other for the purpose of aggregate (vs. individual) net reward consideration.

Since a package can only be reasonably considered for a single block, there is 
a natural effective limit on acceptable package size. Since any number of 
individual txs may be transmitted, and the size/weight/sigops of one tx is 
bounded only by block validity, there is no reason to put any other constraints 
on packages. A package is just a set of txs that may fit into a block and may 
collectively be worth mining. A rational package is just a block or compact 
block without the header. Making it any more than that is unnecessary 
complexity.

If parts of a package satisfy profitability constraints, they will be 
accepted/mined and if other parts do not, they will be rejected. There’s no 
preventing this.

The only pertinent feature missing in the p2p protocol is the ability to 
associate a set of txs for consideration, where the set (or subset) may satisfy 
profitability constraints that would not be satisfied if the txs were 
considered individually.

e

> On May 24, 2022, at 16:21, Gloria Zhao via bitcoin-dev 
>  wrote:
> 
> 
> Hi aj,
> 
> > If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is 
> > below fee floor while A+B and A+B+C+X are above fee floor you have the 
> > problem though.
> 
> To clarify, in this situation, I'm imagining something like
> A: 0 sat, 100vB
> B: 1500 sat, 100vB
> C: 0 sat, 100vB
> X: 500 sat, 100vB
> feerate floor is 3sat/vB
> 
> With the algo:
> >  * is X alone above my fee rate? no, then forget it
> >  * otherwise, s := X.size, f := X.fees, R := [X]
> >  * for P = P1..Pn:
> >   * do I already have P? then skip to the next parent
> >   * s += P.size, f += P.fees, R += [P]
> >  * if f/s above my fee rate floor? if so, request all the txs in R
> 
> We'd erroneously ask for A+B+C+X, but really we should only take A+B.
> But wouldn't A+B also be a package that was announced for B?
> Please lmk if you were imagining something different. I think I may be 
> missing something.
> 
> > Is it plausible to add the graph in?
> 
> Fun to think about. Most basic design would be to represent {spends, doesn’t 
> spend} for a previous transaction in the package as a bit. Can think of it as 
> a matrix where row i, column j tells you whether Tx j (directly) spends Tx i.
> But of course you can omit the last row, since the child spends all of them. 
> And since topological ordering is a requirement, you only need as many bits 
> as there are transactions preceding this one in the package.
> If you have up to 24 parents, you need 1 + 2 + ... + 23 bits to codify 
> spending for the 2nd ... 24th parent. For a maximum 25 transactions, 23*24/2 
> = 276, seems like 36 bytes for a child-with-parents package. A few more for 
> tx-with-ancestors.
> Then you can split it up into sub-packages and everything. Still not sure if 
> we really need to.
> 
> Also side note, since there are no size/count params, 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?
> 
> Best,
> Gloria
> 
>> On Tue, 24 May 2022 at 12:48 Anthony Towns  wrote:
>> On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao  
>> wrote:
>> >> If you're asking for the package for "D", would a response telling you:
>> >>   txid_D (500 sat, 100vB)
>> >>   txid_A (0 sat, 100vB)
>> >>   txid_B (2000 sat, 100 vB)
>> >> be better, in that case? Then the receiver can maybe do the logic
>> >> themselves to figure out that they already have A in their mempool
>> >> so it's fine, or not?
>> >Right, I also considered giving the fees and sizes of each transaction in
>> >the package in “pckginfo1”. But I don’t think that information provides
>> >additional meaning unless you know the exact topology, i.e. also know if
>> >the parents have dependency relationships between them. For instance, in
>> >the {A, B, D} package there, even if you have the information listed, your
>> >decision should be different depending on whether B spends from A.
>> 
>> I don't think that's true? We already know D is above our fee floor so if B 
>> with A is also above the floor, we want them all, but also if B isn't above 
>> the floor, but all of them combined are, then we also do?
>> 
>> If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is 
>> below fee floor while A+B and A+B+C+X are above fee floor you have the 
>> problem though.
>> 
>> Is it plausible to add the graph in?
>> 
>> Cheers,
>> aj
>> 
>> 
>> 
>> -- 
>> Sent from my phone.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoun

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

[Eric Voskuil via bitcoin-dev]

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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

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 
> Sent: Tuesday, May 3, 2022 7:37 PM
> To: Eric Voskuil 
> Cc: Chris Belcher ; Bitcoin Protocol Discussion  d...@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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

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.

e

> On May 3, 2022, at 11:03, Chris Belcher via bitcoin-dev 
>  wrote:
> 
> Hello ZmnSCPxj,
> 
> Such a system will have to be publicly advertised, in the same way we see 
> centralized cryptocurrency staking shops buying ads all over the place. 
> That's how they'll make retail hodlers aware that renting out your coins in 
> this way is possible. If JoinMarket/Teleport users notice such ads appearing 
> then we could change the taker code to remove the intermediate certificate 
> keypair, and have the fidelity bond UTXO key sign the endpoint (IRC nickname 
> or onion hostname) directly. This removes the possibility of fidelity bonds 
> in cold storage. It would have to be done for privacy, and it wouldn't be too 
> bad. Right now there's no cold storage solution for fidelity bonds yet 
> JoinMarket has about 600 bitcoins locked up and advertised, which must be all 
> on hot wallets.
> 
> Best,
> CB
> 
>> On 03/05/2022 06:26, ZmnSCPxj wrote:
>> Good morning Chris,
>>> Hello ZmnSCPxj,
>>> 
>>> Renting out fidelity bonds is an interesting idea. It might happen in
>>> the situation where a hodler wants to generate yield but doesn't want
>>> the hassle of running a full node and yield generator. A big downside of
>>> it is that the yield generator income is random while the rent paid is a
>>> fixed cost, so there's a chance that the income won't cover the rent.
>> The fact that *renting* is at all possible suggests to me that the following 
>> situation *could* arise:
>> * A market of lessors arises.
>> * A surveillor creates multiple identities.
>> * Each fake identity rents separately from multiple lessors.
>> * Surveillor gets privacy data by paying out rent money to the lessor market.
>> In defiads, I and Tamas pretty much concluded that rental would happen 
>> inevitably.
>> One could say that defiads was a kind of fidelity bond system.
>> Our solution for defiads was to prioritize propagating advertisements 
>> (roughly equivalent to the certificates in your system, I think) with larger 
>> bonded values * min(bonded_time, 1 year).
>> However, do note that we did not intend defiads to be used for 
>> privacy-sensitive applications like JoinMarket/Teleport.
>> Regards,
>> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Eric Voskuil via bitcoin-dev]

> > Even if it is not needed, it is kind of "free" if you take transaction size 
> > into account
> 
> But it would require an on-chain transaction. We don't want 6 billion people 
> to have to send an on-chain transaction all in the same week in order to 
> register their preference on something.

I haven’t followed this thread, so apologies if I’m missing some context, but 
confirmed tx signaling remains miner signaling.

Regardless, miners are the only actors who can create soft fork compatibility, 
so theirs is the only relevant signal. Otherwise people can just fork 
themselves at any time using any voting mechanism they want.

e
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev 
>  wrote:
> 
> 
>> Dear Bitcoin Developers,
> 
>> -When I contacted bitInfoCharts to divide the first interval of addresses, 
>> they kindly did divided to 3 intervals. From here:
>> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
>> -You can see that there are more than 3.1m addresses holding ≤ 0.01 BTC 
>> (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per address.
> 
>> -Therefore, a simple solution would be to follow the difficulty adjustment 
>> idea and just delete all those
> 
> That would be a soft-fork, and arguably could be considered theft. While 
> commonly (but non universally) implemented standardness rules may prevent 
> spending them currently, there is no requirement that such a rule remain in 
> place. Depending on how feerate economics work out in the future, such 
> outputs may not even remain uneconomical to spend. Therefore, dropping them 
> entirely from the UTXO set is potentially destroying potentially useful funds 
> people own.
> 
>> or at least remove them to secondary storage
> 
> Commonly adopted Bitcoin full nodes already have two levels of storage 
> effectively (disk and in-RAM cache). It may be useful to investigate using 
> amount as a heuristic about what to keep and how long. IIRC, not even every 
> full node implementation even uses a UTXO model.

You recall correctly. Libbitcoin has never used a UTXO store. A full node has 
no logical need for an additional store of outputs, as transactions already 
contain them, and a full node requires all of them, spent or otherwise.

The hand-wringing over UTXO set size does not apply to full nodes, it is 
relevant only to pruning. Given linear worst case growth, even that is 
ultimately a non-issue.

>> for Archiving with extra cost to get them back, along with non-standard 
>> UTXOs and Burned ones (at least for publicly known, published, burn 
>> addresses).
> 
> Do you mean this as a standardness rule, or a consensus rule?
> 
> * As a standardness rule it's feasible, but it makes policy (further) deviate 
> from economically rational behavior. There is no reason for miners to require 
> a higher price for spending such outputs.
> * As a consensus rule, I expect something like this to be very controversial. 
> There are currently no rules that demand any minimal fee for anything, and 
> given uncertainly over how fee levels could evolve in the future, it's 
> unclear what those rules, if any, should be.
> 
> Cheers,
> 
> --
> Pieter
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF policy

[Eric Voskuil via bitcoin-dev]

> On Feb 1, 2022, at 00:32, Bram Cohen  wrote:
> 
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil  wrote:
>> 
>> 
 On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev 
  wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and 
>>> disallowing it is the feature, and that feature is mostly there to appease 
>>> some people's delusions that zeroconf is a thing? It seems a bit overdue to 
>>> disrespect the RBF flag in the direction of always assuming it's on.
>> What flag?
> 
> The opt-in RBF flag in transactions.

Was being facetious. The “disrespect” referred to above assumes respect that 
some implementations have never given.

>>> There are two different common regimes which result in different 
>>> incentivized behavior. One of them is that there's more than a block's 
>>> backlog in the mempool in which case between two conflicting transactions 
>>> the one with the higher fee rate should win. In the other case where there 
>>> isn't a whole block's worth of transactions the one with higher total value 
>>> should win.
>> These are not distinct scenarios. The rational choice is the highest fee 
>> block-valid subgraph of the set of unconfirmed transactions, in both cases 
>> (within the limits of what is computationally feasible of course).
> 
> It's weird because which of two or more conflicting transactions should win 
> can oscillate back and forth depending on other stuff going on in the mempool.

The assumption of RAM storage is an error and unrelated to network protocol. 
There is nothing “going on” in a set of unconfirmed valid transactions. They 
are logically unchanging.

> There's already a bit of that with child pays but this is stranger and has 
> more oddball edge cases about which transactions to route.

There’s really no such thing. The p2p network is necessarily permissionless. A 
person can route whatever he wants. Presumably people will not generally waste 
their own bandwidth by routing what they believe to be unconfirmable. And 
whatever they would retain themselves is their presumption of confirmable.

This decision of what to retain one’s self is just a graph traversal to 
determine the most valuable subset - an optimizing CSP (though generally 
suboptimal due to the time constraint).

Short of DoS, the most profitable model is to retain *all* valid transactions. 
[Note that a spend conflict is not an invalidity. Two valid transactions can be 
confirmed in sibling branch blocks - both valid in some context.]

So the only consideration is low cost storage fill. The fee is a proof of 
spend, which like proof of work (for headers/blocks), is the basis of DoS 
protection (for unconfirmed transactions). The issue with two conflicting 
subgraphs is that one or the other is ultimately unspendable. As such the fee 
on each is non-cumulative and therefore only one (the highest) is providing DoS 
protection. Any subsequent conflicting subgraph must pay not only for itself, 
but for all preceding conflicting subgraphs.

This pays for the storage, which is a trade accepted by the owner of the node 
in order to have a preview of confirmable transactions. This supports both 
mining generation of candidate blocks and rapid validation/confirmation of 
blocks.

It’s a rather straightforward system when considered in terms of how it 
actually works (ie from a consensus standpoint). The only p2p issue is the need 
to package transactions for consideration as a set, as otherwise parents may be 
discarded before children can pay for them. Any set up to a full block is 
entirely reasonable for consideration.

e___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF policy

[Eric Voskuil via bitcoin-dev]

> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev 
>  wrote:


…

> Is it still verboten to acknowledge that RBF is normal behavior and 
> disallowing it is the feature, and that feature is mostly there to appease 
> some people's delusions that zeroconf is a thing? It seems a bit overdue to 
> disrespect the RBF flag in the direction of always assuming it's on.

What flag?

>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>   accept replacement transactions which would decrease fee profits
>>   of a miner. In general, if our mempool policy deviates from what is
>> economically rational, it's likely that the transactions in our
>> mempool will not match the ones in miners' mempools, making our
>> fee estimation, compact block relay, and other mempool-dependent
>> functions unreliable. Incentive-incompatible policy may also
>> encourage transaction submission through routes other than the p2p
>> network, harming censorship-resistance and privacy of Bitcoin payments.
> 
> There are two different common regimes which result in different incentivized 
> behavior. One of them is that there's more than a block's backlog in the 
> mempool in which case between two conflicting transactions the one with the 
> higher fee rate should win. In the other case where there isn't a whole 
> block's worth of transactions the one with higher total value should win.

These are not distinct scenarios. The rational choice is the highest fee 
block-valid subgraph of the set of unconfirmed transactions, in both cases 
(within the limits of what is computationally feasible of course).

When collecting pooled txs the only issue is DoS protection, which is simply a 
question of what any given miner is willing to pay, in terms of disk space, to 
archive conflicts for the opportunity to optimize block reward.

> It would be nice to have consolidated logic which handles both, it seems the 
> issue has to do with the slope of the supply/demand curve which in the first 
> case is gentle enough to keep the one transaction from hitting the rate but 
> in the second one is basically infinite.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP review

[Eric Voskuil via bitcoin-dev]

> 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  
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 
  "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

 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP review

[Eric Voskuil via bitcoin-dev]

> -Original Message-
> From: Luke Dashjr 
> Sent: Tuesday, January 18, 2022 2:10 PM
> To: e...@voskuil.org
> Cc: 'Bitcoin Protocol Discussion' 
> Subject: Re: [bitcoin-dev] CTV BIP review
> 
> On Tuesday 18 January 2022 22:02:24 e...@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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP review

[Eric Voskuil via bitcoin-dev]

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  On
Behalf
> Of Luke Dashjr via bitcoin-dev
> Sent: Tuesday, January 18, 2022 1:19 PM
> To: bitcoin-dev@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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] death to the mempool, long live the mempool

[Eric Voskuil via bitcoin-dev]

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  On Behalf
> Of ZmnSCPxj via bitcoin-dev
> Sent: Tuesday, October 26, 2021 1:02 AM
> To: lisa neigut ; Bitcoin Protocol Discussion  d...@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 t

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

[Eric Voskuil via bitcoin-dev]

Switching pools has always been possible. But the largest pool is the most 
profitable, and centralized pools are easily controlled. Decoupling selection 
without decoupling payout is an engineering change without a pooling pressure 
change.

e

> On Sep 6, 2021, at 10:01, David A. Harding  wrote:
> 
> On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote:
>> It doesn’t centralize payment, which ultimately controls transaction 
>> selection (censorship).
> 
> Yeah, but if you get paid after each share via LN and you can switch
> pools instantly, then the worst case with centralized pools is that
> you don't get paid for one share.  If the hasher sets their share
> difficulty low enough, that shouldn't be a big deal.
> 
> I'm interested in whether braidpool offers any significant benefits over
> an idealized version of centralized mining with independent transaction
> selection.
> 
> -Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

[Eric Voskuil via bitcoin-dev]

It doesn’t centralize payment, which ultimately controls transaction selection 
(censorship).

e

> On Sep 6, 2021, at 08:25, David A. Harding via bitcoin-dev 
>  wrote:
> 
> On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote:
>> How would you compare this to Stratum v2?
> 
> Specifically, I'd be interested in learning what advantages this has
> over a centralized mining pool using BetterHash or StratumV2 with
> payouts made via LN (perhaps immediately after each submitted share is
> validated).
> 
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

All reasonable.

e

> Okay, it seems to me that what you are saying is something like this:
> 
> > Proof-of-reserves would (partially) work for a "pure" warehousing service
> (i.e. user pays some fee, service keeps money and provides proofs that
> money is kept).
> > However, "pure" warehousing is not what a typical exchange does (else
> the explicit fees in their exchanges would be higher), as it takes on risk due
> to having to deal with non-Bitcoin monopoly money (by definition, since they
> are *exchanges*).
> > Further, with Bitcoin you can be your own warehouse (including Green-like
> multisig schemes where you own your own keys that are part of the
> scheme), which is an alternative choice to hiring a "pure warehouse" (i.e.
> Safe Deposit).
> 
> Would that be a fair (if somewhat rough and undetailed) restatement?
> 
> Regards,
> ZmnSCPxj


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> 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

_

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

ot;Buck breaking has rarely happened. Up to the 2008 financial crisis, only three 
money funds had broken the buck in the 37-year history of money funds... The 
first money market mutual fund to break the buck was First Multifund for Daily 
Income (FMDI) in 1978, liquidating and restating NAV at 94 cents per share"

An investment loss of 6%.

"The Community Bankers US Government Fund broke the buck in 1994, paying 
investors 96 cents per share."

An investment loss of 4%.

"This was only the second failure in the then 23-year history of money funds 
and there were no further failures for 14 years... No further failures occurred 
until September 2008, a month that saw tumultuous events for money funds."

It was a "tumultuous" month for nearly all investments. The feds of course 
doled out the pork, and the funds had to take it (as if their competition did 
and they didn't they would fail due to higher relative capital costs and 
thereby lower rates). In the past, absent pork, they had raised money where 
necessary to maintain their NAV (just as banks do, but they go to the taxpayer, 
and just as all business do from time to time).

These are remarkably stable in terms of NAV. And people seem to be satisfied 
with them:

"At the end of 2011, there were 632 money market funds in operation,[19] with 
total assets of nearly US$2.7 trillion.[19] Of this $2.7 trillion, retail money 
market funds had $940 billion in Assets Under Management (AUM). Institutional 
funds had $1.75 trillion under management.[19]"

The point being, that this is as close to free market bank-based investing as 
exists in the white market. In a money market fund, the NAV is reflected in the 
share price, so any losses are evenly distributed - no different than when all 
those HODLers take a hit when Elon farts, and the reserve they maintain has 
been very effective in maintaining their $1/share *target* despite paying 
*interest* on *investments*. They are merely shifting market returns into 
interest, just like banks. Market returns over short periods aren't always 
positive. No surprise. The larger point being, BANKS ARE INVESTMENT FUNDS.

>> Irrelevant.

> It is certainly not irrelevant. People have been lead to believe that they 
> can withdraw their money from their accounts. People expect this.

Irrelevant, people have minds and free will and can read the contracts they are 
actually signing. Contracts are the *actual* Law associated with non-aggression.

> Banks are doing nothing to educate people on the limitations of that fact.

Again, irrelevant. And wholly unnecessary given compulsory taxpayer deposit 
insurance.

> PoR would give people the ability to see quite accurately how much reserves 
> there are and can use this knowledge to put pressure on institutions to keep 
> the reserves those people think they should keep. 

For all of the reasons I've stated, it's a fairly pointless exercise, but 
people can do what they want. But if they are doing this with a deeply flawed 
understanding of banking to start with, they will be disappointed in the 
outcome.

>> Without 100% “reserve” there is no way to cryptographically demonstrate 
>> “solvency”. 

> You can show proof that you're 80% solvent, and then claim the other 20% is 
> in other assets. This is, again, still useful. 

80% solvent ... 50% pregnant.

>>The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state 
>>seizure, no matter what the reserve

> You're right, but that's irrelevant. 

I'll leave that to the reader. The alternative is to use your own wallet.

> But it seems like you're not interested in understanding what I'm saying or 
> discussing these things honestly.

I'm not interested in allowing flawed concepts to be perpetuated without 
question. This is just a drain on capital that could be put to much better use. 
How many times have I heard the oxymoron "full reserve banking", and how much 
capital has been burned on this futile exercise, simply due to a failure to 
understand these concepts.

> So I'm going to end my conversation with you here.

While seemingly off-topic, these are things that need to be aired in this 
community. Thanks for the discourse.

e

On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev 
<mailto:bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Jul 9, 2021, at 10:44, Billy Tetrud <mailto:billy.tet...@gmail.com> wrote:
> 
> >  there is an unsupportable leap being made here
> 
> You think that because you're misinterpreting me. I'm in no way claiming that 
> any solvent company can prove it, I'm simply claiming that any company can 
> prove that they have bitcoin reserves to cover bitcoins promised as account 
> balances. 

You can prove that in your own wallet. All other scenari

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> On Jul 9, 2021, at 10:44, Billy Tetrud  wrote:
> 
> >  there is an unsupportable leap being made here
> 
> You think that because you're misinterpreting me. I'm in no way claiming that 
> any solvent company can prove it, I'm simply claiming that any company can 
> prove that they have bitcoin reserves to cover bitcoins promised as account 
> balances. 

You can prove that in your own wallet. All other scenarios imply lending (which 
is what is implied by “reserve”) and lending cannot be 100% reserve.

> > Banks (lending institutions) do not operate under any such pretense
> 
> You seem to be saying that banks are under no legal obligation to serve cash 
> on demand to customers. While you might be right,

I am, as banks are lending institutions.

> again you're misinterpreting me. Banks do in fact make claims to their 
> customers that they'll be able to get cash out of their account on demand.

Up to the insured limit, in 7 days. This is of course true because the taxpayer 
has insured the bank to that level.

> They're called demand deposit accounts for a reason.

They are time deposits, read your bank agreement. Not that it makes any 
difference. How the contract is satisfied is not a term of the contract, just 
that it is. And as I pointed out, money markets have had no reserve requirement 
and have a nearly spotless record of satisfying their obligations.

> And certainly customers expect to be able to withdraw their cash on demand. 

Irrelevant.

> > With a 100% of investment cash hoard, there is zero lending and zero return
> 
> I did say "pretend" did I not?

See above.

> > “relate to” is a far cry from 100% “reserve”
> 
> Indeed. Again, you seem to be misunderstanding me. You're putting the words 
> "100% reserve" in my mouth, when I never said any such thing. Proof of 
> 80%/50%/20% reserves is still useful if that's the clear expectation for the 
> customer/client.

Without 100% “reserve” there is no way to cryptographically demonstrate 
“solvency”. And even with that, investors would have to accept the promise that 
there are no other liabilities.

The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state 
seizure, no matter what the reserve.

It’s information, sure, but it’s not what people seem to think. If one wants 
full reserve banking, use a wallet. If one wants to invest, the money will be 
spent - that’s why it was raised. There can be no covenant placed on it that 
will ensure it’s return.

e
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev 
>  wrote:

> But people can certainly pull their money out of companies that can't show 
> solvency. 

As I pointed out previously there is an unsupportable leap being made here 
between a vault (money warehouse) and any company (including a bank).

A company cannot possibly show that it has all of the money that every person 
has invested into it. At times a solvent company may even have zero cash. It is 
also not possible for a company provide cryptographic proof of its many 
necessarily non-crypto assets and liabilities. What is presumed here is a 
community-verified sort of crypto balance sheet, with no considerations of risk 
- a central aspect of business.

As I said, if you want a vault, you can just use your own wallet. Solvency does 
not in any way imply 100% cash balance of the amounts invested. Raising money 
under such terms is pointless for both company and investors (the owners of the 
company).

> > Nonsense, any business can fail, regardless of temporal cash reserves.
> 
> I agree that any business can fail. But a bank that pretends it can serve 
> cash on demand is not a normal business,

Banks (lending institutions) do not operate under any such pretense. US banks 
require 7 day time deposits for all interest bearing accounts (read your 
depositor agreement), and it should be clear that your uninsured balance is at 
risk. Banks are investment funds, not money warehouses (in Rothbard’s 
terminology).

With a 100% of investment cash hoard, there is zero lending and zero return. 
This is true for all business.

> and cash reserves absolutely relate to their ability to survive as a bank.

“relate to” is a far cry from 100% “reserve”. At 100% reserve an investment 
fund would most certainly fail. At 20% it would fail. Money markets (banks 
without a reserve requirement) don’t break the buck, compete effectively with 
banks with reserve requirements (required by the taxpayer who is insuring 
deposits and providing discount credit), and maintain around 10% reserve. This 
is consistent with a world of people with time preference that creates around a 
10% interest rate (return on investment).

> Its honestly confusing to me how you could think otherwise.

It’s confusing to me how anyone would put money into a business and expect 
(even want) it to sit there.

> Also, calling my thoughts "nonsense" is rude, please check yourself, Eric. 

Check myself? Nonsense is English for “doesn’t make sense”. It’s not an insult.

e
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> 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  On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud ; Bitcoin Protocol Discussion
> 
> 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  d...@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 respo

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> @Eric
> Auditability Fallacy
> 
> > A solvency audit requires simultaneous (atomic) proof of both the full 
> > amount of the asset held by a custodian and the securities issued against 
> > it.
> 
> > in the case where the security is issued on a distinct public chain the 
> > atomicity requirement is not satisfied.
> 
> I think what its saying is that you can't get atomicity of both the security 
> and the reserve. While this is true, what you can get is a system where the 
> order of events can be established to a degree of precision. Ie, you can know 
> that between reserve-snapshot A and B, the balances add up to X. Each user 
> can validate that their balance was indeed that value between A and B. With 
> reserve snapshots and balance snapshots frequent enough, this can allow 
> reasonably high accuracy of estimated solvency. However, it does seem clear 
> that perfect accuracy is not possible.

If perfect is not possible, it’s not possible. It reduces to trust, which is 
the status quo.

All “users” need to simultaneously share their individual and temporary audits 
with each other (ie publicly).

> > Historically it has not been difficult to detect such deviations. The 
> > difficulty arises in stopping them.
> 
> I disagree here that it has not been difficult to detect deviations 
> (insolvency).

It is not hard to spot price inflation. Stopping or avoiding it is the actual 
issue. No “proof” of reserve can do this. The federal reserve was clearly 
insolvent from its early days, as that was its purpose.

> I mean, "difficulty" isn't the right word. These things always become clear 
> eventually. But I think its important to detect insolvency quickly. 
> Historically insolvency has certainly not been detected quickly. Insolvency 
> is instead practically perpetual, and the question is only how insolvent and 
> when will it explode?

There is no “proof” that answers this question.

> I'm of the opinion that you can't prevent insolvency.

It’s not a matter of opinion. Lending implies risk. When you invest you are in 
fact the owner of the insolvency, not someone else.

> Places will have money troubles and will try to cover it up, since usually 
> there is no downside (admitting insolvency can lead to bankrupcy, and failure 
> to conceal insolvency has the same result - so why not try to conceal it and 
> hope you can shore it up). However, its important that people know the 
> institutions they have their money in are insolvent, or to what degree they 
> are. If that information were well tracked, it could become clear over time 
> that a 10% insolvent company rarely goes out of business, but a 20% insolvent 
> company usually does.

Nonsense, any business can fail, regardless of temporal cash reserves.

> Then people can have parameters where they're ok with a certain measurable 
> degree of insolvency, but react swiftly and strongly when a company is too 
> reckless. Currently the amount of recklessness any given company engages in 
> is basically a company secret that their clients don't have insight into. PoR 
> would greatly help this I think. You don't think so? 

Reckless is a subjective term. Proofs will not insure any investment.

e

>> On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil  wrote:
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
>> 
 On Jul 5, 2021, at 21:54, ZmnSCPxj  wrote:
 
>>> Good morning Billy,
>>> 
>>> 
 
>   The two participants in the channel can sign a plaintext containing 
> their node pubkeys and how much each owns
 
 Sure, but even if both participants in the channel sign a correct 
 statement of truth, one of the participants can send funds out in the next 
 second, invalidating that truth. While proof of ownership of on-chain 
 UTXOs can be seen publicly in real time if they are spent, LN transactions 
 aren't public like that. So any balance attestation is at best only valid 
 the instant its taken, and can't be used as verification the money is 
 still owned by the same channel partner in the next second. 
>>> 
>>> The same problem really also exists onchain --- a thief (or "thief") who 
>>> has gotten a copy of the key can sign a transaction that spends it, one 
>>> second after the proof-of-reserves is made.
>>> 
>>> Really, though, the issue is that ownership of funds is conditional on 
>>> *knowledge* of keys.
>>> And *knowledge* is easily copyable.
>>> 
>>> Thus, it is possible that the funds that are "proven" to be the reserve of 
>>> a custodian is actually *also* owned by someone else who has gotten to the 
>>> privkeys (e.g. somebody threw a copy of it from a boating accident and a 
>>> fearless scuba diver rescued it), and thus can also move the funds outside 
>>> of the control of the custodian.
>>> This condition can remain for many months or years, as well, without 
>>> knowledge of the custodian clients, *or* of the custodian itself.
>>> 
>>> There is no way to prove 

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy

> On Jul 5, 2021, at 21:54, ZmnSCPxj  wrote:
> 
> Good morning Billy,
> 
> 
>> 
>>>   The two participants in the channel can sign a plaintext containing their 
>>> node pubkeys and how much each owns
>> 
>> Sure, but even if both participants in the channel sign a correct statement 
>> of truth, one of the participants can send funds out in the next second, 
>> invalidating that truth. While proof of ownership of on-chain UTXOs can be 
>> seen publicly in real time if they are spent, LN transactions aren't public 
>> like that. So any balance attestation is at best only valid the instant its 
>> taken, and can't be used as verification the money is still owned by the 
>> same channel partner in the next second. 
> 
> The same problem really also exists onchain --- a thief (or "thief") who has 
> gotten a copy of the key can sign a transaction that spends it, one second 
> after the proof-of-reserves is made.
> 
> Really, though, the issue is that ownership of funds is conditional on 
> *knowledge* of keys.
> And *knowledge* is easily copyable.
> 
> Thus, it is possible that the funds that are "proven" to be the reserve of a 
> custodian is actually *also* owned by someone else who has gotten to the 
> privkeys (e.g. somebody threw a copy of it from a boating accident and a 
> fearless scuba diver rescued it), and thus can also move the funds outside of 
> the control of the custodian.
> This condition can remain for many months or years, as well, without 
> knowledge of the custodian clients, *or* of the custodian itself.
> 
> There is no way to prove that there is no alternate copy of the privkeys, 
> hence "if only one could prove that he won't get into a boating accident".
> 
> On the other hand, one could argue that at least the onchain proof requires 
> more conditions to occur, so we might plausibly live with "we cannot prove we 
> will never get into a boating accident but we can show evidence that we live 
> in a landlocked city far from any lakes, seas, or rivers".
> 
> Regards,
> ZmnSCPxj
> 
>> 
>>>   a custodian Lightning node is unable to "freeze" a snapshot of its 
>>> current state and make an atomic proof-of-reserves of *all* channels
>> 
>> That would be a neat trick. But yeah, I don't know how that would be 
>> possible. 
>> 
>>>   I believe it is one reason why custodian proof-of-reserves is not that 
>>> popular ... it does not prove that the key will not get lost
>> 
>> True, but at least if funds do get lost, it would be come clear far quicker. 
>> Today, an insolvent company could go many months without the public finding 
>> out. 
>> 
>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj  wrote:
>> 
>>> Good morning e,
>>> 
 If only one could prove that he won’t get into a boating accident.
>>> 
>>> At least in the context of Lightning channels, if one party in the channel 
>>> loses its key in a boating accident, the other party (assuming it is a true 
>>> separate person and not a sockpuppet) has every incentive to unilaterally 
>>> close the channel, which reveals the exact amounts (though not necessarily 
>>> who owns which).
>>> If the other party then uses its funds in a new proof-of-reserves, then 
>>> obviously the other output of the unilateral close was the one lost in the 
>>> boating accident.
>>> 
>>> On the other hand, yes, custodians losing custodied funds in boating 
>>> accidents is much too common.
>>> I believe it is one reason why custodian proof-of-reserves is not that 
>>> popular --- it only proves that the funds were owned under a particular key 
>>> at some snapshot of the past, it does not prove that the key will not get 
>>> lost (or "lost and then salvaged by a scuba diver") later.
>>> 
>>> Regards,
>>> ZmnSCPxj
>>> 
 
 e
 
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
> Good morning Billy,
> 
>> 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.
> 
> Thinking about this in terms of economic logic:
> Every channel is anchored onchain, and that anchor (the funding txout) is 
> proof of the existence, and size, of the channel.
> The two participants in the channel can sign a plaintext containing their 
> node pubkeys and how much each owns.
> One of the participants should provably be the custodian.
> 
> -   If the counterparty is a true third party, it has no incentive to lie 
> about its money.
> -   Especially if the counterparty is another custodian who wants 
> proof-of-reserves, it has every incentive to overreport, but then the 
> first party will refuse to sign.
>  It has a disincentive to underreport, and would itself refuse to 
> sign a dishonest report that assigns more funds to the first party.
>  The only

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

If only one could prove that he won’t get into a boating accident.

e

> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev 
>  wrote:
> 
> Good morning Billy,
> 
>> 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. 
> 
> Thinking about this in terms of economic logic:
> 
> Every channel is anchored onchain, and that anchor (the funding txout) is 
> proof of the existence, and size, of the channel.
> 
> The two participants in the channel can sign a plaintext containing their 
> node pubkeys and how much each owns.
> One of the participants should provably be the custodian.
> 
> * If the counterparty is a true third party, it has no incentive to lie about 
> its money.
>  * Especially if the counterparty is *another* custodian who wants 
> proof-of-reserves, it has every incentive to overreport, but then the first 
> party will refuse to sign.
>It has a disincentive to underreport, and would itself refuse to sign a 
> dishonest report that assigns more funds to the first party.
>The only case that would be acceptable to both custodians would be to 
> honestly report their holdings in the Lightning channel.
> * If the counterparty is a sockpuppet of the custodian, then the entire 
> channel is owned by the custodian and it would be fairly dumb of he custodian 
> to claim to have less funds than the entire channel.
> 
> Perhaps a more practical problem is that Lightning channel states change 
> fairly quickly, and there are possible race conditions, due to network 
> latency (remember, both nodes need to sign, meaning both of them need to 
> communicate with each other, thus hit by network latency and other race 
> conditions) where a custodian Lightning node is unable to "freeze" a snapshot 
> of its current state and make an atomic proof-of-reserves of *all* channels.
> 
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Eric Voskuil via bitcoin-dev]

> On Jun 30, 2021, at 05:45, Zac Greenwood  wrote:
> 
> 
> Eric,
> 
> > A million nodes saying a transaction is invalid does nothing to enforce 
> > that knowledge
> 
> It does. Nodes disregard invalid transactions and invalid blocks as if they 
> never existed. It is not possible for any party to transact bitcoin in a way 
> that violates the set of rules enforced by the network of 
> consensus-compatible nodes that we call Bitcoin.

When Fincen walks into Coinbase and every other exchange (and white market 
business in the country), and tells them to change a rule or they are taking 
the CEO out in hancuffs for money laundering, I’m pretty sure that their node 
with not be able to prevent it.

Enforcement is always people. We use the term node as a metaphorical term for 
people who use the node to avoid taking bad money. Like those machines that 
test paper money, they offer no resistance themselves.

A node in a closet checking transactions, unconnected to any human actually 
rejecting the money in trade, offers no resistance to anything. It can be 
forked off without any consequence whatsoever. 

This subject was discussed here during the BCH split. People were setting up 
nodes on cloud services, to boost numbers. These non-economic nodes were of 
course of no consequence, which was not a matter of debate. I’m explaining to 
you why that is.

The network ignores non-economic nodes as if they never existed.

> Zac
> 
> 
>> On Wed, Jun 30, 2021 at 2:03 PM Eric Voskuil  wrote:
>> A million nodes saying a transaction is invalid does nothing to enforce that 
>> knowledge.
>> 
>> An economic node is a person who refuses to accept invalid money. A node 
>> only informs this decision, it cannot enforce it. That’s up to people.
>> 
>> And clearly if one is not actually accepting bitcoin for anything at the 
>> time, he is not enforcing anything.
>> 
>> The idea of a non-economic node is well established, nothing new here.
>> 
>> e
>> 
 On Jun 30, 2021, at 04:33, Zac Greenwood  wrote:
 
>>> 
>>> Hi Eric,
>>> 
>>> > A node (software) doesn’t enforce anything. Merchants enforce consensus 
>>> > rules
>>> 
>>> … by running a node which they believe to enforce the rules of Bitcoin.
>>> 
>>> A node definitely enforces consensus rules and defines what is Bitcoin. I 
>>> am quite disturbed that this is even being debated here.
>>> 
>>> Zac
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Eric Voskuil via bitcoin-dev]

A million nodes saying a transaction is invalid does nothing to enforce that 
knowledge.

An economic node is a person who refuses to accept invalid money. A node only 
informs this decision, it cannot enforce it. That’s up to people.

And clearly if one is not actually accepting bitcoin for anything at the time, 
he is not enforcing anything.

The idea of a non-economic node is well established, nothing new here.

e

> On Jun 30, 2021, at 04:33, Zac Greenwood  wrote:
> 
> 
> Hi Eric,
> 
> > A node (software) doesn’t enforce anything. Merchants enforce consensus 
> > rules
> 
> … by running a node which they believe to enforce the rules of Bitcoin.
> 
> A node definitely enforces consensus rules and defines what is Bitcoin. I am 
> quite disturbed that this is even being debated here.
> 
> Zac
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

> From: Jorge Timón  

>> "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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Eric Voskuil via bitcoin-dev]

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  
Sent: Sunday, June 27, 2021 5:01 AM
To: e...@voskuil.org
Cc: Bitcoin Dev 
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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

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  
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil 
Cc: Jorge Timón ; Luke Dashjr ; Bitcoin 
Protocol Discussion 
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 alterna

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

ers
>> >>>> wants which rules? We don't have a divining rod to determine with
>> >>>> certainty what users want. We can only make polls of various levels of
>> >>>> inaccuracy. The methods bitcoin has been using is community discussion
>> >>>> and social consensus estimation as well as miner signaling during the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade, and
>> >>>> why we need to have higher thresholds of success (require larger
>> >>>> supermajorities in both consensus and miner signaling).
>> >>>> 
>> >>>> Developers obviously care about bitcoin and have an incentive (personal
>> >>>> and probably financial) to do it right. And miners have both an
>> >>>> incentive to keep the system healthy, as well as an incentive to mine on
>> >>>> the chain that the economic majority of users is using. But measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily difficult
>> >>>> to do with consistent accuracy, and so I think miner signaling as it has
>> >>>> been used as a second barrier to entry for an upgrade is quite
>> >>>> appropriate.
>> >>>> 
>> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil  wrote:
>> >>>>> I have not objected to anyone splitting. As I said, a split is always
>> >>>>> possible, and of course has been done on a large scale. It is only the
>> >>>>> misleading statements about inherent soft fork “compatibility” and the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>> 
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>> 
>> >>>>> The statements below are grossly misleading and need to be called out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” decide the rules is not the question. The
>> >>>>> question is only how to avoid a split. If one does not care he can
>> >>>>> split at any time, no discussion required.
>> >>>>> 
>> >>>>> e
>> >>>>> 
>> >>>>>> On Jun 27, 2021, at 01:47, Jorge Timón  wrote:
>> >>>>>> 
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>> 
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>>  wrote:
>> >>>>>>> 
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>> 
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people want.
>> >>>>>>> Given that there is no collective “we”, those wants differ. Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>&

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

re) based on that signaling. I'm sure
>>>> you can agree that does not exist in BIP8.
>>>> 
>>>>> No additional bit is needed, as softforks are coordinated between
>>>>> users, NOT miners
>>>> 
>>>> And yet there is miner involvement, as you rightly pointed out. Miners
>>>> are needed to set the nVersion in the header. So when you say "no
>>>> additional bit is needed", could you please be clearer as to what you
>>>> mean? Do you mean that signaling of opposition in a block can be done
>>>> without any "additional bit"? Or are you just saying that it is
>>>> redundant to consider what miners might be opposing an upgrade?
>>>> 
>>>> @Jorge
>>>> 
>>>>> If different users want different incompatible things... there's no
>>>>> way to avoid the split
>>>> 
>>>> I agree. This happened with bcash, and that's fine. It was painful, but
>>>> there were a significant amount of users that disagreed, and they have
>>>> the chain they want now.
>>>> 
>>>> But we generally all want to avoid a chain split when possible. Because
>>>> chain splits have a cost, and that cost can be high, its likely that
>>>> many users would rather choose the chain with the most support rather
>>>> than choosing the chain with their preferred rules.
>>>> 
>>>> However, the question here is: how do we estimate what fraction of users
>>>> wants which rules? We don't have a divining rod to determine with
>>>> certainty what users want. We can only make polls of various levels of
>>>> inaccuracy. The methods bitcoin has been using is community discussion
>>>> and social consensus estimation as well as miner signaling during the
>>>> actual deployment period. Neither of these are perfect, but they are
>>>> both reasonable enough mechanisms. However, because both of these
>>>> mechanisms are very rough estimates of user sentiment, we need to
>>>> consider the possibility that sometimes the estimate may be
>>>> substantially inaccurate when we design deployment procedures. This
>>>> inaccuracy is why we need multiple barriers in place for an upgrade, and
>>>> why we need to have higher thresholds of success (require larger
>>>> supermajorities in both consensus and miner signaling).
>>>> 
>>>> Developers obviously care about bitcoin and have an incentive (personal
>>>> and probably financial) to do it right. And miners have both an
>>>> incentive to keep the system healthy, as well as an incentive to mine on
>>>> the chain that the economic majority of users is using. But measuring
>>>> the consensus of the bitcoin community can be extraordinarily difficult
>>>> to do with consistent accuracy, and so I think miner signaling as it has
>>>> been used as a second barrier to entry for an upgrade is quite
>>>> appropriate.
>>>> 
>>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil  wrote:
>>>>> I have not objected to anyone splitting. As I said, a split is always
>>>>> possible, and of course has been done on a large scale. It is only the
>>>>> misleading statements about inherent soft fork “compatibility” and the
>>>>> implication that activation without hash power enforcement does not
>>>>> create a split that I object to. People who know better should be
>>>>> honest about it.
>>>>> 
>>>>> Far too many people have been led to believe there is some sort of
>>>>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
>>>>> There is only a choice between creating a split and hash power
>>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>>>>> unless enforced by majority hash power.
>>>>> 
>>>>> The statements below are grossly misleading and need to be called out
>>>>> as such so that people can actually make this decision you speak of.
>>>>> This idea that “users” decide the rules is not the question. The
>>>>> question is only how to avoid a split. If one does not care he can
>>>>> split at any time, no discussion required.
>>>>> 
>>>>> e
>>>>> 
>>>>>> On Jun 27, 2021, at 01:47, Jorge Timón  wrote:
>>>>>> 
>>>>>>

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

system healthy, as well as an incentive to mine on the chain that 
>> the economic majority of users is using. But measuring the consensus of the 
>> bitcoin community can be extraordinarily difficult to do with consistent 
>> accuracy, and so I think miner signaling as it has been used as a second 
>> barrier to entry for an upgrade is quite appropriate. 
>> 
>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil  wrote:
>>> I have not objected to anyone splitting. As I said, a split is always 
>>> possible, and of course has been done on a large scale. It is only the 
>>> misleading statements about inherent soft fork “compatibility” and the 
>>> implication that activation without hash power enforcement does not create 
>>> a split that I object to. People who know better should be honest about it.
>>> 
>>> Far too many people have been led to believe there is some sort of 
>>> activation choice with “ensured” equal outcomes (maybe “slowed down”). 
>>> There is only a choice between creating a split and hash power enforcement. 
>>> Soft forks are rule changes, and thereby incompatible - unless enforced by 
>>> majority hash power.
>>> 
>>> The statements below are grossly misleading and need to be called out as 
>>> such so that people can actually make this decision you speak of. This idea 
>>> that “users” decide the rules is not the question. The question is only how 
>>> to avoid a split. If one does not care he can split at any time, no 
>>> discussion required.
>>> 
>>> e
>>> 
>>> > On Jun 27, 2021, at 01:47, Jorge Timón  wrote:
>>> > 
>>> > If different users want different incompatible things (enough on each
>>> > side), there's no way to avoid the split. We shouldn't try to avoid
>>> > such a split.
>>> > Users decide the rules, not miners nor developers.
>>> > 
>>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>>> >>  wrote:
>>> >> 
>>> >> Ultimately there is only one answer to this question. Get majority hash 
>>> >> power support.
>>> >> 
>>> >> Soft fork enforcement is the same act as any other censorship 
>>> >> enforcement, the difference is only a question of what people want. 
>>> >> Given that there is no collective “we”, those wants differ. Bitcoin 
>>> >> resolves this question of conflicting wants, but it is not a democracy, 
>>> >> it’s a market. One votes by trading.
>>> >> 
>>> >> 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.
>>> >> 
>>> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s 
>>> >> dishonest to imply that one can do this and all others will surely 
>>> >> follow. This cannot be known, it’s merely a gamble. And it’s one that 
>>> >> has been shown to not always pay off.
>>> >> 
>>> >> e
>>> >> 
>>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil  wrote:
>>> >>> 
>>> >>> For some definitions of “block”.
>>> >>> 
>>> >>> Without majority hash power support, activation simply means you are 
>>> >>> off on a chain split. Anyone can of course split off from a chain by 
>>> >>> changing a rule (soft or otherwise) at any time, so this is a bit of an 
>>> >>> empty claim.
>>> >>> 
>>> >>> Nobody can stop a person from splitting. The relevant question is how 
>>> >>> to *prevent* a split. And activation without majority hash power 
>>> >>> certainly does not “ensure” this.
>>> >>> 
>>> >>> e
>>> >>> 
>>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev 
>>> >>>>  wrote:
>>> >>>> 
>>> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. 
>>> >>>> They can
>>> >>>> still sl

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

I have not objected to anyone splitting. As I said, a split is always possible, 
and of course has been done on a large scale. It is only the misleading 
statements about inherent soft fork “compatibility” and the implication that 
activation without hash power enforcement does not create a split that I object 
to. People who know better should be honest about it.

Far too many people have been led to believe there is some sort of activation 
choice with “ensured” equal outcomes (maybe “slowed down”). There is only a 
choice between creating a split and hash power enforcement. Soft forks are rule 
changes, and thereby incompatible - unless enforced by majority hash power.

The statements below are grossly misleading and need to be called out as such 
so that people can actually make this decision you speak of. This idea that 
“users” decide the rules is not the question. The question is only how to avoid 
a split. If one does not care he can split at any time, no discussion required.

e

> On Jun 27, 2021, at 01:47, Jorge Timón  wrote:
> 
> If different users want different incompatible things (enough on each
> side), there's no way to avoid the split. We shouldn't try to avoid
> such a split.
> Users decide the rules, not miners nor developers.
> 
>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>>  wrote:
>> 
>> Ultimately there is only one answer to this question. Get majority hash 
>> power support.
>> 
>> Soft fork enforcement is the same act as any other censorship enforcement, 
>> the difference is only a question of what people want. Given that there is 
>> no collective “we”, those wants differ. Bitcoin resolves this question of 
>> conflicting wants, but it is not a democracy, it’s a market. One votes by 
>> trading.
>> 
>> 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.
>> 
>> Otherwise, as mentioned below, anyone can start a new coin. But it’s 
>> dishonest to imply that one can do this and all others will surely follow. 
>> This cannot be known, it’s merely a gamble. And it’s one that has been shown 
>> to not always pay off.
>> 
>> e
>> 
>>>> On Jun 26, 2021, at 14:43, Eric Voskuil  wrote:
>>> 
>>> For some definitions of “block”.
>>> 
>>> Without majority hash power support, activation simply means you are off on 
>>> a chain split. Anyone can of course split off from a chain by changing a 
>>> rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>>> 
>>> Nobody can stop a person from splitting. The relevant question is how to 
>>> *prevent* a split. And activation without majority hash power certainly 
>>> does not “ensure” this.
>>> 
>>> e
>>> 
>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev 
>>>>  wrote:
>>>> 
>>>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They 
>>>> can
>>>> still slow it down.
>>>> 
>>>> It also already has the trinary state you seem to be describing (although
>>>> perhaps this could be better documented in the BIP): users who oppose the
>>>> softfork can and should treat the successful signal (whether MASF or UASF) 
>>>> as
>>>> invalid, thereby ensuring they do not follow a chain with the rules in 
>>>> force.
>>>> 
>>>> No additional bit is needed, as softforks are coordinated between users, 
>>>> NOT
>>>> miners (who have no particular say in them, aside from their role as also
>>>> being users). The miner involvement is only out of necessity (to set the 
>>>> bit
>>>> in the header, which users coordinate with) and potentially to accelerate
>>>> activation by protecting upgrade-lagging users.
>>>> 
>>>> Luke
>>>> 
>>>> 
>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>> non-controversial taproot upgrade, I have been thinking about ways to 
>>>>> solve
>>>>> the problems that both sides brought up. In short, BIP8 LOT=true 
>>>>> proponents
>>>>&g

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

Ultimately there is only one answer to this question. Get majority hash power 
support.

Soft fork enforcement is the same act as any other censorship enforcement, the 
difference is only a question of what people want. Given that there is no 
collective “we”, those wants differ. Bitcoin resolves this question of 
conflicting wants, but it is not a democracy, it’s a market. One votes by 
trading.

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.

Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest 
to imply that one can do this and all others will surely follow. This cannot be 
known, it’s merely a gamble. And it’s one that has been shown to not always pay 
off.

e

> On Jun 26, 2021, at 14:43, Eric Voskuil  wrote:
> 
> For some definitions of “block”.
> 
> Without majority hash power support, activation simply means you are off on a 
> chain split. Anyone can of course split off from a chain by changing a rule 
> (soft or otherwise) at any time, so this is a bit of an empty claim.
> 
> Nobody can stop a person from splitting. The relevant question is how to 
> *prevent* a split. And activation without majority hash power certainly does 
> not “ensure” this.
> 
> e
> 
>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev 
>>  wrote:
>> 
>> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They 
>> can 
>> still slow it down.
>> 
>> It also already has the trinary state you seem to be describing (although 
>> perhaps this could be better documented in the BIP): users who oppose the 
>> softfork can and should treat the successful signal (whether MASF or UASF) 
>> as 
>> invalid, thereby ensuring they do not follow a chain with the rules in force.
>> 
>> No additional bit is needed, as softforks are coordinated between users, NOT 
>> miners (who have no particular say in them, aside from their role as also 
>> being users). The miner involvement is only out of necessity (to set the bit 
>> in the header, which users coordinate with) and potentially to accelerate 
>> activation by protecting upgrade-lagging users.
>> 
>> Luke
>> 
>> 
 On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>>> Given the recent controversy over upgrade mechanisms for the
>>> non-controversial taproot upgrade, I have been thinking about ways to solve
>>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>>> make the point that lazy miners failing to upgrade in a timely manner slow
>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>>> proponents make the point that LOT=true can lead to undesirable forks that
>>> might cause a lot of chaos. I believe both points are essentially correct
>>> and have created a proposal
>>> >> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>>> 
>>> The proposal uses trinary version signaling rather than binary signaling.
>>> For any particular prospective soft fork upgrade, this allows for three
>>> signaling states:
>>> 
>>> * Actively support the change.
>>> * Actively oppose the change.
>>> * Not signaling (neither support or oppose). This is the default state.
>>> 
>>> Using this additional information, we can release non-contentious upgrades
>>> much quicker (with a much lower percent of miners signaling support). For
>>> contentious upgrades, miners who oppose the change are incentivized to
>>> update their software to a version that can actively signal opposition to
>>> the change. The more opposition there is, the higher the threshold
>>> necessary to lock in the upgrade. With the parameters I currently
>>> recommended in the proposal, this chart shows how much support signaling
>>> would be necessary given a particular amount of active opposition
>>> signaling:
>>> 
>>> [image: thresholdChart.png]
>>> If literally no one signals opposition, a 60% threshold should be
>>> relatively safe because it is a supermajority amount that is unlikely to
>>> change significantly very quickly (ie if 60% of miners support the change
>>> today, its unlikely that less than a majority of miners would support the
>>> change a year or two from now), and if no one is signaling opposition,
>>> chances are that the vast majority of the other 40% would also eventually
>>> signal support.
>>> 
>>> This both gives an incentive for "lazy" miners to upgrade if they actually
>>> oppose the change while at the same time allowing these lazy miners to
>>> remain lazy without slowing down the soft fork activation much.
>>> 
>>> I think now is the right time to discuss new soft fork upgrade m

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

For some definitions of “block”.

Without majority hash power support, activation simply means you are off on a 
chain split. Anyone can of course split off from a chain by changing a rule 
(soft or otherwise) at any time, so this is a bit of an empty claim.

Nobody can stop a person from splitting. The relevant question is how to 
*prevent* a split. And activation without majority hash power certainly does 
not “ensure” this.

e

> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev 
>  wrote:
> 
> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can 
> still slow it down.
> 
> It also already has the trinary state you seem to be describing (although 
> perhaps this could be better documented in the BIP): users who oppose the 
> softfork can and should treat the successful signal (whether MASF or UASF) as 
> invalid, thereby ensuring they do not follow a chain with the rules in force.
> 
> No additional bit is needed, as softforks are coordinated between users, NOT 
> miners (who have no particular say in them, aside from their role as also 
> being users). The miner involvement is only out of necessity (to set the bit 
> in the header, which users coordinate with) and potentially to accelerate 
> activation by protecting upgrade-lagging users.
> 
> Luke
> 
> 
>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
>> Given the recent controversy over upgrade mechanisms for the
>> non-controversial taproot upgrade, I have been thinking about ways to solve
>> the problems that both sides brought up. In short, BIP8 LOT=true proponents
>> make the point that lazy miners failing to upgrade in a timely manner slow
>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
>> proponents make the point that LOT=true can lead to undesirable forks that
>> might cause a lot of chaos. I believe both points are essentially correct
>> and have created a proposal
>> > ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>> 
>> The proposal uses trinary version signaling rather than binary signaling.
>> For any particular prospective soft fork upgrade, this allows for three
>> signaling states:
>> 
>> * Actively support the change.
>> * Actively oppose the change.
>> * Not signaling (neither support or oppose). This is the default state.
>> 
>> Using this additional information, we can release non-contentious upgrades
>> much quicker (with a much lower percent of miners signaling support). For
>> contentious upgrades, miners who oppose the change are incentivized to
>> update their software to a version that can actively signal opposition to
>> the change. The more opposition there is, the higher the threshold
>> necessary to lock in the upgrade. With the parameters I currently
>> recommended in the proposal, this chart shows how much support signaling
>> would be necessary given a particular amount of active opposition
>> signaling:
>> 
>> [image: thresholdChart.png]
>> If literally no one signals opposition, a 60% threshold should be
>> relatively safe because it is a supermajority amount that is unlikely to
>> change significantly very quickly (ie if 60% of miners support the change
>> today, its unlikely that less than a majority of miners would support the
>> change a year or two from now), and if no one is signaling opposition,
>> chances are that the vast majority of the other 40% would also eventually
>> signal support.
>> 
>> This both gives an incentive for "lazy" miners to upgrade if they actually
>> oppose the change while at the same time allowing these lazy miners to
>> remain lazy without slowing down the soft fork activation much.
>> 
>> I think now is the right time to discuss new soft fork upgrade mechanisms,
>> when there are no pressing soft fork upgrades ready to deploy. Waiting
>> until we need to deploy a soft fork to discuss this will only delay things
>> and cause contention again like it did with taproot.
>> 
>> I'm very curious to know what people think of this mechanism. I would
>> appreciate any comments here, or written as github issues on the proposal
>> repo itself.
>> 
>> Thanks,
>> BT
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

[Eric Voskuil via bitcoin-dev]

https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Eric Voskuil via bitcoin-dev]

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy

> On May 7, 2021, at 15:50, SatoshiSingh via bitcoin-dev 
>  wrote:
> 
> Hello list,
> 
> I am a lurker here and like many of you I worry about the energy usage of 
> bitcoin mining. I understand a lot mining happens with renewable resources 
> but the impact is still high.
> 
> I want to get your opinion on implementing proof of stake for bitcoin mining 
> in future. For now, proof of stake is still untested and not battle tested 
> like proof of work. Though someday it will be.
> 
> In the following years we'll be seeing proof of stake being implemented. 
> Smaller networks can test PoS which is a luxury bitcoin can't afford. Here's 
> how I see this the possibilities:
> 
> 1 - Proof of stake isn't a good enough security mechanism
> 2 - Proof of state is a good security mechanism and works as intended
> 
> IF PoS turns out to be good after battle testing, would you consider 
> implementing it for Bitcoin? I understand this would invoke a lot of 
> controversies and a hard fork that no one likes. But its important enough to 
> consider a hard fork. What are your opinions provided PoS does work?
> 
> Love from India.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

[Eric Voskuil via bitcoin-dev]

You may activate any time you want.

 

e

 

From: bitcoin-dev  On Behalf Of 
Claus Ehrenberg via bitcoin-dev
Sent: Wednesday, April 7, 2021 6:42 AM
To: Rusty Russell ; Bitcoin Protocol Discussion 

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

> If you actually believe the operation of consensus and the discussion 
> relevant to that is a mundane or philosophical dissection of people's ability 
> to grasp a humorous while on-topic but obligatorily unnecessary conversation 
> you may prefer if you enquire how Bitcoin is censorship-resistant.

https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

I’m pretty sure it’s subtle mockery. Even a legit title doesn’t warrant 
additional attention.

e

> On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev 
>  wrote:
> 
> Can I just point out (to those addressing James as Lord/Excelency/etc
> that he isn't noble nor a Lord, so just wanted to mention this in case
> people were giving him more attention than the average person would be
> afforded.
> 
> My 2p (an equal 2p) on Taproot is ACK, by the way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Eric Voskuil via bitcoin-dev]

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  On Behalf Of 
Jorge Timón via bitcoin-dev
Sent: Monday, March 8, 2021 4:52 AM
To: Anthony Towns ; Bitcoin Protocol Discussion 

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.

 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Eric Voskuil via bitcoin-dev]

The most sensible approach I’ve seen yet.

e

> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev 
>  wrote:
> 
> On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev 
> wrote:
>> ## Example timeline
>> - T+0: release of one or more full nodes with activation code
>> - T+14: signal tracking begins
>> - T+28: earliest possible lock in
>> - T+104: locked in by this date or need to try a different activation process
>> - T+194: activation (if lockin occurred)
> 
>> ### Base activation protocol
>> The idea can be implemented on top of either Bitcoin Core's existing
>> BIP9 code or its proposed BIP8 patchset.[6]
>>BIP9 is already part of Bitcoin Core and I think the changes being
>>proposed would be relatively small, resulting in a small patch that
>>could be easy to review.
> 
> To get to specifics, here's a PR, based on #21334, that updates bip9
> to support an extra parameter to delay the transition from LOCKED_IN
> to ACTIVE until a particular timestamp is reached, and to reduce the
> activation threshold to 90%:
> 
>  https://github.com/bitcoin/bitcoin/pull/21377
> 
> With that in mind, I think the example timeline above could translate
> to taproot parameters of:
> 
>  nStartTime = 1618358400; // April 14, 2021
>  nTimeout = 1626220800; // July 14 2021
>  activation_time = 1633046400; // October 1 2021
> 
> That is, signalling begins with the first retarget period whose parent's
> median time is at least April 14th; and concludes with the last retarget
> period whose final block's median time is prior to July 14th; that's
> 91 days which should be about ~6.5 retarget periods, so should cover 6
> full retarget periods, but could only cover 5.  Activation is delayed
> until the first retarget period where the final block of the previous
> retarget period has a timestamp of at least October 1st.
> 
> Note that the timeout there is prior to the expected timestamp of the
> startheight block specified in the proposal for bip8 parameters:
> 
>  https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> 
> and earliest activation is after the expected release of 22.0 and hence
> the maintenance end of 0.20.
> 
> Note also that the PR above specifies the delay as a deadline, not a
> delta between lockin and activation; so earlier lockin does not produce
> an earlier activation with the code referenced above.
> 
> Cheers,
> aj
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Eric Voskuil via bitcoin-dev]

FYI it’s generally considered bad form repost a private thread, especially one 
you initiate.

...

It’s typically more effective to generate some community support before 
actually submitting a BIP. Otherwise the process gets easily overwhelmed. This 
is likely why you aren’t getting a response. You can draft the BIP in your own 
repo and collect feedback from interested parties.

Posting a link to your research/code is a good start. I’d be happy to look at 
an overview of the central principles. I’m not a cryptographer. I write code, 
but I look at these things from economic principles. So far all I have to go on 
is that you go “much beyond” Chia. That’s not really anything.

e

> On Mar 5, 2021, at 14:03, Lonero Foundation  
> wrote:
> 
> 
> Hi, Eric. Chia's network is a bad example. They go after energy consumption 
> in the wrong way entirely. True, it requires a comparable cost of hardware. I 
> am trying to tackle cryptography in a way that goes much beyond that. Part of 
> what I am doing includes lowering invalided proofs while trying to get the 
> best of both worlds in regards to PoW and PoC. It is an efficiency issue to 
> the core. In regards to the mechanisms of how I will do that, I suggest you 
> look at the entire proposal which is why I am hoping the BIP team would be so 
> gracious as to allow me to draft it out on GitHub.
> 
> Best regards, Andrew
> 
>> On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil  wrote:
>> How is the argument against PoM only partially true?
>> 
>> I wrote this as soon as I saw Chia. Had two debates on Twitter with Brahm, 
>> before he blocked me. Two years later, after they finally realized I was 
>> correct, one of their PhDs contacted me and told me. Better to flesh this 
>> out early. They had already raised $20 and done their research, so he wasn’t 
>> exactly in a listening mode.
>> 
>> e
>> 
 On Mar 5, 2021, at 13:20, Lonero Foundation  
 wrote:
 
>>> 
>>> Actually I mentioned a proof of space and time hybrid which is much 
>>> different than staking. Sorry to draw for the confusion as PoC is more 
>>> commonly used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Work as 
>>> it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of being 
>>> both CPU compatible and memory-hard compatible. There are lots of benefits 
>>> outside of the realm of efficiency, and I already looked into numerous 
>>> fault tolerant designs as well and what others in the cryptography 
>>> community attempted to propose. The actual argument you have only against 
>>> this is the Proof of Memory fallacy, which is only partially true. Given 
>>> how the current hashing algorithm works, hard memory allocation wouldn't be 
>>> of much benefit given it is more optimized for CPU/ASIC specific mining. 
>>> I'm working towards a hybrid mechanism that fixes that. BTW: The way 
>>> Bitcoin currently stands in its cryptography still needs updating 
>>> regardless. If someone figures out NP hardness or the halting problem the 
>>> traditional rule of millions of years to break all of Bitcoin's 
>>> cryptography now comes down to minutes. Bitcoin is going to have to 
>>> eventually radically upgrade their cryptography and hashing algo in the 
>>> future regardless. I want to integrate some form of NP complexity in 
>>> regards to the hybrid cryptography I'm aiming to provide which includes a 
>>> polynomial time algorithm in the cryptography. More than likely the first 
>>> version of my BTC hard fork will be coded in a way where integrating such 
>>> complexity in the future only requires a soft fork or minor upgrade to its 
>>> chain.
>>> 
>>> In regards to the argument, "As a separate issue, proposing a hard fork in 
>>> the hashing algorithm will invalidate the enormous amount of capital 
>>> expenditure by mining entities and disincentivize future capital 
>>> expenditure into mining hardware that may compute these more "useful" 
>>> proofs of work."
>>> 
>>> A large portion of BTC is already mined through AWS servers and non-asic 
>>> specific hardware anyways. A majority of them would benefit from a hybrid 
>>> proof, and the fact that it is hybrid in that manner wouldn't 
>>> disenfranchise currently optimized mining entities as well.
>>> 
>>> There are other reasons why a cryptography upgrade like this is beneficial. 
>>> Theoretically one can argue BItcoin isn't fully decentralized. It is few 
>>> unsolved mathematical proofs away from being entirely broken. My goal 
>>> outside of efficiency is to build cryptography in a way that prevents such 
>>> an event from happening in the future, if it was to ever happen. I have 
>>> various research in regards to this area and work alot with distributed 
>>> computing. I believe if the BTC community likes such a proposal, I would 
>>> single handedly be able to build the cryptographic proof myself (though 
>>> would lik

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Eric Voskuil via bitcoin-dev]

Hi Andrew,

Do you mean that you can reduce the cost of executing the cryptography at a 
comparable level of security? If so this will only have the effect of 
increasing the amount of it that is required to consume the same cost.

https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox

You mentioned a staking hybrid in your original post.

https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy

This would be a change to dynamics - the economic forces at work. Staking is 
not censorship resistant

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy

and is therefore what I refer to as cryptodynamically insecure.

https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles

As such it wouldn’t likely be considered as a contribution to Bitcoin. It might 
of course be useful in some other context.

https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition

But BIPs are proposals aimed at Bitcoin improvement.

https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP

Non-staking attempts to improve energy efficiency are either proof of work in 
disguise, such as proof of memory:

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy

or attempts to repurpose “wasteful” computing, such as by finding prime 
numbers, which does not imply a reduction in dedicated energy consumption.

https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle

Finally, waste and renewable energy approaches at “carbon” (vs energy) 
reduction must still consume the same in cost as the reward. In other words, 
the apparent benefit represents a temporary market shift, with advantage to 
first movers. The market will still consume what it consumes. If the hashing 
energy was free all reward consumption would shift to operations.

https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallacy

The motivation behind these attempts is naively understandable, but based on a 
false premise.

https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy

The one thing that reduces Bitcoin energy consumption is an increase in energy 
cost relative to block reward.

https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy

e

> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev 
>  wrote:
> 
> Hi, this isn't about the energy efficient argument in regards to renewables 
> or mining devices but a better cryptography layer to get the most out of your 
> hashing for validation. I do understand the arbitrariness of it, but do want 
> to still propose a document. Do I use the Media Wiki format on GitHub and 
> just attach it as my proposal?
> 
> Best regards, Andrew
> 
> On Fri, Mar 5, 2021, 10:07 AM Devrandom  wrote:
>> Hi Ryan and Andrew,
>> 
>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev 
>>  wrote:
>>> 
>>>   https://www.truthcoin.info/blog/pow-cheapest/
>>> "Nothing is Cheaper than Proof of Work"
>>> on | 04 Aug 2015
>> 
>> Just to belabor this a bit, the paper demonstrates that the mining market 
>> will tend to expend resources equivalent to miner reward.  It does not prove 
>> that mining work has to expend *energy* as a primary cost.
>> 
>> Some might argue that energy expenditure has negative externalities and that 
>> we should move to other resources.  I would argue that the negative 
>> externalities will go away soon because of the move to renewables, so the 
>> point is likely moot. 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Eric Voskuil via bitcoin-dev]

Mike was wrong about a number of things, and in the end decided that Bitcoin 
was pointless, as people could not defend it against the state. He used this as 
the basis for his defense of large blocks and centralized mining. When that 
didn’t work out he quit, to work on centralized systems.

People can of course do what they want, but unnecessarily splitting from the 
existing chain reduces utility, which seems counterproductive. BCH is a good 
example of this.

Compatibility isn’t “dangerous”. Old nodes don’t need to know what new nodes 
are doing. If the person operating one needs to validate a taproot payment to 
himself, he would have to upgrade. Otherwise it’s of no consequence, his node 
is economic (relevant) only in relation to the legacy payments he receives, 
which he can continue to validate.

e

> On Mar 4, 2021, at 15:22, Vincent Truong via bitcoin-dev 
>  wrote:
> 
> 
> 
> I must remind everyone of Mike Hearn's proposal not many years ago, which 
> ought to be on everyone's mind right now. "Every soft fork should be a hard 
> fork, and that soft forks are inherently dangerous because old nodes are 
> tricked to not know what the new nodes are doing" (paraphrased). Whether 
> taproot is dangerous is not the issue; whether old nodes should or should not 
> ignore new rules, is.
> 
> Flag day activation of a soft fork is basically proposing a hard fork, but 
> without saying or doing it at full commitment. May as well just do a flag day 
> hard fork.
> 
> Bitcoin Cash/Bcash has already tested for you how a market driven hard fork 
> should work. Bitcoin didn't die. We should be learning from the mistakes made 
> in those early hard forks to not repeat them when Bitcoin hard forks - like 
> having replay protection written before deployment.
> 
> If it's not evident within the first 6-12 blocks which fork is winning, then 
> the market will trade it out. Just like what happened with Bitcoin Cash/Bcash.
> 
> Not only that, it stops the drama of Bitcoin Core devs from "being in 
> control" of consensus. The market will choose, you just create the safest way 
> for users to participate. The market is consensus. Rough consensus is just 
> the conversation starter.
> 
> 
>> On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, 
>>  wrote:
>> The bitcoin world is close to total gridlock on the question of how to
>> activate taproot. There's no agreement on activation[1][2], and if an
>> agreement isn't reached then nothing happens. That would be really
>> terrible because we'd miss out on the benefits of taproot and
>> potentially other future soft forks.
>> 
>> A major problem with BIP8 is that it would result to a situation where
>> different parts of the bitcoin ecosystem run different consensus rules.
>> Some people will run LOT=true and others LOT=false. Worst of all, it
>> becomes vulnerable to a twitter/reddit/social media blitz which could
>> attempt to move the date of miner activation around.
>> 
>> Twitter and reddit drama provide a perfect cover for social attacks on
>> bitcoin.
>> 
>> Forced signalling leads to brinksmanship. Where two or more sides
>> (backed up by social media drama) enter into a game of chicken with
>> deployed nodes. If one of them doesn't concede then we get a damaging
>> chain split. And the $1 trillion in value that the bitcoin network
>> protects is put at risk. From the point of view of a miner or big
>> exchange stuck in the middle, if they look at the ecosystem of twitter
>> and reddit (especially if you think about all the problems with bots and
>> sockpuppets) they have no idea which consensus rules they should
>> actually follow and exactly what date they take effect. Miners,
>> exchanges, merchants and the rest of the ecosystem exist to serve their
>> customers and users, and trouble happens when they don't know what their
>> customers really want. Social media attacks are not just a theoretical
>> concern; back during the block size drama, the bitcoin reddits were
>> targetted by bots, sockpuppets and brigading[3].
>> 
>> Enter flag day activation. With a flag day there can be no
>> brinksmanship. A social media blitz cant do anything except have its own
>> followers fork away. Crucially, miner signalling cant be used to change
>> the activation date for nodes that didn't choose to and just passively
>> follow signalling. Changing the activation date requires all those users
>> to actually run different node software.
>> 
>> Flag day activation works simply: we choose a block height and after
>> that block height the new taproot rules become enforced.
>> 
>> 
>> Supporters of the permissionless, "users rule" approach of LOT=true
>> should be happy because it completely takes miners out of activation.
>> 
>> Supporters of the safe, conservative approach of LOT=false can be made
>> happy with a few ways of derisking:
>> 
>> * Getting mining pools, businesses and users to look at the code and ask
>> if they (a) think its either neutral or good for their

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

Your Excellency,

You don’t seem to understand how Bitcoin currently works. A signature is a 
mathematical /probabilistical proof that the person who signed (the output) is 
the same person who created the script (the input) that was paid to (i.e. not 
fraud). You cannot see that he is that person, you can only do the math - 
giving yourself a reasonable assurance that it is not a fraud.

Taproot is not a proposed change to this design, so I’m not sure to what 
exactly you are objecting. The math continues to be the sole assurance and 
visibility that the money was created and transferred in accordance with the 
agreed rules (consensus). There is no other way for anyone to “look at” 
potential fraud on the chain.

If you are aware of any flaw in the existing or proposed mathematics that would 
enable fraudulent creation or transfer of bitcoin, please spell it out for us.

e

> On Mar 3, 2021, at 21:10, LORD HIS EXCELLENCY JAMES HRMH 
>  wrote:
> 
> Good Afternoon,
> 
> I will reply privately here, what do you say I am not in support of 
> fungibility? This fungibility is because of consensus including transparency. 
> Otherwise, if it is just a fraud no-one can look at it.
> 
> KING JAMES HRMH
> 
> 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: bitcoin-dev  on behalf 
> of Felipe Micaroni Lalli via bitcoin-dev 
> 
> Sent: Thursday, 4 March 2021 3:30 AM
> To: e...@voskuil.org ; Bitcoin Protocol Discussion 
> 
> Subject: Re: [bitcoin-dev] Taproot NACK
>  
> Dear LORD HIS EXCELLENCY JAMES HRMH (& HMRH), a.k.a. "The Australian",
> 
> This discussion list is serious stuff, please stop making noise. Fungibility 
> is a desirable property, anyway.
> 
> Thank you!
> 
>> On Wed, Mar 3, 2021 at 12:04 PM Eric Voskuil via bitcoin-dev 
>>  wrote:
> > 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

> 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  
Sent: Tuesday, March 2, 2021 6:55 PM
To: Eric Voskuil ; Bitcoin Protocol Discussion 

Cc: Ariel Lorenzo-Luaces 
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 - 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 mailto:e...@voskuil.org> >
Sent: Tuesday, 2 March 2021 9:37 AM
To: LORD HIS EXCELLENCY JAMES HRMH mailto:willt...@live.com.au> >; Bitcoin Protocol Discussion 
mailto:bitcoin-dev@lists.linuxfoundation.org> >
Cc: Ariel Lorenzo-Luaces mailto:ariellua...@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 
mailto:bitcoin-dev@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 ha

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

> 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  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 ; Daniel 
Edgecumbe 
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  on behalf of 
Daniel Edgecumbe via bitcoin-dev mailto:bitcoin-dev@lists.linuxfoundation.org> >
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev mailto:bitcoin-dev@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
em...@esotericnonsense.com <mailto:em...@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 
> >  > <mailto:bitcoin-dev@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 governme

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Eric Voskuil via bitcoin-dev]

I personally don’t like the term 51% attack as applied to censorship. A miner 
is free to mine or not mine any transactions it wants (censor). The term attack 
is better reserved for stealing from someone (reclaiming spends using hash 
power), as it implies a moral distinction.

But 51% attack is the term in common use for a majority censor and using it 
helps people understand the mechanism of hash power soft fork enforcement. It’s 
not intended as a pejorative. 

However “without social support” is a political term. It confuses the actual 
behavior to imply the mechanism is somehow not the same because there is some 
ill-defined level of agreement.

e


> On Mar 2, 2021, at 10:58, Luke Dashjr via bitcoin-dev 
>  wrote:
> 
> On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
>> I'm realizing that a clear advantage of LOT=false is that it can happen
>> without the need for a social movement. All that is really needed is the
>> convincing of 95% miners. Apathetic users will never notice any kind of
>> service disruption no matter the success or failure of the activation. This
>> is obviously why it naturally became the default activation method.
> 
> No. Miners enforcing rules without the social support is a 51% attack, not a 
> softfork.
> 
>> While LOT=true, on the other hand, must be able to 51% the blockchain to
>> win the apathetic users. But then the reorgs will not be pretty. Or if it
>> ever clearly gets over the 51% hurdle then all apathetic users now need to
>> scramble to use the rogue client to be safe from reorgs. Either way it's
>> disruptive.
> 
> No, LOT=True doesn't do this. It only happens if miners choose to create an 
> invalid chain, which they could do at any time with or without a softfork 
> involved.
> 
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Eric Voskuil via bitcoin-dev]

To clarify, it is the soft fork enforcement by majority hash power that is the 
51% attack, not the stopping of it. Majority hash power censors non-conforming 
transactions. To counter it requires only a non-censoring majority to continue 
mining.

It is correct that the purpose of supermajority signaling is to reduce the 
chance of a chain split. It is misleading to call it a bug and to imply that 
user activation isn’t actually intended to create, or at least threaten, a 
chain split. It’s a game of chicken.

e

> On Mar 2, 2021, at 10:22, Chris Belcher via bitcoin-dev 
>  wrote:
> 
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.
> 
> As we vividly saw in the events of the 2017 UASF, the purpose of miner
> signalling isn't to activate or enforce the new rules but to stop a
> chain split. A majority of miners can stop a chain split by essentially
> doing a 51% attack. Such attacks have been known about since day one,
> and even the whitepaper writes about them.
> 
> So they are not a bug but an inherent part of the way bitcoin works. If
> fixing this issue was a simple as setting a consensus rule parameter
> then bitcoin would have been invented decades earlier than it was.
> 
> And certainly miner signalling cannot be compared to an inflation bug.
> The inflation rules are enforced by the economy using full nodes, but
> chain splits or lack of them is enforced by miners. They are two
> different parts of the bitcoin system. Back in 2010 there was an
> inflation bug CVE-2010-5139 (the "Value overflow incident") which proves
> my point. Even though miners created a block which printed 184 billion
> bitcoins, the economy quickly adopted a patch which fixed the bug and
> miners switched over to the correct chain which soon overtook the bugged
> chain (there was a reorg of 53 blocks).
> 
> 
> 
> 
> Also another point: in a hypothetical chain split it's true that the
> LOT=false chain would be vulnerable to reorgs, but it's also true that
> the LOT=true would suffer from slow blocks.
> 
> So for example, imagine trading bitcoin for cash in person, but instead
> of waiting on average 10 minutes for a confirmation you have to wait 2
> hours. Imagine depositing coins to an exchange which requires 3
> confirmation, then instead of waiting ~30 minutes you have to actually
> wait 6 hours. This is a significant degradation in usability. The
> situation is a mirror image of how the LOT=false chain is vulnerable to
> reorgs. Both chains suffer if a chain split happens which is why they
> are pretty important to avoid. That's why its inaccurate to portray
> LOT=true chain as safe with no downsides at all.
> 
> 
> 
> 
>> On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
>> (Note: I am writing this as a general case against LOT=False, but using 
>> Taproot simply as an example softfork. Note that this is addressing 
>> activation under the assumption that the softfork is ethical and has 
>> sufficient community support. If those criteria have not been met, no 
>> activation should be deployed at all, of any type.)
>> 
>> As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, 
>> despite its potential benefits, also leaves open the door to a miner veto. 
>> This was never the intended behaviour, and a bug, which took a rushed 
>> deployment of BIP148 to address. LOT=False would reintroduce that same bug.
>> It wouldn't be much different than adding back the inflation bug 
>> (CVE-2018-17144) and trusting miners not to exploit it.
>> 
>> Some have tried to spin LOT=True as some kind of punishment for miners or 
>> reactive "counter-attack". Rather, it is simply a fallback to avoid 
>> regression on this and other bugs. "Flag day" activation is not 
>> fundamentally 
>> flawed or dangerous, just slow since everyone needs time to upgrade.
>> BIP 8(LOT=True) combines the certainty of such a flag day, with the speed 
>> improvement of a MASF, so that softforks can be activated both reasonably 
>> quick and safely.
>> 
>> In the normal path, and that which BIP8(True) best incentivises, miners will 
>> simply upgrade and signal, and activation can occur as soon as the economic 
>> majority is expected to have had time to upgrade. In the worst-case path, 
>> the 
>> behaviour of LOT=True is the least-harmful result: unambiguous activation 
>> and 
>> enforcement by the economy, with miners either deciding to make an 
>> anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners 
>> revolt against the softfork, the LOT=True nodes are simply faced with a 
>> choice to hardfork (replacing the miners with a PoW change) or concede - 
>> they 
>> do not risk vulnerability or loss.
>> 
>> With LOT=False in the picture, however, things can get messy: some users 
>> will 
>> enforce Taproot(eg) (those running LOT=True), while others will not (those 
>> with LOT=False). Users with LOT=True will still get all the safety thereof, 
>> but those with LO

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

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 
>  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]-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
> 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
> 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 
> Sent: Monday, 1 March 2021 12:07 AM
> To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin Protocol 
> Discussion 
> 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
> 
> 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, 20

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

[Eric Voskuil via bitcoin-dev]

On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev 
mailto:bitcoin-dev@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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Eric Voskuil via bitcoin-dev]

I think it has been shown that an understanding of reasonableness is not 
universal, making any assertion about it as a collective goal kind of 
self-defeating. The question is what is achievable, not what is reasonable. I’m 
not making any value judgements here. Simply pointing out that anything other 
than a successful 51% attack will create a split.

e

> On Feb 28, 2021, at 12:25, Matt Corallo  wrote:
> 
> Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at 
> [1], which I referenced and specifically addressed each of in the OP of this 
> thread.
> 
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
> 
>> On 2/28/21 15:19, Eric Voskuil wrote:
>> In the attempt to change consensus rules there is a simple set of choices:
>> 1) hard fork: creates a chain split
>> 2) soft fork: creates a chain split
>> 3) 51% attack: does not create a chain split
>> The presumption being that one can never assume 100% explicit adoption of 
>> any rule change.
>> A 51% attack can of course fail. It is also possible that signaling can be 
>> untruthful. But miner signaling provides some level of assurance that it 
>> will be successful. This level of assurance is increased by adoption of a 
>> higher than majority threshold, as has been done in the past.
>> Most of the discussion I’ve seen has been focused on who is in charge. 
>> Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nobody 
>> is in charge.
>> The majority of those who mine can choose to enforce censorship any time 
>> they want. They don’t need anyone’s permission. No power is given to them by 
>> developers or anyone else. They have that power based on their own capital 
>> invested.
>> Similarly, the economy (those who accept bitcoin) can enforce any rule 
>> change it wants to. And it can do so at any level of participation that 
>> wants to go along. Anyone can do this, it requires nobody’s permission. 
>> Furthermore, it is possible for the economy to signal its level of agreement 
>> in every transaction, as miners have done in blocks previously.
>> But if the objective is to produce a rule change while avoiding a chain 
>> split, 50% is a much lower bar than 100%. If there is some other objective, 
>> it’s not clear to me what it is.
>> e
 On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev 
  wrote:
>>> 
>>> 
>>> Miners still can generate invalid blocks as a result of SPV mining, and it 
>>> could be profitable to do "bad block enhanced selfish mining" to take 
>>> advantage of it.
>>> 
>>> 
>>> Hard to analyze exactly what that looks like, but...
>>> 
>>> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate 
>>> to mine bad blocks would mean 1/4th of the time you could make 20% of the 
>>> hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One 
>>> could analyze out that the lost hash rate for bad blocks only matters for 
>>> the first difficulty adjustment period you're doing this for too, as the 
>>> hashrate drop will be accounted for -- but then a miner can switch back to 
>>> mining valid chain, giving themselves a larger % of hashrate.
>>> 
>>> So it is still possible that an un-upgraded miner will fail part 3, and 
>>> attempting to accommodate un-upgraded miners leads to some nasty 
>>> oscillating hashrate being optimal.
>>> 
>>> 
>>> --
>>> @JeremyRubin 
>>> 
>>> 
>>> 
 On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo >>> > wrote:
>>> 
>>>Note further that mandatory signaling isn't "just" a flag day - unlike a 
>>> Taproot flag day (where miners running
>>>Bitcoin
>>>Core unmodified today will not generate invalid blocks), a mandatory 
>>> signaling flag day blatantly ignores goal (3)
>>>from
>>>my original post - it results in any miner who has not taken active 
>>> action (and ensured every part of their
>>>often-large
>>>infrastructure has been correctly reconfigured) generating invalid 
>>> blocks.
>>> 
>>>As for "Taproot" took too long, hey, at least if its locked in people 
>>> can just build things assuming it exists. Some
>>>already are, but once its clearly locked in, there's no reason to not 
>>> continue other work at the same time.
>>> 
>>>Matt
>>> 
On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>>>> I agree with much of the logic presented by Matt here.
>>>>
>>>> BIP8 was intended to be simpler to agree on to maintain consensus, yet 
>>> we find ourselves in a situation where a
>>>"tiny"
>>>> parameter has the potential to cause great network disruption and 
>>> confusion (rationality is not too useful a
>>>concept
>>>> here given differing levels of sophistication and information). It is 
>>> therefore much simpler and more likely to be
>>>> universally understood by all network participants to just have a flag 
>>> day. 

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Eric Voskuil via bitcoin-dev]

In the attempt to change consensus rules there is a simple set of choices:

1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split

The presumption being that one can never assume 100% explicit adoption of any 
rule change.

A 51% attack can of course fail. It is also possible that signaling can be 
untruthful. But miner signaling provides some level of assurance that it will 
be successful. This level of assurance is increased by adoption of a higher 
than majority threshold, as has been done in the past.

Most of the discussion I’ve seen has been focused on who is in charge. Bitcoin 
requires no identity; anyone can mine and/or accept bitcoin - nobody is in 
charge.

The majority of those who mine can choose to enforce censorship any time they 
want. They don’t need anyone’s permission. No power is given to them by 
developers or anyone else. They have that power based on their own capital 
invested.

Similarly, the economy (those who accept bitcoin) can enforce any rule change 
it wants to. And it can do so at any level of participation that wants to go 
along. Anyone can do this, it requires nobody’s permission. Furthermore, it is 
possible for the economy to signal its level of agreement in every transaction, 
as miners have done in blocks previously.

But if the objective is to produce a rule change while avoiding a chain split, 
50% is a much lower bar than 100%. If there is some other objective, it’s not 
clear to me what it is.

e

> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev 
>  wrote:
> 
> 
> Miners still can generate invalid blocks as a result of SPV mining, and it 
> could be profitable to do "bad block enhanced selfish mining" to take 
> advantage of it.
> 
> 
> Hard to analyze exactly what that looks like, but...
> 
> E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to 
> mine bad blocks would mean 1/4th of the time you could make 20% of the 
> hashrate mine bad blocks, overall a > 5% (series expansion) benefit. One 
> could analyze out that the lost hash rate for bad blocks only matters for the 
> first difficulty adjustment period you're doing this for too, as the hashrate 
> drop will be accounted for -- but then a miner can switch back to mining 
> valid chain, giving themselves a larger % of hashrate.
> 
> So it is still possible that an un-upgraded miner will fail part 3, and 
> attempting to accommodate un-upgraded miners leads to some nasty oscillating 
> hashrate being optimal.
> 
> 
> --
> @JeremyRubin
> 
> 
>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo  
>> wrote:
>> Note further that mandatory signaling isn't "just" a flag day - unlike a 
>> Taproot flag day (where miners running Bitcoin 
>> Core unmodified today will not generate invalid blocks), a mandatory 
>> signaling flag day blatantly ignores goal (3) from 
>> my original post - it results in any miner who has not taken active action 
>> (and ensured every part of their often-large 
>> infrastructure has been correctly reconfigured) generating invalid blocks.
>> 
>> As for "Taproot" took too long, hey, at least if its locked in people can 
>> just build things assuming it exists. Some 
>> already are, but once its clearly locked in, there's no reason to not 
>> continue other work at the same time.
>> 
>> Matt
>> 
>> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
>> > I agree with much of the logic presented by Matt here.
>> > 
>> > BIP8 was intended to be simpler to agree on to maintain consensus, yet we 
>> > find ourselves in a situation where a "tiny" 
>> > parameter has the potential to cause great network disruption and 
>> > confusion (rationality is not too useful a concept 
>> > here given differing levels of sophistication and information). It is 
>> > therefore much simpler and more likely to be 
>> > universally understood by all network participants to just have a flag 
>> > day. It is easier to communicate what users 
>> > should do and when.
>> > 
>> > This is ultimately not coercive to users because the upgrade for Taproot 
>> > itself is provable and analyzable on its own, 
>> > but activation parameters based on what % of economically relevant nodes 
>> > are running an upgrade by a certain date are 
>> > not. Selecting these sorts of complicated consensus parameters may 
>> > ultimately present more opportunity for a cooptable 
>> > consensus process than something more straightforward.
>> > 
>> > 
>> > That said, a few points strike me as worth delving into.
>> > 
>> > 
>> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory 
>> > signaling is effectively 2 flag days -- one for 
>> > the signaling rule, 1 for the taproot type. The reason for the 2 week gap 
>> > between flag day for signaling and flag day 
>> > for taproot rules is, more or less, so that nodes who aren't taproot ready 
>> > at the 1st flag day do not end up SPV mining 
>> > (using standardness rules in mempool prevents

Re: [bitcoin-dev] Out-of-band transaction fees

[Eric Voskuil via bitcoin-dev]

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  On Behalf Of 
Sebastian Geisler via bitcoin-dev
Sent: Monday, November 30, 2020 3:03 PM
To: bitcoin-dev@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

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

I see no requirement for anything here apart from exchanging a list of 
supported “features”. Conditionally hiding a feature provides no benefit. Any 
peer that wants it can get it (obfuscation being weak security), and otherwise 
it’s a non-issue.

e

> On Aug 24, 2020, at 13:22, Jeremy  wrote:
> 
>> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil  wrote:
>> I said security, not privacy. You are in fact exposing the feature to any 
>> node that wants to negotiate for it. if you don’t want to expose the buggy 
>> feature, then disable it. Otherwise you cannot prevent peers from accessing 
>> it. Presumably peers prefer the new feature if they support it, so there is 
>> no need for this complexity.
> 
> I interpreted " This seems to imply a security benefit (I can’t discern any 
> other rationale for this complexity). It should be clear that this is no more 
> than trivially weak obfuscation and not worth complicating the protocol to 
> achieve.", to be about obfuscation and therefore privacy.
> 
> The functionality that I'm mentioning might not be buggy, it might just not 
> support peers who don't support another feature. You can always disconnect a 
> peer who sends a message that you didn't handshake on (or maybe we should 
> elbow bump given the times).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

I said security, not privacy. You are in fact exposing the feature to any node 
that wants to negotiate for it. if you don’t want to expose the buggy feature, 
then disable it. Otherwise you cannot prevent peers from accessing it. 
Presumably peers prefer the new feature if they support it, so there is no need 
for this complexity.

e

> On Aug 24, 2020, at 12:59, Jeremy  wrote:
> 
> 
>> 
>> >> On 8/21/20 5:17 PM, Jeremy wrote:
>> >> As for an example of where you'd want multi-round, you could imagine a 
>> >> scenario where you have a feature A which gets bugfixed by the 
>> >> introduction of feature B, and you don't want to expose that you support 
>> >> A unless you first negotiate B. Or if you can negotiate B you should 
>> >> never expose A, but for old nodes you'll still do it if B is unknown to 
>> >> them.
>> 
>> This seems to imply a security benefit (I can’t discern any other rationale 
>> for this complexity). It should be clear that this is no more than trivially 
>> weak obfuscation and not worth complicating the protocol to achieve.
> 
> 
> The benefit is not privacy oriented and I didn't intend to imply as such. The 
> benefit is that you may only wish to expose functionality to peers which 
> support some other set of features. For example, with wtxid relay, I might 
> want to expose some additional functionality after establishing my peer 
> supports it, that peers which do not have wtxid relay should not be allowed 
> to use. The benefit over just exposing all functions is then a node might be 
> programmed to support the new feature but not wtxid relay, which can lead to 
> some incompatibilities.
> 
> You cannot implement this logic as a purely post-hoc "advertise all and then 
> figure out what is allowed" because then you require strict consistency 
> between peers of that post-hoc feature availability implication map.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

> On Aug 21, 2020, at 13:45, Matt Corallo  wrote:
> 
> This seems to be pretty overengineered.

I agree. In fact all proposals I’ve seen on this are over engineered.

> Do you have a specific use-case in mind for anything more than simply 
> continuing the pattern we've been using of sending a message indicating 
> support for a given feature?

Correct me if I’m wrong, but this pattern is what the proposal aims to 
eliminate. There is no reason whatsoever for a message per indication. The 
appropriate pattern is already established in the implementation of service 
bits. In fact in this discussion it has been pointed out that the problem with 
service bits is simply too few bits.

> If we find some in the future,

> we could deploy something like this, though the current proposal makes it 
> possible to do it on a per-feature case.

As does any other proposal, including passage of the full set of optional 
sub-protocols in the verack.

> The great thing about Suhas' proposal is the diff is about -1/+1 (not 
> including tests), while still getting all the flexibility we need.

> Even better, the code already exists.

This is neither true nor relevant. Maybe the Segwit 2X guys should have used 
this argument.

e


> Matt
> 
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> I have a proposal:
>> Protocol >= 70016 cease to send or process VERACK, and instead use 
>> HANDSHAKEACK, which is completed after feature negotiation.
>> This should make everyone happy/unhappy, as in a new protocol number it's 
>> fair game to change these semantics to be clear that we're acking more than 
>> version.
>> I don't care about when or where these messages are sequenced overall, it 
>> seems to have minimal impact. If I had free choice, I slightly agree with 
>> Eric that verack should come before feature negotiation, as we want to 
>> divorce the idea that protocol number and feature support are tied.
>> But once this is done, we can supplant Verack with HANDSHAKENACK or 
>> HANDSHAKEACK to signal success or failure to agree on a connection. A NACK 
>> reason (version too high/low or an important feature missing) could be 
>> optional. Implicit NACK would be disconnecting, but is discouraged because a 
>> peer doesn't know if it should reconnect or the failure was intentional.
>> --
>> AJ: I think I generally do prefer to have a FEATURE wrapper as you 
>> suggested, or a rule that all messages in this period are interpreted as 
>> features (and may be redundant with p2p message types -- so you can 
>> literally just use the p2p message name w/o any data).
>> I think we would want a semantic (which could be based just on message 
>> names, but first-class support would be nice) for ACKing that a feature is 
>> enabled. This is because a transcript of:
>> NODE0:
>> FEATURE A
>> FEATURE B
>> VERACK
>> NODE1:
>> FEATURE A
>> VERACK
>> It remains unclear if Node 1 ignored B because it's an unknown feature, or 
>> because it is disabled. A transcript like:
>> NODE0:
>> FEATURE A
>> FEATURE B
>> FEATURE C
>> ACK A
>> VERACK
>> NODE1:
>> FEATURE A
>> ACK A
>> NACK B
>> VERACK
>> would make it clear that A and B are known, B is disabled, and C is unknown. 
>> C has 0 support, B Node 0 should support inbound messages but knows not to 
>> send to Node 1, and A has full bilateral support. Maybe instead it could a 
>> message FEATURE SEND A and FEATURE RECV A, so we can make the split explicit 
>> rather than inferred from ACK/NACK.
>> --
>> I'd also propose that we add a message which is SYNC, which indicates the 
>> end of a list of FEATURES and a request to send ACKS or NACKS back (which 
>> are followed by a SYNC). This allows multi-round negotiation where based on 
>> the presence of other features, I may expand the set of features I am 
>> offering. I think you could do without SYNC, but there are more edge cases 
>> and the explicitness is nice given that this already introduces future 
>> complexity.
>> This multi-round makes it an actual negotiation rather than a pure 
>> announcement system. I don't think it would be used much in the near term, 
>> but it makes sense to define it correctly now. Build for the future and 
>> all...
>> --
>> @JeremyRubin 
>> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

> On Aug 21, 2020, at 15:16, Matt Corallo  wrote:
> 
> Hmm, could that not be accomplished by simply building this into new 
> messages? eg, send "betterprotocol", if you see a verack and no 
> "betterprotocol" from your peer, send "worseprotocol" before you send a 
> "verack".
> 
> Matt
> 
>> On 8/21/20 5:17 PM, Jeremy wrote:
>> As for an example of where you'd want multi-round, you could imagine a 
>> scenario where you have a feature A which gets bugfixed by the introduction 
>> of feature B, and you don't want to expose that you support A unless you 
>> first negotiate B. Or if you can negotiate B you should never expose A, but 
>> for old nodes you'll still do it if B is unknown to them.

This seems to imply a security benefit (I can’t discern any other rationale for 
this complexity). It should be clear that this is no more than trivially weak 
obfuscation and not worth complicating the protocol to achieve.

>> An example of this would be (were it not already out without a feature 
>> negotiation existing) WTXID/TXID relay.
>> The SYNC primitve simply codifies what order messages should be in and when 
>> you're done for a phase of negotiation offering something. It can be done 
>> without, but then you have to be more careful to broadcast in the correct 
>> order and it's not clear when/if you should wait for more time before 
>> responding.
>> On Fri, Aug 21, 2020 at 2:08 PM Jeremy > > wrote:
>>Actually we already have service bits (which are sadly limited) which 
>> allow negotiation of non bilateral feature
>>support, so this would supercede that.
>>--
>>@JeremyRubin 
>> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

Service bits are advertised, protocol support is not.

https://en.bitcoin.it/wiki/Protocol_documentation#Network_address

e

> On Aug 21, 2020, at 14:08, Jeremy  wrote:
> 
> 
> Actually we already have service bits (which are sadly limited) which allow 
> negotiation of non bilateral feature support, so this would supercede that.
> --
> @JeremyRubin
> 
> 
>> On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo  
>> wrote:
>> This seems to be pretty overengineered. Do you have a specific use-case in 
>> mind for anything more than simply continuing 
>> the pattern we've been using of sending a message indicating support for a 
>> given feature? If we find some in the future, 
>> we could deploy something like this, though the current proposal makes it 
>> possible to do it on a per-feature case.
>> 
>> The great thing about Suhas' proposal is the diff is about -1/+1 (not 
>> including tests), while still getting all the 
>> flexibility we need. Even better, the code already exists.
>> 
>> Matt
>> 
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> > I have a proposal:
>> > 
>> > Protocol >= 70016 cease to send or process VERACK, and instead use 
>> > HANDSHAKEACK, which is completed after feature 
>> > negotiation.
>> > 
>> > This should make everyone happy/unhappy, as in a new protocol number it's 
>> > fair game to change these semantics to be 
>> > clear that we're acking more than version.
>> > 
>> > I don't care about when or where these messages are sequenced overall, it 
>> > seems to have minimal impact. If I had free 
>> > choice, I slightly agree with Eric that verack should come before feature 
>> > negotiation, as we want to divorce the idea 
>> > that protocol number and feature support are tied.
>> > 
>> > But once this is done, we can supplant Verack with HANDSHAKENACK or 
>> > HANDSHAKEACK to signal success or failure to agree 
>> > on a connection. A NACK reason (version too high/low or an important 
>> > feature missing) could be optional. Implicit NACK 
>> > would be disconnecting, but is discouraged because a peer doesn't know if 
>> > it should reconnect or the failure was 
>> > intentional.
>> > 
>> > --
>> > 
>> > AJ: I think I generally do prefer to have a FEATURE wrapper as you 
>> > suggested, or a rule that all messages in this period 
>> > are interpreted as features (and may be redundant with p2p message types 
>> > -- so you can literally just use the p2p 
>> > message name w/o any data).
>> > 
>> > I think we would want a semantic (which could be based just on message 
>> > names, but first-class support would be nice) for 
>> > ACKing that a feature is enabled. This is because a transcript of:
>> > 
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > VERACK
>> > 
>> > NODE1:
>> > FEATURE A
>> > VERACK
>> > 
>> > It remains unclear if Node 1 ignored B because it's an unknown feature, or 
>> > because it is disabled. A transcript like:
>> > 
>> > NODE0:
>> > FEATURE A
>> > FEATURE B
>> > FEATURE C
>> > ACK A
>> > VERACK
>> > 
>> > NODE1:
>> > FEATURE A
>> > ACK A
>> > NACK B
>> > VERACK
>> > 
>> > would make it clear that A and B are known, B is disabled, and C is 
>> > unknown. C has 0 support, B Node 0 should support 
>> > inbound messages but knows not to send to Node 1, and A has full bilateral 
>> > support. Maybe instead it could a message 
>> > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit 
>> > rather than inferred from ACK/NACK.
>> > 
>> > 
>> > --
>> > 
>> > I'd also propose that we add a message which is SYNC, which indicates the 
>> > end of a list of FEATURES and a request to 
>> > send ACKS or NACKS back (which are followed by a SYNC). This allows 
>> > multi-round negotiation where based on the presence 
>> > of other features, I may expand the set of features I am offering. I think 
>> > you could do without SYNC, but there are more 
>> > edge cases and the explicitness is nice given that this already introduces 
>> > future complexity.
>> > 
>> > This multi-round makes it an actual negotiation rather than a pure 
>> > announcement system. I don't think it would be used 
>> > much in the near term, but it makes sense to define it correctly now. 
>> > Build for the future and all...
>> > 
>> > 
>> > 
>> > --
>> > @JeremyRubin 
>> > 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

I’m pretty sure one can run whatever they want even without a BIP. There is 
nobody here to do any “allowing”. On the other hand, standards development is 
tedious for good reason.

Generally speaking, overloading is a primary source of complexity (creating 
more branches in code and human explanation). Nevertheless this is verack 
payload, no additional messages are necessary or helpful.

e

> On Aug 21, 2020, at 07:15, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> Sure, we could do a new message for negotiation, but there doesn’t seem to 
> be a lot of reason for it - using the same namespace for negotiation seems 
> fine too. In any case, this is one of those things that doesn’t matter in the 
> slightest, and if one person volunteers to write a BIP and code, no reason 
> they shouldn’t just decide and be allowed to run with it. Rough consensus and 
> running code, as it were :)
> 
> Matt
> 
> 
>>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev 
>>>  wrote:
>>> 
>>> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev 
>>> wrote:
>>> In thinking about the mechanism used there, I thought it would be helpful to
>>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>>> messages received before a VERACK.  A draft of my proposal is available here
>>> [2].
>> 
>> Rather than allowing arbitrary messages, maybe it would make sense to
>> have a specific feature negotiation message, eg:
>> 
>> VERSION ...
>> FEATURE wtxidrelay
>> FEATURE packagerelay
>> VERACK
>> 
>> with the behaviour being that it's valid only between VERSION and VERACK,
>> and it takes a length-prefixed-string giving the feature name, optional
>> additional data, and if the feature name isn't recognised the message
>> is ignored.
>> 
>> If we were to support a "polite disconnect" feature like Jeremy suggested,
>> it might be easier to do that for a generic FEATURE message, than
>> reimplement it for the message proposed by each new feature.
>> 
>> Cheers,
>> aj
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

Hi Anthony,

This is what I was implying in my last post (the reference to the unnecessary 
overload of message typing). However, if one imagines a sequence diagram for 
this communication it becomes obvious that all such messages are 100% redundant 
with verack.

e

> On Aug 20, 2020, at 19:37, Anthony Towns via bitcoin-dev 
>  wrote:
> 
> On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev 
> wrote:
>> In thinking about the mechanism used there, I thought it would be helpful to
>> codify in a BIP the idea that Bitcoin network clients should ignore unknown
>> messages received before a VERACK.  A draft of my proposal is available here
>> [2].
> 
> Rather than allowing arbitrary messages, maybe it would make sense to
> have a specific feature negotiation message, eg:
> 
>  VERSION ...
>  FEATURE wtxidrelay
>  FEATURE packagerelay
>  VERACK
> 
> with the behaviour being that it's valid only between VERSION and VERACK,
> and it takes a length-prefixed-string giving the feature name, optional
> additional data, and if the feature name isn't recognised the message
> is ignored.
> 
> If we were to support a "polite disconnect" feature like Jeremy suggested,
> it might be easier to do that for a generic FEATURE message, than
> reimplement it for the message proposed by each new feature.
> 
> Cheers,
> aj
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

> On Aug 18, 2020, at 11:25, Matt Corallo  wrote:
> 
> On 8/18/20 2:11 PM, Eric Voskuil wrote:
> - snip -
>>> Still, I think we're talking pedantics here, and not in a useful way.
>> Not to be pedantic, but I don’t know what that means.
> 
> It means that part of the discussion is not useful, and not worth bothering 
> to go back and figure out what was shipped before the version increase and 
> what wasn't, lets talk about what makes sense for the future :).

When the discussion centers on backward compatibility, and there is confusion 
over what that actually implies, this is a central question. You snipped the 
bit about what actually constitutes the existing protocol. I have implemented 
every aspect of the protocol that is widely deployed, and I can say without 
question that the protocol does not require a peer to accept arbitrary 
messages. In other words, your statement on the subject was a very relevant 
factual error. Furthermore no reason has been demonstrated here to accept 
arbitrary traffic.

>>> Ultimately we need some kind of negotiation which is flexible in allowing 
>>> different software to negotiate different features without a global 
>>> lock-step version number increase.
>> I have shown below how that already works.
>>> Or, to put it another way, if a feature is fully optional, why should there 
>>> be a version number increase for it
>> For the reasons previously given.
>>> - the negotiation of it is independent and a version number only increases 
>>> confusion over which change "owns" a given version number.
>> Presumably this is why we have a standards process. Any new message implies 
>> ownership. Deconflicting that is required, which implies it can easily be 
>> version associated (as it has been).
> 
> I think the point is, this doesn't work today, bumping the protocol version 
> requires everyone agreeing on which features make sense,

As I have shown, this is not the case. While I have given my support to 
simplifying the process, we should not proceed based on an incorrect 
understanding of actual behavior.

> and as we can see from this email thread alone, that isn't a common result in 
> this community. People happily ignore BIPs that make no sense, of which there 
> are a lot, and they should totally be able to do that!
> 
> You can say that the current world works, but there's a reason over time 
> we've shifted away from the original "shove another bit on the end of the 
> version message, and everyone agrees on the order of those bits for new 
> feature negotiation." Version bumping is an extension of that, really.

Actually the protocol has not done this. It has used the version to signal a 
new sub-protocol, and then in some cases that sub-protocol has been made 
optional through subsequent negotiation. What is being proposed here is to 
simplify that process by collapsing the secondary negotiation into the 
handshake.

In fact I argued against this secondary ad-hoc negotiation when it began. Now 
we are coming around to recognizing that it’s a handshake issue, as I said at 
the time. I’m glad to see that.

>>> I presume you'd support a single message that lists the set of features 
>>> which a node (optionally) wishes to support on the connection. This 
>>> proposal is fully equivalent to that, instead opting to list them as 
>>> individual messages instead of one message, which is a bit nicer in that 
>>> they can be handled more independently or by different subsystems including 
>>> even the message hashing.
>> This presumes an implementation. As part of the handshake, collection of an 
>> arbitrary set of messages is a significant and unnecessary complication *of 
>> the protocol*. Extension of the verack is not. It is the simplest change 
>> possible to implement the desired behavior. Each peer simply supplies the 
>> matrix of sub-protocols it supports and only those supported by both are 
>> allowed. There is no reason for the protocol to split that matrix up into 
>> multiple messages, requiring termination. Independent messages exist because 
>> of timing or ordering requirements. Implementing dependent messages as if 
>> they were independent is wasteful and complicating.
> 
> Some things may need further negotiation. eg compact blocks sends multiple 
> redundant messages with different versions and then deduces the correct 
> version based on the message ordering and version set supported. Doing this 
> via verack locks you into a very specific possible negotiation protocols.

This is a moot point. Whether a list of supported optional sub-protocols is 
listed in one or multiple messages in the handshake would not change this.

> You could extend it further and suggest a verack K-V list which allows for 
> more flexible negotiation, but I'm not sure that it isn't more complicated 
> than just shoving more messages on the wire.

There is no difference between a constrained set of key-value pairs and a 
distinct set of options, so there is no additional c

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

> On Aug 18, 2020, at 10:26, Matt Corallo  wrote:
> 
> There are several cases where a new message has been sent as a part of a 
> negotiation without changing the protocol version.

Such as?

> You may chose to ignore that, but that doesn't mean that it isn't an 
> understood and even relied upon feature of the Bitcoin P2P protocol. If you 
> wish to fail connections to new nodes (and risk network splits, as Suhas 
> points out), then you may do so, but that doesn't make it a part of the 
> Bitcoin P2P protocol that you must do so. Of course there is no "official 
> document" by which we can make a formal appeal, but historical precedent 
> suggests otherwise.

You are misrepresenting “historical precedent”. I’ve seen several attempts to 
require arbitrary traffic over the years and none have been realized.

> Still, I think we're talking pedantics here, and not in a useful way.

Not to be pedantic, but I don’t know what that means.

> Ultimately we need some kind of negotiation which is flexible in allowing 
> different software to negotiate different features without a global lock-step 
> version number increase.

I have shown below how that already works.

> Or, to put it another way, if a feature is fully optional, why should there 
> be a version number increase for it

For the reasons previously given.

> - the negotiation of it is independent and a version number only increases 
> confusion over which change "owns" a given version number.

Presumably this is why we have a standards process. Any new message implies 
ownership. Deconflicting that is required, which implies it can easily be 
version associated (as it has been).

> I presume you'd support a single message that lists the set of features which 
> a node (optionally) wishes to support on the connection. This proposal is 
> fully equivalent to that, instead opting to list them as individual messages 
> instead of one message, which is a bit nicer in that they can be handled more 
> independently or by different subsystems including even the message hashing.

This presumes an implementation. As part of the handshake, collection of an 
arbitrary set of messages is a significant and unnecessary complication *of the 
protocol*. Extension of the verack is not. It is the simplest change possible 
to implement the desired behavior. Each peer simply supplies the matrix of 
sub-protocols it supports and only those supported by both are allowed. There 
is no reason for the protocol to split that matrix up into multiple messages, 
requiring termination. Independent messages exist because of timing or ordering 
requirements. Implementing dependent messages as if they were independent is 
wasteful and complicating.

I’m well aware of the inefficiency produced by version linearity in the face of 
optional sub-protocols. The protocol must negotiate to the version where it can 
then negotiate support, which has been done. I support creating a simpler 
system, eliminating these extra messages. The existing numeric version can be 
reserved exclusively for “must” implement, and can be used to signal an 
extension to the verack. The verack can then carry a list of “may” or “should” 
sub-protocols for final negotiation.

The format of the matrix is arbitrary, but the requirement is to list a set of 
optional sub-protocols. This implies a namespace. This implies “ownership“ of 
names. In other words, that coordination requirement is not eliminated.

e

> Matt
> 
>> On 8/18/20 12:54 PM, Eric Voskuil wrote:
>> “Bitcoin protocol has always expected clients to ignore unknown messages”
>> This is not true. Bitcoin has long implemented version negotiation, which is 
>> the opposite expectation. Libbitcoin’s p2p protocol implementation 
>> immediately drops a peer that sends an invalid message according to the 
>> negotiated version. The fact that a given client does not validate the 
>> protocol does not make it an expectation that the protocol not be validated.
>> Features can clearly be optional within an actual protocol. There have been 
>> post-handshake negotiations implemented for optional messages which are 
>> valid at the negotiated version. The protocol may be flexible while 
>> remaining validateable. There is no reason to force a client to accept 
>> unknown message traffic.
>> A generalized versioning change can be implemented in or after the 
>> handshake. The latter is already done on an ad-hoc basis. The former is 
>> possible as long as the peer’s version is sufficient to be aware of the 
>> behavior. This does not imply any need to send invalid messages. The verack 
>> itself can simply be extended with a matrix of feature support. There is no 
>> reason to complicate negotiation with an additional message(s).
>> FWIW, bip37 did this poorly, adding a feature field to the version message, 
>> resulting in bip60. Due to this design, older protocol-validating clients 
>> were broken. In this case it was message length that was presumed to not be 
>> 

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

“Bitcoin protocol has always expected clients to ignore unknown messages”

This is not true. Bitcoin has long implemented version negotiation, which is 
the opposite expectation. Libbitcoin’s p2p protocol implementation immediately 
drops a peer that sends an invalid message according to the negotiated version. 
The fact that a given client does not validate the protocol does not make it an 
expectation that the protocol not be validated.

Features can clearly be optional within an actual protocol. There have been 
post-handshake negotiations implemented for optional messages which are valid 
at the negotiated version. The protocol may be flexible while remaining 
validateable. There is no reason to force a client to accept unknown message 
traffic.

A generalized versioning change can be implemented in or after the handshake. 
The latter is already done on an ad-hoc basis. The former is possible as long 
as the peer’s version is sufficient to be aware of the behavior. This does not 
imply any need to send invalid messages. The verack itself can simply be 
extended with a matrix of feature support. There is no reason to complicate 
negotiation with an additional message(s).

FWIW, bip37 did this poorly, adding a feature field to the version message, 
resulting in bip60. Due to this design, older protocol-validating clients were 
broken. In this case it was message length that was presumed to not be 
validated.

e

> On Aug 18, 2020, at 07:59, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> This sounds like a great idea!
> 
> Bitcoin is no longer a homogeneous network of one client - it is many, with 
> different features implemented in each. The Bitcoin protocol hasn't (fully) 
> evolved to capture that reality. Initially the Bitcoin protocol had a simple 
> numerical version field, but that is wholly impractical for any diverse 
> network - some clients may not wish to implement every possible new relay 
> mechanic, and why should they have to in order to use other new features?
> 
> Bitcoin protocol changes have, many times in recent history, been made via 
> new dummy "negotiation" messages, which take advantage of the fact that the 
> Bitcoin protocol has always expected clients to ignore unknown messages. 
> Given that pattern, it makes sense to have an explicit negotiation phase - 
> after version and before verack, just send the list of features that you 
> support to negotiate what the connection will be capable of. The exact way we 
> do that doesn't matter much, and sending it as a stream of messages which 
> each indicate support for a given protocol feature perfectly captures the 
> pattern that has been used in several recent network upgrades, keeping 
> consistency.
> 
> Matt
> 
>> On 8/14/20 3:28 PM, Suhas Daftuar via bitcoin-dev wrote:
>> Hi,
>> Back in February I posted a proposal for WTXID-based transaction relay[1] 
>> (now known as BIP 339), which included a proposal for feature negotiation to 
>> take place prior to the VERACK message being received by each side.  In my 
>> email to this list, I had asked for feedback as to whether that proposal was 
>> problematic, and didn't receive any responses.
>> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, 
>> though it has not yet been released.
>> In thinking about the mechanism used there, I thought it would be helpful to 
>> codify in a BIP the idea that Bitcoin network clients should ignore unknown 
>> messages received before a VERACK.  A draft of my proposal is available 
>> here[2].
>> I presume that software upgrading past protocol version 70016 was already 
>> planning to either implement BIP 339, or ignore the wtxidrelay message 
>> proposed in BIP 339 (if not, then this would create network split concerns 
>> in the future -- so I hope that someone would speak up if this were a 
>> problem).  When we propose future protocol upgrades that would benefit from 
>> feature negotiation at the time of connection, I think it would be nice to 
>> be able to use the same method as proposed in BIP 339, without even needing 
>> to bump the protocol version.  So having an understanding that this is the 
>> standard of how other network clients operate would be helpful.
>> If, on the other hand, this is problematic for some reason, I look forward 
>> to hearing that as well, so that we can be careful about how we deploy 
>> future p2p changes to avoid disruption.
>> Thanks,
>> Suhas Daftuar
>> [1] 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
>>  
>> 
>> [2] 
>> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
>>  
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

Hi Suhas,

It seems to me that your first two paragraphs contradict each other, so I’m not 
sure we have understanding. As you say in the first paragraph, a peer would 
never get messages that it does not understand, so there is no chance that 
missing a protocol change would matter.

In case it’s not understood, version negotiation provides each peer with the 
maximum supported protocol version of the other. Once complete both have 
negotiated to the highest common version. No message not supported at that 
version may be sent by either.

If the protocol was to accept *any* message traffic then it will cease to be a 
protocol. People will drop in their changes without obtaining broad support, 
and peers will evolve to the point of no longer being peers. They won’t speak 
the same language and the “network” will be little more than a broadcast 
transport, broadcasting all traffic to all peers, whether it’s for them or not.

People need to either build support or build a distinct network. That’s the 
actual coordination issue, which is inherent to protocol development.

Best,
e

> On Aug 17, 2020, at 13:40, Suhas Daftuar  wrote:
> 
> Hi Eric,
> 
> Thanks for your response.  If I understand correctly, you're suggesting that 
> in the future we do the same as what was done in BIP 339, of accompanying new 
> messages (which are optional) with a protocol version bump, so that network 
> clients are never reading unknown messages from a peer (and can be free to 
> disconnect a peer for sending an unknown message)?
> 
> I think that works fine, so if indeed there will be software that will expect 
> things to operate this way then I can withdraw the suggestion I've made in 
> this thread.  However I wanted to clarify that this is what you suggest, 
> because there is another downside to this approach (beyond the sequential 
> nature of sequence numbers that you mention) -- if a software implementation 
> misses a proposed new protocol upgrade, and thus fails to parse (and ignore) 
> some proposed new message, the result can be a network split down the road as 
> incompatible clients get slowly upgraded over time. 
> 
> I think this coordination cost is something to be concerned about -- for 
> instance, the lack of response to my wtxid-relay proposal made me wonder if 
> other software would be implementing something to account for the new message 
> that proposal introduces (for clients with version >= 70016).  It's 
> reasonable for people to be busy and miss things like this, and I think it's 
> worth considering whether there's a safer way for us to deploy changes.
> 
> That said, I don't think this coordination cost is unbearable, so as long as 
> we have a process for making p2p protocol improvements I'm not too worried 
> about what mechanism we use.  So if this concern over coordination of changes 
> doesn't sway you, I think we can continue to just bump protocol version at 
> the same time as deploying new messages, as we have been doing, and hope that 
> we don't run into problems down the road.  
> 
> If I have misunderstood how you think we should be making future protocol 
> changes, please let me know.
> 
> Thanks,
> Suhas
> 
> 
> 
>> On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil  wrote:
>> A requirement to ignore unknown (invalid) messages is not only a protocol 
>> breaking change but poor protocol design. The purpose of version negotiation 
>> is to determine the set of valid messages. Changes to version negotiation 
>> itself are very problematic.
>> 
>> The only limitation presented by versioning is that the system is 
>> sequential. As such, clients that do not wish to implement (or operators who 
>> do not wish to enable) them are faced with a problem when wanting to support 
>> later features. This is resolvable by making such features optional at the 
>> new protocol level. This allows each client to limit its communication to 
>> the negotiated protocol, and allows ignoring of known but 
>> unsupported/disabled features.
>> 
>> Sorry I missed your earlier post. Been distracted for a while.
>> 
>> e
>> 
>> 
 On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev 
  wrote:
 
>>> 
>>> Hi,
>>> 
>>> Back in February I posted a proposal for WTXID-based transaction relay[1] 
>>> (now known as BIP 339), which included a proposal for feature negotiation 
>>> to take place prior to the VERACK message being received by each side.  In 
>>> my email to this list, I had asked for feedback as to whether that proposal 
>>> was problematic, and didn't receive any responses.
>>> 
>>> Since then, the implementation of BIP 339 has been merged into Bitcoin 
>>> Core, though it has not yet been released.
>>> 
>>> In thinking about the mechanism used there, I thought it would be helpful 
>>> to codify in a BIP the idea that Bitcoin network clients should ignore 
>>> unknown messages received before a VERACK.  A draft of my proposal is 
>>> available here[2].
>>> 
>>> I presume that software upgradi

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil via bitcoin-dev]

A requirement to ignore unknown (invalid) messages is not only a protocol 
breaking change but poor protocol design. The purpose of version negotiation is 
to determine the set of valid messages. Changes to version negotiation itself 
are very problematic.

The only limitation presented by versioning is that the system is sequential. 
As such, clients that do not wish to implement (or operators who do not wish to 
enable) them are faced with a problem when wanting to support later features. 
This is resolvable by making such features optional at the new protocol level. 
This allows each client to limit its communication to the negotiated protocol, 
and allows ignoring of known but unsupported/disabled features.

Sorry I missed your earlier post. Been distracted for a while.

e


> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev 
>  wrote:
> 
> 
> Hi,
> 
> Back in February I posted a proposal for WTXID-based transaction relay[1] 
> (now known as BIP 339), which included a proposal for feature negotiation to 
> take place prior to the VERACK message being received by each side.  In my 
> email to this list, I had asked for feedback as to whether that proposal was 
> problematic, and didn't receive any responses.
> 
> Since then, the implementation of BIP 339 has been merged into Bitcoin Core, 
> though it has not yet been released.
> 
> In thinking about the mechanism used there, I thought it would be helpful to 
> codify in a BIP the idea that Bitcoin network clients should ignore unknown 
> messages received before a VERACK.  A draft of my proposal is available 
> here[2].
> 
> I presume that software upgrading past protocol version 70016 was already 
> planning to either implement BIP 339, or ignore the wtxidrelay message 
> proposed in BIP 339 (if not, then this would create network split concerns in 
> the future -- so I hope that someone would speak up if this were a problem).  
> When we propose future protocol upgrades that would benefit from feature 
> negotiation at the time of connection, I think it would be nice to be able to 
> use the same method as proposed in BIP 339, without even needing to bump the 
> protocol version.  So having an understanding that this is the standard of 
> how other network clients operate would be helpful.
> 
> If, on the other hand, this is problematic for some reason, I look forward to 
> hearing that as well, so that we can be careful about how we deploy future 
> p2p changes to avoid disruption.
> 
> Thanks,
> Suhas Daftuar
> 
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
> 
> [2] 
> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block solving slowdown question/poll

[Eric Voskuil via bitcoin-dev]

Mining is a lottery.

e

> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev 
>  wrote:
> 
> 
> There seems to be the real possibility that miners are simply trying to 
> optimise mining profit by limiting the average hash rate during the 
> retargeting, saving some electricity but poorly considering the overall 
> situation where they give opportunity to other miners probably raising the 
> hashrate for the next period. It is far more profitable for the ecosystem 
> considering the whole to hold a lottery for minig as has been discussed 
> elsewhere some time ago.
> 
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
> 
> 
> From: bitcoin-dev  on behalf 
> of David A. Harding via bitcoin-dev 
> Sent: Sunday, 22 March 2020 6:54 PM
> To: Dave Scotese ; Bitcoin Protocol Discussion 
> 
> Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
>  
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons.  I'm
> > curious to know if anyone has ideas on how this might be handled
> 
> There are only two practical solutions I'm aware of:
> 
> 1. Do nothing
> 2. Hard fork a difficulty reduction
> 
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
> 
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
> 
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

[Eric Voskuil via bitcoin-dev]

> On Nov 8, 2019, at 11:16, David A. Harding via bitcoin-dev 
>  wrote:
> 
> On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev 
> wrote:
>> In the current draft, witness v1 outputs of length other
>> than 32 remain unencumbered, which means that for now such an
>> insertion or erasure would result in an output that can be spent by
>> anyone. If that is considered unacceptable, it could be prevented by
>> for example outlawing v1 witness outputs of length 31 and 33.
> 
> Either a consensus rule or a standardness rule[1] would require anyone
> using a bech32 library supporting v1+ segwit to upgrade their library.
> Otherwise, users of old libraries will still attempt to pay v1 witness
> outputs of length 31 or 33, causing their transactions to get rejected
> by newer nodes or get stuck on older nodes.  This is basically the
> problem #15846[2] was meant to prevent.
> 
> If we're going to need everyone to upgrade their bech32 libraries
> anyway, I think it's probably best that the problem is fixed in the
> bech32 algorithm rather than at the consensus/standardness layer.

As an implementer of both the address encoding and script validation, I agree.

e

> -Dave
> 
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017444.html
> [2] https://github.com/bitcoin/bitcoin/pull/15846
> 
> P.S. My thanks as well to the people who asked the question during
> review that lead to this discussion:
> 
> 
> http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html#l-88
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trustless hash-price insurance contracts

[Eric Voskuil via bitcoin-dev]

.
>>>> > 
>>>> > An analogy would be car insurance. If you are an excellent driver you 
>>>> > wouldn't be willing to spend a ton of money to protect your car in the 
>>>> > event of an accident, but if it is cheap enough you would. And there may 
>>>> > be people that are unwilling to take the risk of a damaged car that 
>>>> > refrain from becoming drivers until insurance allows them to lower the 
>>>> > worst case scenario of a damaged car.
>>>> > 
>>>> > -JW
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > ‐‐‐ Original Message ‐‐‐
>>>> >> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil  
>>>> >> wrote:
>>>> >> 
>>>> >> 
>>>> >> 
>>>> >>>> On Oct 20, 2019, at 10:10, JW Weatherman j...@mathbot.com wrote:
>>>> >>> I think the assumption is not that all miners are unprofitable, but 
>>>> >>> that a single miner could make an investment that becomes unprofitable 
>>>> >>> if the hash rate increases more than he expected.
>>>> >> 
>>>> >> This is a restatement of the assumption I questioned. Hash rate 
>>>> >> increase does not imply unprofitability. The new rig should be 
>>>> >> profitable.
>>>> >> 
>>>> >> What is being assumed is a hash rate increase without a proportional 
>>>> >> block reward value increase. In this case if the newest equipment is 
>>>> >> unprofitable, all miners are unprofitable.
>>>> >> 
>>>> >>> Depending on the cost of the offered insurance it would be prudent for 
>>>> >>> a miner to decrease his potential loss by buying insurance for this 
>>>> >>> possibility.
>>>> >>> And the existence of attractive insurance contracts would lower the 
>>>> >>> barrier to entry for new competitors in mining and this would increase 
>>>> >>> bitcoins security.
>>>> >>> -JW
>>>> >>> ‐‐‐ Original Message ‐‐‐
>>>> >>> 
>>>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev 
>>>> >>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>>>> >>>> Hi Lucas,
>>>> >>>> I would question the assumption inherent in the problem statement. 
>>>> >>>> Setting aside variance discount, proximity premium, and questions of 
>>>> >>>> relative efficiency, as these are presumably already considered by 
>>>> >>>> the miner upon the purchase of new equipment, it’s not clear why a 
>>>> >>>> loss is assumed in the case of subsequently increasing hash rate.
>>>> >>>> The assumption of increasing hash rate implies an expectation of 
>>>> >>>> increasing return on investment. There are certainly speculative 
>>>> >>>> errors, but a loss on new equipment implies all miners are operating 
>>>> >>>> at a loss, which is not a sustainable situation.
>>>> >>>> If any miner is profitable it is the miner with the new equipment, 
>>>> >>>> and if he is not, hash rate will drop until he is. This drop is most 
>>>> >>>> likely to be precipitated by older equipment going offline.
>>>> >>>> Best,
>>>> >>>> Eric
>>>> >>>> 
>>>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev 
>>>> >>>>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>>>> >>>>>> Hi,
>>>> >>>>>> This is my first post to this list -- even though I did some tiny 
>>>> >>>>>> contributions to bitcoin core I feel quite a beginner -- so if my 
>>>> >>>>>> idea is stupid, already known, or too off-topic, just let me know.
>>>> >>>>>> TL;DR: a trustless contract that guarantees minimum profitability 
>>>> >>>>>> of a mining operation -- in case Bitcoin/hash price goes too low. 
>>>> >>>>>> It can be trustless bc we can use the assumption that the price of 
>>>> >>>>>> hashing is low to unlock funds.
>&g

Re: [bitcoin-dev] Trustless hash-price insurance contracts

[Eric Voskuil via bitcoin-dev]

ld 
>> > still be worth it. And any potential new entrants on the edge of jumping 
>> > in would enter when they otherwise would not have because of the decreased 
>> > costs (decreased risk).
>> > 
>> > An analogy would be car insurance. If you are an excellent driver you 
>> > wouldn't be willing to spend a ton of money to protect your car in the 
>> > event of an accident, but if it is cheap enough you would. And there may 
>> > be people that are unwilling to take the risk of a damaged car that 
>> > refrain from becoming drivers until insurance allows them to lower the 
>> > worst case scenario of a damaged car.
>> > 
>> > -JW
>> > 
>> > 
>> > 
>> > 
>> > ‐‐‐ Original Message ‐‐‐
>> >> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil  
>> >> wrote:
>> >> 
>> >> 
>> >> 
>> >>>> On Oct 20, 2019, at 10:10, JW Weatherman j...@mathbot.com wrote:
>> >>> I think the assumption is not that all miners are unprofitable, but that 
>> >>> a single miner could make an investment that becomes unprofitable if the 
>> >>> hash rate increases more than he expected.
>> >> 
>> >> This is a restatement of the assumption I questioned. Hash rate increase 
>> >> does not imply unprofitability. The new rig should be profitable.
>> >> 
>> >> What is being assumed is a hash rate increase without a proportional 
>> >> block reward value increase. In this case if the newest equipment is 
>> >> unprofitable, all miners are unprofitable.
>> >> 
>> >>> Depending on the cost of the offered insurance it would be prudent for a 
>> >>> miner to decrease his potential loss by buying insurance for this 
>> >>> possibility.
>> >>> And the existence of attractive insurance contracts would lower the 
>> >>> barrier to entry for new competitors in mining and this would increase 
>> >>> bitcoins security.
>> >>> -JW
>> >>> ‐‐‐ Original Message ‐‐‐
>> >>> 
>> >>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev 
>> >>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>> >>>> Hi Lucas,
>> >>>> I would question the assumption inherent in the problem statement. 
>> >>>> Setting aside variance discount, proximity premium, and questions of 
>> >>>> relative efficiency, as these are presumably already considered by the 
>> >>>> miner upon the purchase of new equipment, it’s not clear why a loss is 
>> >>>> assumed in the case of subsequently increasing hash rate.
>> >>>> The assumption of increasing hash rate implies an expectation of 
>> >>>> increasing return on investment. There are certainly speculative 
>> >>>> errors, but a loss on new equipment implies all miners are operating at 
>> >>>> a loss, which is not a sustainable situation.
>> >>>> If any miner is profitable it is the miner with the new equipment, and 
>> >>>> if he is not, hash rate will drop until he is. This drop is most likely 
>> >>>> to be precipitated by older equipment going offline.
>> >>>> Best,
>> >>>> Eric
>> >>>> 
>> >>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev 
>> >>>>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>> >>>>>> Hi,
>> >>>>>> This is my first post to this list -- even though I did some tiny 
>> >>>>>> contributions to bitcoin core I feel quite a beginner -- so if my 
>> >>>>>> idea is stupid, already known, or too off-topic, just let me know.
>> >>>>>> TL;DR: a trustless contract that guarantees minimum profitability of 
>> >>>>>> a mining operation -- in case Bitcoin/hash price goes too low. It can 
>> >>>>>> be trustless bc we can use the assumption that the price of hashing 
>> >>>>>> is low to unlock funds.
>> >>>>>> The problem:
>> >>>>>> A miner invests in new mining equipment, but if the hash-rate goes up 
>> >>>>>> too much (the price he is paid for a hash goes down by too much) he 
>> >>>>>> will have a loss.
>> >>>>>> Soluti

Re: [bitcoin-dev] Trustless hash-price insurance contracts

[Eric Voskuil via bitcoin-dev]

So we are talking about a miner insuring against his own inefficiency.

Furthermore a disproportionate increase in hash rate is based on the 
expectation of higher future return (investment leads returns). So the 
insurance could end up paying out against realized profit.

Generally speaking, insuring investment is a zero sum game.

e

> On Oct 20, 2019, at 12:10, JW Weatherman  wrote:
> 
> Oh, I see your point.
> 
> However the insurance contract would protect the miner even in that case. A 
> miner with great confidence that he is running optimal hardware and has 
> optimal electricity and labor costs probably wouldn't be interested in 
> purchasing insurance for a high price, but if it was cheap enough it would 
> still be worth it. And any potential new entrants on the edge of jumping in 
> would enter when they otherwise would not have because of the decreased costs 
> (decreased risk).
> 
> An analogy would be car insurance. If you are an excellent driver you 
> wouldn't be willing to spend a ton of money to protect your car in the event 
> of an accident, but if it is cheap enough you would. And there may be people 
> that are unwilling to take the risk of a damaged car that refrain from 
> becoming drivers until insurance allows them to lower the worst case scenario 
> of a damaged car.
> 
> -JW
> 
> 
> 
> 
> ‐‐‐ Original Message ‐‐‐
>> On Sunday, October 20, 2019 10:57 AM, Eric Voskuil  wrote:
>> 
>> 
>> 
>>>> On Oct 20, 2019, at 10:10, JW Weatherman j...@mathbot.com wrote:
>>> I think the assumption is not that all miners are unprofitable, but that a 
>>> single miner could make an investment that becomes unprofitable if the hash 
>>> rate increases more than he expected.
>> 
>> This is a restatement of the assumption I questioned. Hash rate increase 
>> does not imply unprofitability. The new rig should be profitable.
>> 
>> What is being assumed is a hash rate increase without a proportional block 
>> reward value increase. In this case if the newest equipment is unprofitable, 
>> all miners are unprofitable.
>> 
>>> Depending on the cost of the offered insurance it would be prudent for a 
>>> miner to decrease his potential loss by buying insurance for this 
>>> possibility.
>>> And the existence of attractive insurance contracts would lower the barrier 
>>> to entry for new competitors in mining and this would increase bitcoins 
>>> security.
>>> -JW
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev 
>>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>>>> Hi Lucas,
>>>> I would question the assumption inherent in the problem statement. Setting 
>>>> aside variance discount, proximity premium, and questions of relative 
>>>> efficiency, as these are presumably already considered by the miner upon 
>>>> the purchase of new equipment, it’s not clear why a loss is assumed in the 
>>>> case of subsequently increasing hash rate.
>>>> The assumption of increasing hash rate implies an expectation of 
>>>> increasing return on investment. There are certainly speculative errors, 
>>>> but a loss on new equipment implies all miners are operating at a loss, 
>>>> which is not a sustainable situation.
>>>> If any miner is profitable it is the miner with the new equipment, and if 
>>>> he is not, hash rate will drop until he is. This drop is most likely to be 
>>>> precipitated by older equipment going offline.
>>>> Best,
>>>> Eric
>>>> 
>>>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev 
>>>>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>>>>>> Hi,
>>>>>> This is my first post to this list -- even though I did some tiny 
>>>>>> contributions to bitcoin core I feel quite a beginner -- so if my idea 
>>>>>> is stupid, already known, or too off-topic, just let me know.
>>>>>> TL;DR: a trustless contract that guarantees minimum profitability of a 
>>>>>> mining operation -- in case Bitcoin/hash price goes too low. It can be 
>>>>>> trustless bc we can use the assumption that the price of hashing is low 
>>>>>> to unlock funds.
>>>>>> The problem:
>>>>>> A miner invests in new mining equipment, but if the hash-rate goes up 
>>>>>> too much (the price he is paid for a hash goes down by too much) he will 
>>>&

Re: [bitcoin-dev] Trustless hash-price insurance contracts

[Eric Voskuil via bitcoin-dev]

> On Oct 20, 2019, at 10:10, JW Weatherman  wrote:
> 
> I think the assumption is not that all miners are unprofitable, but that a 
> single miner could make an investment that becomes unprofitable if the hash 
> rate increases more than he expected.

This is a restatement of the assumption I questioned. Hash rate increase does 
not imply unprofitability. The new rig should be profitable.

What is being assumed is a hash rate increase *without* a proportional block 
reward value increase. In this case if the newest equipment is unprofitable, 
all miners are unprofitable.

> Depending on the cost of the offered insurance it would be prudent for a 
> miner to decrease his potential loss by buying insurance for this possibility.
> 
> And the existence of attractive insurance contracts would lower the barrier 
> to entry for new competitors in mining and this would increase bitcoins 
> security.
> 
> -JW
> 
> 
> 
> 
> ‐‐‐ Original Message ‐‐‐
>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev 
>>  wrote:
>> 
>> Hi Lucas,
>> 
>> I would question the assumption inherent in the problem statement. Setting 
>> aside variance discount, proximity premium, and questions of relative 
>> efficiency, as these are presumably already considered by the miner upon the 
>> purchase of new equipment, it’s not clear why a loss is assumed in the case 
>> of subsequently increasing hash rate.
>> 
>> The assumption of increasing hash rate implies an expectation of increasing 
>> return on investment. There are certainly speculative errors, but a loss on 
>> new equipment implies all miners are operating at a loss, which is not a 
>> sustainable situation.
>> 
>> If any miner is profitable it is the miner with the new equipment, and if he 
>> is not, hash rate will drop until he is. This drop is most likely to be 
>> precipitated by older equipment going offline.
>> 
>> Best,
>> Eric
>> 
>>>> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev 
>>>> bitcoin-dev@lists.linuxfoundation.org wrote:
>>> Hi,
>>> This is my first post to this list -- even though I did some tiny 
>>> contributions to bitcoin core I feel quite a beginner -- so if my idea is 
>>> stupid, already known, or too off-topic, just let me know.
>>> TL;DR: a trustless contract that guarantees minimum profitability of a 
>>> mining operation -- in case Bitcoin/hash price goes too low. It can be 
>>> trustless bc we can use the assumption that the price of hashing is low to 
>>> unlock funds.
>>> The problem:
>>> A miner invests in new mining equipment, but if the hash-rate goes up too 
>>> much (the price he is paid for a hash goes down by too much) he will have a 
>>> loss.
>>> Solution: trustless hash-price insurance contract (or can we call it an 
>>> option to sell hashes at a given price?)
>>> An insurer who believes that it's unlikely the price of a hash will go down 
>>> a lot negotiates a contract with the miner implemented as a Bitcoin 
>>> transaction:
>>> Inputs: a deposit from the insurer and a premium payment by the miner
>>> Output1: simply the premium payment to the insurer
>>> Output2 -- that's the actual insurance
>>> There are three OR'ed conditions for paying it:
>>> A. After expiry date (in blocks) insurer can spend
>>> B. Both miner and insurer can spend at any time by mutual agreement
>>> C. Before expiry, miner can spend by providing a pre-image that produces a 
>>> hash within certain difficulty constraints
>>> The thing that makes it a hash-price insurance (or option, pardon my lack 
>>> of precise financial jargon), is that if hashing becomes cheap enough, it 
>>> becomes profitable to spend resources finding a suitable pre-image, rather 
>>> than mining Bitcoin.
>>> Of course, both parties can reach an agreement that doesn't require 
>>> actually spending these resources -- so the miner can still mine Bitcoin 
>>> and compensate for the lower-than-expected reward with part of the 
>>> insurance deposit.
>>> If the price doesn't go down enough, the miner just mines Bitcoin and the 
>>> insurer gets his deposit back.
>>> It's basically an instrument for guaranteeing a minimum profitability of 
>>> the mining operation.
>>> Implementation issues: unfortunately we can't do arithmetic comparison with 
>>> long integers >32bit in the script, so implementation of the difficulty 
>>> requirement needs to be hacky. I t

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

[Eric Voskuil via bitcoin-dev]

I agree, thanks.

FWIW I’ve never been a fan of the ‘reject’ message, or its implementation.

https://github.com/bitcoin/bips/wiki/Comments:BIP-0061

e

> On Oct 18, 2019, at 18:46, David A. Harding  wrote:
> 
> On Thu, Oct 17, 2019 at 01:16:47PM -0700, Eric Voskuil via bitcoin-dev wrote:
>> As this is a P2P protocol change it should be exposed as a version
>> increment (and a BIP) [...]
>> 
>> BIP61 is explicit:
>> 
>> “All implementations of the P2P protocol version 70,002 and later
>> should support the reject message.“
> 
> I don't think a new BIP or a version number increment is necessary.
> 
> 1. "Should support" isn't the same as "must support".  See
>   https://tools.ietf.org/html/rfc2119 ; by that reading,
>   implementations with protocol versions above 70,002 are not required
>   to support the reject message.
> 
> 2. If you don't implement a BIP, as Bitcoin Core explicitly doesn't any
>   more for BIP61[1], you're not bound by its conditions.
> 
> -Dave
> 
> [1] https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md  "BIP61
> [...] Support was removed in v0.20.0"
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trustless hash-price insurance contracts

[Eric Voskuil via bitcoin-dev]

Hi Lucas,

I would question the assumption inherent in the problem statement. Setting 
aside variance discount, proximity premium, and questions of relative 
efficiency, as these are presumably already considered by the miner upon the 
purchase of new equipment, it’s not clear why a loss is assumed in the case of 
subsequently increasing hash rate. 

The assumption of increasing hash rate implies an expectation of increasing 
return on investment.  There are certainly speculative errors, but a loss on 
new equipment implies *all miners* are operating at a loss, which is not a 
sustainable situation.

If any miner is profitable it is the miner with the new equipment, and if he is 
not, hash rate will drop until he is. This drop is most likely to be 
precipitated by older equipment going offline.

Best,
Eric

> On Oct 20, 2019, at 00:31, Lucas H via bitcoin-dev 
>  wrote:
> 
> 
> Hi,
> 
> This is my first post to this list -- even though I did some tiny 
> contributions to bitcoin core I feel quite a beginner -- so if my idea is 
> stupid, already known, or too off-topic, just let me know.
> 
> TL;DR: a trustless contract that guarantees minimum profitability of a mining 
> operation -- in case Bitcoin/hash price goes too low. It can be trustless bc 
> we can use the assumption that the price of hashing is low to unlock funds.
> 
> The problem:
> 
> A miner invests in new mining equipment, but if the hash-rate goes up too 
> much (the price he is paid for a hash goes down by too much) he will have a 
> loss.
> 
> Solution: trustless hash-price insurance contract (or can we call it an 
> option to sell hashes at a given price?)
> 
> An insurer who believes that it's unlikely the price of a hash will go down a 
> lot negotiates a contract with the miner implemented as a Bitcoin transaction:
> 
> Inputs: a deposit from the insurer and a premium payment by the miner
> Output1: simply the premium payment to the insurer
> Output2 -- that's the actual insurance
>   There are three OR'ed conditions for paying it:
>   A. After expiry date (in blocks) insurer can spend
>   B. Both miner and insurer can spend at any time by mutual agreement
>   C. Before expiry, miner can spend by providing **a pre-image that produces 
> a hash within certain difficulty constraints**
> 
> The thing that makes it a hash-price insurance (or option, pardon my lack of 
> precise financial jargon), is that if hashing becomes cheap enough, it 
> becomes profitable to spend resources finding a suitable pre-image, rather 
> than mining Bitcoin.
> Of course, both parties can reach an agreement that doesn't require actually 
> spending these resources -- so the miner can still mine Bitcoin and 
> compensate for the lower-than-expected reward with part of the insurance 
> deposit.
> If the price doesn't go down enough, the miner just mines Bitcoin and the 
> insurer gets his deposit back.
> It's basically an instrument for guaranteeing a minimum profitability of the 
> mining operation.
> 
> Implementation issues: unfortunately we can't do arithmetic comparison with 
> long integers >32bit in the script, so implementation of the difficulty 
> requirement needs to be hacky. I think we can use the hashes of one or more 
> pre-images with a given short length, and the miner has to provide the exact 
> pre-images. The pre-images are chosen by the insurer, and we would need a 
> "honesty" deposit or other mechanism to punish the insurer if he chooses a 
> hash that doesn't correspond to any short-length pre-image. I'm not sure 
> about this implementation though, maybe we actually need new opcodes.
> 
> What do you guys think?
> Thanks for reading it all! Hope it was worth your time!
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

[Eric Voskuil via bitcoin-dev]

As this is a P2P protocol change it should be exposed as a version increment 
(and a BIP), not just as a conditional service. If the intent is to retain this 
protocol indefinitely, exposing it conditionally, then a service bit would make 
sense, but it remains a protocol change.

BIP61 is explicit:

“All implementations of the P2P protocol version 70,002 and later should 
support the reject message.“

e

> On Oct 17, 2019, at 12:54, Andreas Schildbach via bitcoin-dev 
>  wrote:
> 
> On 16/10/2019 18.43, John Newbery via bitcoin-dev wrote:
> 
>> Following discussion on this mailing list, support for BIP 61 REJECT
>> messages was not removed from Bitcoin Core in V0.19. The behaviour in
>> that upcoming release is that REJECT messages are disabled by default
>> and can be enabled using the `-enablebip61` command line option.
> 
> Is there a NODE_* bit we can use to pick peers that support this
> (useful!) feature?
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev