Date: Tue, 26 Oct 2021 08:56:10 +0000
To: "eric@voskuil.org" <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <a33WOOHRYsOk5DCaJQAQUh-fwyudYXQYggn54KmIKx_CVA4qCnjaAxG3-Drl639NTGC8smZUNeIulUcAxoOp44kRZhf8BQS0JqqW1BkJpCU=@protonmail.com>
In-Reply-To: <009901d7ca43$d9dd2f50$8d978df0$@voskuil.org>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
 <wIXL_bs_B1FfWrIOMjdog--VwQWD_okme8nPjerWyszHuKhFcPTi3yetwPKYYYR79PEeQcbA3lqZTL107k_KED8-RMs4HPyvhLh5b1miSr4=@protonmail.com>
 <009901d7ca43$d9dd2f50$8d978df0$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

Good morning e, and lisa,

> Agree ZmnSCPxj
>
> Hi lisa,
>
> I'm all for removing it from memory. :) Did that a while ago. We just cal=
l 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 distributi=
on (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 fe=
es. Anyone can get paid to mine, just need the txs.
>
> Mining may be semi-restricted set is today, it may not be tomorrow. Imagi=
ne 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 c=
onnected transactions. Block headers come along occasionally, and impose or=
der 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 endpo=
ints 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 st=
ake 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-contr=
act 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 endp=
oint (in much the same way published Lightning channels are attested by the=
ir funding tx outpoints), and has no effect on block validity, only on goss=
iping 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 cha=
nging of staked identity is more expensive than having a persistent identit=
y.
WE should really design systems where anonymity-preservation should be as c=
heap 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 ac=
ceptable feerates at the time, which both makes transaction confirmation ti=
melines 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 no=
t 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 po=
ssible that this mechanism *increases* variability rather than decreases it=
.

Regards,
ZmnSCPxj