From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "eric@voskuil•org" <eric@voskuil•org>
Cc: 'Bitcoin Protocol Discussion'
<bitcoin-dev@lists•linuxfoundation.org>,
'lisa neigut' <niftynei@gmail•com>
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Date: Tue, 26 Oct 2021 08:56:10 +0000 [thread overview]
Message-ID: <a33WOOHRYsOk5DCaJQAQUh-fwyudYXQYggn54KmIKx_CVA4qCnjaAxG3-Drl639NTGC8smZUNeIulUcAxoOp44kRZhf8BQS0JqqW1BkJpCU=@protonmail.com> (raw)
In-Reply-To: <009901d7ca43$d9dd2f50$8d978df0$@voskuil.org>
Good morning e, and lisa,
> 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.
On the subject of thinking backwards....
The current design gossips txes.
I believe much of what lisa wants would be doable by gossiping mining endpoints instead of txes.
Then transactors can connect to mining endpoints.
Tx gossip is limited by fees (which is why the RBF rules even exist in the first place).
Thus, mining endpoint gossip must be limited by something as well, such as by requiring some trivial stake of BTC.
(BTC exchanges are commonplace enough, I believe, that requiring completely new miners (i.e. those who currently own 0 BTC) to acquire some trivial stake of BTC would be feasible; for most people it would be easier to buy BTC than to acquire a mining rig and the supporting infrastructure needed for a mine.)
We could have the endpoint encoded in some sign-to-contract or pay-to-contract construction.
Miners can change their identity by spending their stake (which makes nodes drop their endpoint record).
Then, they can use now-common anonymity techniques --- mostly CoinJoin, but also the upcoming CoinSwap implementation --- to acquire a new stake whose identity is not easily traceable to the previous stake.
(This is not proof-of-stake, BTW --- the stake only attests the mining endpoint (in much the same way published Lightning channels are attested by their funding tx outpoints), and has no effect on block validity, only on gossiping of mining endpoints.)
The advantage here is that we expect the set of miner identities to change less often than the set of txes, thus reducing global bandwidth usage,
Against the above, we must notice that the anonymity-preserving regular changing of staked identity is more expensive than having a persistent identity.
WE should really design systems where anonymity-preservation should be as cheap as possible, but onchain activity is no longer cheap at all, given the growing importance of Bitcoin.
--
Also:
> A direct communication channel between block template construction venues and transaction proposers also provides a venue for direct feedback wrt acceptable feerates at the time, which both makes transaction confirmation timelines less variable
Unless you contact ***all*** miners globally, there is always some non-zero probability that one of the miners you did *not* contact (and thus does not have your tx, and thus will not be able to confirm your tx) gets the next block.
Since miners can enter and leave the network at any time, it is entirely possible that this mechanism *increases* variability rather than decreases it.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-10-26 8:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 2:56 lisa neigut
2021-10-26 8:02 ` ZmnSCPxj
2021-10-26 8:31 ` eric
2021-10-26 8:56 ` ZmnSCPxj [this message]
2021-10-26 14:09 ` darosior
2021-10-26 16:38 ` ZmnSCPxj
2021-10-26 16:26 ` Pieter Wuille
2021-10-26 18:16 ` Gloria Zhao
2021-10-28 1:04 ` ZmnSCPxj
2021-11-03 10:12 ` ZmnSCPxj
2021-10-26 23:44 ` Antoine Riard
2021-10-27 20:01 ` Peter Todd
2021-10-27 8:44 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-27 23:05 ` yanmaani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='a33WOOHRYsOk5DCaJQAQUh-fwyudYXQYggn54KmIKx_CVA4qCnjaAxG3-Drl639NTGC8smZUNeIulUcAxoOp44kRZhf8BQS0JqqW1BkJpCU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
--cc=niftynei@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox