Bitcoin.com Mining Team - What can miners do to improve instant transactions?
Watch on YouTubeVideo summary
The primary subject of this discussion revolves around the limitations current mining infrastructure faces in facilitating instant transactions, specifically focusing on how miners and pools handle transaction selection. A key argument presented is that most mining pools do not prioritize instant settlement because their default operation relies on a "first seen first safe" rule found in unmodified Bitcoin Core clients. Under this standard protocol, nodes simply accept the earliest valid block header they receive without actively synchronizing mempools across different global servers. Consequently, if a transaction is accepted by a node in one region, such as California, it can potentially be double-spent before that information propagates to another server located elsewhere, like China, leading to orphaned blocks and failed transactions for merchants relying on immediate confirmation.
To address these issues, the transcript highlights several misconceptions about mining pools, clarifying that they are not monolithic systems but rather consist of dozens or even hundreds of distributed nodes operating with little internal synchronization unless specifically configured otherwise. While some miners have modified their clients to implement features like Replace-by-Fee (RBF) manually, this is rare due to the extra maintenance work and risks involved in recompiling code against frequent network upgrades. The consensus among most pools remains adherence to default settings for predictability; an "honest miner" is defined here as one that follows standard rules without arbitrary modifications, ensuring other nodes can reliably anticipate their behavior. This lack of internal coordination means that even within a single pool's infrastructure, different servers might compete against each other or orphan blocks if they cannot agree on which conflicting transaction to prioritize before submitting the block header to the network.
The video proposes several technical solutions and best practices for merchants seeking higher confidence in instant transactions without waiting for full Bitcoin Core upgrades. One recommended approach is "transaction confidence," where a merchant sets up their own distributed nodes across various global locations, including major mining hubs like North America, Europe, China, and Iceland. By querying these diverse nodes simultaneously to check block templates, a user can achieve approximately 99.99% certainty that a transaction will be included in the next block before actually sending it. Additionally, the discussion suggests implementing internal mechanisms similar to BGP peering or utilizing weak blocks with compacted headers to help pools internally decide on conflicting transactions faster than relying solely on the slow Bitcoin peer-to-peer network layer.
Finally, the conversation concludes with recommendations for developers aiming to improve mining software and overall network efficiency. The most significant pain point identified is the slowness of the current TCP-based Bitcoin P2P network, which has historically been capped at one megabyte per second without strong incentives for improvement. Experts suggest exploring faster communication protocols like UDP combined with Protocol Buffers to speed up block header propagation between nodes and pools globally. While features such as `preciousblock` exist in core code to help resolve race conditions by declaring a specific block superior, they are not yet widely adopted across all pool software. Ultimately, the path forward involves either enhancing internal synchronization within large pools or encouraging broader adoption of faster networking standards that allow merchants to verify transaction inclusion with greater speed and reliability before broadcasting them on-chain.
Read the full video transcript
[Music]
so one thing that is that we can point
out is that mining pools or most other
mining pools probably don't really care
that much about instant transactions the
mining pools job is to put transactions
in blocks and instant transactions
happen outside that process so they it's
not really their priority to to think
about these kind of things as especially
if they're only a mining pool
so what let's go from let's go through
some through some of the things so
miners do honor first seen first safe
room by default if they are running an
unmodified client most miners do run
unmodified unmodified clients but as
Peter showed here on Tuesday there are
some miners that seems to have modified
their clients to actually do RBF even
though that's not activated by default
in in any of the the currents become
cash clients which is quite what's quite
a quite interesting find and there's
little incentive actually modify your
client especially since we're doing
Network wide upgrades every six months
it just leaves a lot of extra work for
the miner and most miners don't want
that extra work so a double spend
succeeds when a mining node sees a
double spending transaction before the
merchant node because the Koston miners
do honor first seen first safe that's
actually what we saw in Peters
presentation on Tuesday is that if you
if you just send the the double spend
transaction if you sent it almost at
exact time or even at the exact time you
don't really know which one has got to
get mine
because they honored first scene for a
safe and - prioritize sinking block
headers and blocks and sinking their
mempool ziz not drill a priority and
since it's not being done by default in
any of the current of the clients right
now it's not really it's not really
happening so so yeah let's go through
some mining pool trivia so one
misconception about mining pools is that
it's just one big system and it's very
smart at selecting transactions mining
pools are not yes one server and they're
not very smart and so like a big mining
the mining pool one a place we want to
place our mining pool service as close
to the hash rate as possible which means
that most mining pools they I have a lot
of sites in North America in Europe and
in China and they they don't really have
anything in like continents where no one
is mining like in Australia so a big
mining pool may consist of twenty to
forty different mining nodes across the
world and one thing that is that people
keep for like some people keep
forgetting is that the like if you if
one pool has forty servers spread across
the world technically these are forty
different mining pools there you have
tagged the blocks the same and they have
to collect the data in like in the same
central server but from a mining
perspective these are separate pools
that can orphan each other and which is
which is something that we see quite
often of mining pools can orphan
themselves and by default there's no way
to actually synchronize the men pools
between the different mining nodes
unless Bitcoin D has a feature for it
because that would required a mining
pool to make the mining pool software do
it
and there's currently not a very strong
incentive to do so
since the mining pool mostly us focus on
pushing out the block as soon as
possible as soon as is found so a
transaction that was accepted by
varieties in California can be double
spent by the same mining pool in China
if the transaction was not propagated
fast enough and like another thing that
about my nipples tell most of them are
hosted in the same cloud providers in
China all of them are at Alabama
I like BTC calm and and pool and by b2c
and lay there all hosted on the same
cloud infrastructure so if you want to
be as close to the mining pools as
possible you should just set up servers
these cloud providers I think here all
of you here have noted basic so if they
mining pool but since this will be in
YouTube later and now I guess we've run
through the basics so one misconception
we saw it in the previous budget
presentation is that ant miners don't
build blocks
it's the mining pool software that
builds the blocks the ant miners they
all do the hashing so the pool soft were
asked for a block template from Bitcoin
D the RPC and then the pool software
converts it into the stratum job the
stratum job is sent to the ant miner the
hasher the a minor set finds a valid
block sends it back and sends back a few
variables to the pool and then the pool
construct a complete block and then
submits it a Bitcoin D so if you really
want to like visualize how mining works
it's actually the mining pool software
where the magic happens the the Hatcher
itself is a very very dumb unit that
makes a lot of silly mistakes and
incorrect shares
so I like the setup pretty looks like
this you have the Bitcoin these are
connected to each other but the mining
pool software most of them are not like
we started a few mining different mining
pool software when we built our our own
mining pool and the norm is that there's
very little synchronization between the
pool software itself at least when it
comes to transactions and Men pools most
of the inter pool communication actually
happens on the Bitcoin on the Bitcoin
network itself between the Bitcoin DS so
in this example I made the the pulsar
for different colors they could be three
different pools or they can be the same
pool but the fact is that these three
pools will compete with each other and
will offer an each other even though if
they are the same pool or not they don't
really care and they're pretty pretty
dumb because the like they just work on
a block template it comes from Bitcoin D
so everything is dependent on the
information that comes from the Satoshi
client so if I improve mental
synchronization all of that has to be
done in Bitcoin D by the the client
developers I observed a few question for
the past few a few questions for the
past few days why would the miners honor
the first seen first safe rule and the
question is pretty simple miners are
lazy they just wanted one to default
clients modifying the the Satoshi client
means that you have to actually get into
the code and do your own modification
need to recompile everything and that
could lead to risk
so most mining pools don't really want
to take that risks we did see some
evidence that it seems to be some miners
that actually have taken that risk and
implement
RBF on their own on the network but most
of them they do honor the the first
thing first days for a safe robe simply
because that's the default setting which
is why RBF is the thing on core because
like the court Peter taught tried to
make the the miners run it without the
patch being in core but they didn't
really care until us became default in
core and the miners didn't really bother
removing it so the most of the norm is
just run the default default settings
and also what is an honest miner it
seems that that that's not really clear
and my definition I would say an honest
miner is someone that runs the default
settings without much modification
because you have so you have the default
setting and then you have what's allowed
in consensus so you can operate within
consensus but outside the default
settings that's where you find our
behalf for example as you were not the
orphaned because you do RBF but it's
still like is it honest and I would say
an honour hard say but like probably the
best definition is like an honest miner
is a predictable miner it means that
other minor that you have predictability
and how they're going to act because you
know exactly what kind of rules they
follow I think Josh you asked why the
pools don't publish nerman polls it's
because we have too many servers so
there's not one man pool they're like 30
of them spread across the world and
they're not very well synchronized so we
can't really publish the nipples is
there a way that you know I know there's
multiple servers but they could have you
know nodes that are not the node that's
doing get blocked template but connected
one hop away and then expose those nodes
mempool so and then it would be up to
the people checking to check cross
multiple pool servers because really
you're just looking for anything
distances right you're looking for
double spends so it doesn't have to be a
singular location it could definitely be
multiple locations yeah well personally
like I don't really I don't really think
that it will be a like any problem
publish them and pool but I would like
to synchronize it internally first and
we're gonna get there I think it will be
more healthy and as the transaction
count goes up on a network mining pools
will find that they will need to sink
their men pools better because I mean
block block propagation also gets better
so how can we sink the the mentals
better the easiest least the solution is
probably weak blocks where utilized
compact expand or graphene graphene
being the the better solution here for
weak blocks to indicate which block is
being worked on and the first step is to
do this internally the problem is a weak
block don't really help decide the
victor in a case of conflict which leads
us into pre consensus territory because
like you can do this internally inside a
pool pretty easily because you trust
your own notes so if you have a so if
you have a node that so if you have a
big mining pool you have service in
China in the US and you observe a double
spend and then you you can easily make
your nodes agree on which transaction to
go for simply by sharing the timestamp
and you can trust the timestamp because
it's your own pool and it's your own
servers it gets a little more tricky
when it's with an external pool that you
have to trust because you don't
necessarily know if they're gonna be
honest or not if they can if they're
gonna modify their time stamps but at
least you would be aware of that
something fishy is going on which
probably is good enough for for
merchants so I would say like my ideal
solution was be some kind of
mimic some kind of internal BGP
functionality to decide like which
conflicting transaction to go for and if
you can old but you can also do some
sort of bgp peering between pools so
basically like you have a list of week
blocks that you receive and you see like
which pools like how many transaction
they have in their blocks and what's the
difference and you can request
retransmission of certain transaction
and once in a while also observe
conflict and how to how to resolve this
conflict I think that's that will be a
long discussion because like the the
avalanche protocol that we just heard
about like speaking as a mining pool a
mining pool would be pretty upset if if
we can get our blocks orphaned by
mistake or if there's some kind of
arbitrary rules that we cannot predict
so the thing is since we are honoring
first scene for safe so it's all one is
if someone is broadcasting a transaction
at the exact same time in China in the
US they have the exact same timestamp
almost and we try to honor a first scene
because the Chinese pool saw it first
and the US pool saw the air there one
first like how are we actually going to
decide which one to go for and if the
pool feel that there was no way to
actually predict this properly and they
got the work they could have the block
orphan just because of that the the
miners will not accept this protocol
they - want predictability they need to
be able to know exactly what's going to
happen if they get block gets accept
you're not so how do we know a which
transaction that will be mined well the
easiest way is to simulate what might
impose does
so any merchants that want to know like
you can never know of course it's
impossible to know for sure 100% that if
recession will be mind but ask the
merchants you can actually simulate your
own mining pool by setting up service
across the world so in this case you
just set up full notes that are spread
across the world on different ISPs
different providers with bu and ABC and
XT and what to do is that you query each
node at exactly the same time and you
ask them to do a get block templates and
check the transaction you're looking for
if the transaction is that everyone's
block templates all across the world
even though they're spread out and using
different clients then it can be pretty
sure that it will be mined in the next
block as a merchant you can feel not 100
percent safe it gives you best in every
case but you can feel 99.99% safe that
this will actually be mined in the next
block I say this is we call it like
transaction confidence the yes query
different nodes across the world and if
they all agree that they will mine your
construction in the next block then you
can predict that yeah this is probably
not gonna be a double spent and for a
merchant that should be enough because
that's how the mining pools work
basically like this Rock template to
solve it and they they they push it out
so I would recommend the merchants that
want to want to be more safe about
instant transactions and see if will be
included in next block just simulate
your mining pool set up a few notes and
distribute them equally across the world
especially where the mining where the
mining pools are hosted which is male
versus North America
our Virginia Oregon California some
parts of Canada China of course and you
yeah Europe eastern and northern Europe
and Iceland any questions um yeah I have
a question I think I've gathered that
from your talk but maybe as a
confirmation do you mean that the
different pools basically within your
pool also use defaults Bitcoin the block
synchronization messages currently
methods the current methods for for
their block synchronization or is there
anything to make that faster or more
efficient for these by D yeah they use
the defaults of course but most mining
pools including ours we have special
techniques for pushing out the block
headers faster than normal would be on
the on the block we're using the the
Bitcoin network because it's not really
it's not that fast and it's faster to do
it with custom software but what we're
only like pushing out things when we
mined a block when actually already
found it yeah but is it like when you
you mean specialized software that just
change the network layer or is there
really a different network for that to
pass them these these headers so our
mining pool and I know that seek a pool
and vibey to see or have like customized
software to us to replicate or broadcast
a block across the world as fast as
possible that but they also use the the
the Bitcoin layer because you do submit
block to Bitcoin D and when that happens
you will send a compact block or an
extent all the knows you're connected to
so it's basically it's like firing a
shotgun it's like you just try to fire
as many bullets and as many darkness as
possible okay thank you
um so you said that there is there is
nothing much in place to reconcile the
members of across your different notes
around the world and sometimes one note
can actually orphan the other
I was just wondering like you still have
to reconcile the state of the shares
from your from your underlying minors
right so you said infrastructure like
not reusable it has a different
characteristic um that that's not usable
at all because I sherry just indicated
that a minor actually solved a small
block or basically a share means that a
my the hasher solve a weak lock and then
that just recorded somewhere but for for
block propagation and synchronize and
making sure that like the mem poles are
synchronized and like deciding on which
double spend to to go for that's not
really relevant it says the difference
separate issue could you comment as a as
a mining pool on topology how many nodes
the mining pool connects to are is each
section connecting to the network on
their own is there any sort of
information so most mining pools I guess
they they have like a list of nodes to
connect to so like actually like a lot
of their mining pools can appeal with
each other and mining pools are probably
the the mining nodes are actually the
most the best connected nodes on the
network
it's hundreds and they focus on like
connecting to the other mining pools of
course another thing that I wanted that
I wanted to point out that I forgot is
that technically the term mining node is
not really something that exists because
Bitcoin D doesn't mind anymore it used
to do that in the CPU mining days but
now it's actually like it's a Bitcoin D
node with mining pool software installed
on the same server they can do it
probably you're probably not gonna find
a block yeah hi so uh thanks for the
great talk and I actually have a
question you said that internal you can
often yourself and then you know a view
that you have to fast blockhead I
realize so did you think about like
basically making like a trusted internal
way to say okay there's this blockhead
I'm going to do SP baby mine on top or
do you not want to go there because of
like risk of attacks somewhere um most
so somewhere I do know that some mining
pools are better at orphanage itself
than others so that for example like I
don't think that gonna calm has ever
orphaned is itself say really you know
if we have I don't think we have because
like we make sure to to do everything to
prevent that and I do know that my B to
C does the same I think and pool is
pretty good at orphan in itself and
slush pool
oh yeah yes thanks for the great talk
Emily I actually learned learned a lot
about mining that I didn't didn't know I
didn't know what that poles
morphing themselves I always thought
there was just one main pool server
so my question I am a proponent of wheat
blocks as a lot of people know and one
of my concerns with rolling out week
blocks was I thought in order to get an
adopted you know you'd have to have
buy-in from a lot of miners because I
thought it only really be useful if the
most network was using it but based on
your talk it sounds like even if B you
were to implement a production version
of wheat blocks it would be useful for
Bitcoin comm just to synchronize the
metals of your own eternal service yeah
yeah so even if we just one mining pool
uses it is still very useful and it
might even be the case that you that the
weak flux will only be used internally
and they don't really because they would
use they would need to set up peers with
other mining pools and which they might
not want to do but it would definitely
be very useful internally and like I'm
from a nice P background so like I've
been working a lot with PGP so like I
would definitely like I see it as sort
of like when you run like show IP bgp
peer native neighbors on a router you'll
see a list of like your neighbors which
would mean which would be the other
mining pools and what kind of block
they're currently working on that would
be very useful as a mining pool thank
you
so there was an RPC code that was added
in Bitcoin D a wall by call Prius block
and it's so the way it works is that in
case there is a race between two blocks
the node software is gonna choose the
Prius block if you ask it to yeah and I
was I was curious to know if that's used
by miner a lot or not right because the
goal would be the different between deed
that are run by a miner when one of them
find a block it can call precious block
and the others and and make sure that
you don't often yourself
from the my it from the other money I am
from the other my new pool software that
I have studied I haven't really seen
that in other mining pool softwares yeah
no okay yeah so this is a little bit
different than the presentation that you
had but my curiosity is if there was
improvements to mining pool software and
the way mining is done today what
recommendations do you have for
developers that want to assist mining
pools and miners to develop better
software and what pain points do you see
today that could be improved
one of the biggest pain point pain
points right now it's the peer-to-peer
network between the the Bitcoin notes
it's it's dreadful it's pretty slow and
we should definitely explore using like
UDP for example you can use protocol
buffers to communicate between the
Bitcoin nodes and I that will be s be an
improvement in general for the whole
Bitcoin network like the natural layer
is pretty slow and of course it is slow
because for years it was stuck at one
megabyte so no one really had an
incentive to actually improve it thank
you okay thank you very much
[Music]