Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

[yancy via bitcoin-dev]

On 2023-11-07 17:12, Andrew Chow via bitcoin-dev wrote:


I would prefer that we continue to have a mailing list where email is a
functional and first class user interface. So that would be to migrate
to groups.io or Google Groups. I think Google Groups is probably the
better choice of the two.


+1 to migrating to a different email service.  That seems like the most 
straightforward solution.


On 2023-11-08 04:56, Anthony Towns via bitcoin-dev wrote:


delvingbitcoin.org is something I setup


Cool, thanks!  It's great to have more channels of discussion.  Same 
with IRC etc.


Cheers,
-Yancy


Andrew Chow

On 11/07/2023 10:37 AM, Bryan Bishop via bitcoin-dev wrote:


Hello,

We would like to request community feedback and proposals on the 
future

of the mailing list.

Our current mailing list host, Linux Foundation, has indicated for 
years

that they have wanted to stop hosting mailing lists, which would mean
the bitcoin-dev mailing list would need to move somewhere else. We
temporarily avoided that, but recently LF has informed a moderator 
that

they will cease hosting any mailing lists later this year.

In this email, we will go over some of the history, options, and 
invite

discussion ahead of the cutoff. We have some ideas but want to solicit
feedback and proposals.

Background
==

The bitcoin-dev mailing list was originally hosted on Sourceforge.net.
The bitcoin development mailing list has been a source of proposals,
analysis, and developer discussion for many years in the bitcoin
community, with many thousands of participants. Later, the mailing 
list
was migrated to the Linux Foundation, and after that OSUOSL began to 
help.


Linux Foundation first asked us to move the mailing list in 2017. They
internally attempted to migrate all LF mailing lists from mailman2 to
mailman3, but ultimately gave up. There were reports of scalability
issues with mailman3 for large email communities. Ours definitely
qualifies as.. large.

2019 migration plan: LF was to turn off mailman and all lists would
migrate to the paid service provider groups.io . 
Back

then we were given accounts to try the groups.io 
interface and administration features. Apparently we were not the only
dev community who resisted change. To our surprise LF gave us several
years of reprieve by instead handing the subdomain and server-side 
data
to the non-profit OSUOSL lab who instead operated mailman2 for the 
past

~4 years.

OSUOSL has for decades been well known for providing server
infrastructure for Linux and Open Source development so they were a 
good

fit. This however became an added maintenance burden for the small
non-profit with limited resources. Several members of the Bitcoin dev
community contributed funding to the lab in support of their Open 
Source

development infrastructure goals. But throwing money at the problem
isn't going to fix the ongoing maintenance burden created by 
antiquated

limitations of mailman2.

Permalinks
==

Linux Foundation has either offered or agreed to maintain archive
permalinks so that content of historic importance is not lost.
Fortunately for us while lists.linuxfoundation.org
 mailman will go down, they have
agreed the read-only pipermail archives will remain online. So all old
URLs will continue to remain valid. However, the moderators strongly
advise that the community supplements with public-inbox instances to
have canonical archive urls that are separate from any particular 
email

software host.

Public-Inbox


https://public-inbox.org/README.html 



"Public Inbox" decentralized archiving - no matter what mailing list
server solution is used, anyone can use git to maintain their own
mailing list archive and make it available to read on the web.

Public Inbox is a tool that you can run yourself. You can transform 
your

mbox file and it makes it browsable and viewable online. It commits
every post to a git repository. It's kind of like a decentralized mail
archiving tool. Anyone can publish the mail archive to any web server
they wish.

We should try to have one or more canonical archives that are served
using public-inbox. But it doesn't matter if these are lost because
anyone else can archive the mailing list in the same way and 
re-publish

the archives.

These git commits can also be stamped using opentimestamps, inserting
their hashes into the bitcoin blockchain.

LKML mailing list readers often use public-inbox's web interface, and
they use the reply-to headers to populate their mail client and reply 
to

threads of interest. This allows their reply to be properly threaded
even if they were not a previous subscriber to that mailing list to
receive the headers.

public-inbox makes it so that it doesn't really matter where the list 
is

hosted, as pertaining to reading the mailing list. There is still a
disruption if the mailing list goes 

Re: [bitcoin-dev] On mempool policy consistency

[yancy via bitcoin-dev]

I read Antoine's original post on this and got the general gist, and 
here also, it makes sense, but I'd like to ask: is it necessary that 
(B, C) in the above not *see* A's opt-out "pre-replacement" (inputs: 
A1, outputs: A, fees: low; call it TX_2)? I get that they cannot 
replace it


Is it actually true that they cannot replace it?  If miners and node 
operators collude and have the incentive to run a patched version of 
core, is it still technically impossible to replace?



the idea that they suffer financial loss from
"ignorant" fee bumping is the part that seems weird to me.


Even if they waste resources trying to fee-bump, I agree that this does 
not appear to be a catastrophe.There doesn't seem to be any technical 
reason why improvements can't be made to allow B and C to have a better 
view.


Cheers,
-Yancy

On 2022-11-08 10:28, AdamISZ via bitcoin-dev wrote:


Hi aj and list,
(questions inline)

--- Original Message ---
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via
bitcoin-dev  wrote:

Is that true? Antoine claims [1 [1]] that opt-in RBF isn't enough to 
avoid

a DoS issue when utxos are jointly funded by untrusting partners, and,
aiui, that's the main motivation for addressing this now.

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html


The scenario he describes is: A, B, C create a tx:

inputs: A1, B1, C1 [opts in to RBF]
fees: normal
outputs:
[lightning channel, DLC, etc, who knows]

they all analyse the tx, and agree it looks great; however just before
publishing it, A spams the network with an alternative tx, double
spending her input:

inputs: A1 [does not opt in to RBF]
fees: low
outputs: A

If A gets the timing right, that's bad for B and C because they've
populated their mempool with the 1st transaction, while everyone else
sees the 2nd one instead; and neither tx will replace the other. B and
C can't know that they should just cancel their transaction, eg:

inputs: B1, C1 [opts in to RBF]
fees: 50% above normal
outputs:
[smaller channel, refund, whatever]

and might instead waste time trying to fee bump the tx to get it 
mined,

or similar.

What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?


I read Antoine's original post on this and got the general gist, and
here also, it makes sense, but I'd like to ask: is it necessary that
(B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
replace it, but the idea that they suffer financial loss from
"ignorant" fee bumping is the part that seems weird to me. Clearly
TX_2 gets gossiped to other mempools; and understood that it does not
replace the TX_1 (the 3-input) in B's mempool, say, but why should
they not even hear about it? Is it just a matter of engineering, or is
there some deeper problem with that.

About this general flavour of attack, it's never been a *big* concern
in Joinmarket imo (though, we did until recently have a bug that made
this happen *by accident*, i.e. people double spending an input out of
a negotiated join, albeit it was rare; but it's ofc definitely
*possible* to 'grief' like this, given the ordering of events; maker
sends signature, maker broadcasts double spend - 95% of the time they
will be first). Interactive protocols are yucky and I think there'll
always be griefing possibilities; designing around multiple-rounds of
negotiation amongst not always-on participants is even more yucky, so
just having a 'taker is in charge of network fee; if it's slow or gets
double spent out causing time delay then just wait', combined with
'there really isn't any economic incentive for an attacker' (i.e.
ignoring griefing) might sound crappy but it's probably just being
realistic.

Of course, off-chain contracting has more sophisticated considerations
than this.

Cheers,
AdamISZ/waxwing

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



Links:
--
[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[yancy via bitcoin-dev]

technically, all we need is for *miners* to consistently mine "full
rbf"


There's another important point I think:

technically, all we need is for *miners* to consistently mine the 
highest fee-rate transaction (or the one with the most incentive).


Miners could probably be incentivized to mine transactions that double 
spend a previous transaction that isn't rbf, also.


Cheers,
-Yancy

On 2022-11-03 14:32, Erik Aronesty via bitcoin-dev wrote:


actually, peter makes an important point here

technically, all we need is for *miners* to consistently mine "full
rbf"

as long as they do, businesses that accept 0conf will have to adjust
their risk accordingly, and the problem of misaligned incentives is
resolved

i don't think it matters what non-mining users do nearly as much

On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev
 wrote:

Hi Peter,

tl;dr: I'm broadcasting full-RBF replacements paying extremely high 
fees to reward miners that turn on full-RBF. I'm starting small, just 
~$100/block in times of congestion. Miner and pool profit margins are 
pretty small, on the order of $1k/block in many cases, so I know it 
doesn't take that much more money to make a difference.

I appreciate this effort and perhaps this was all that was needed in
addition to Bitcoin Core's inclusion of full rbf support. Making it
default right away or enabling preferential peering with service
flag in a bitcoin core release was unnecessary.

If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
Sorry, I don't trust you based on some of the things you support on
Twitter. Hopefully, others will donate and help this bounty.

/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via
bitcoin-dev  wrote:

I'm now running a full-RBf bounty program for miners.

tl;dr: I'm broadcasting full-RBF replacements paying extremely high 
fees to reward miners that turn on full-RBF. I'm starting small, just 
~$100/block in times of congestion. Miner and pool profit margins are 
pretty small, on the order of $1k/block in many cases, so I know it 
doesn't take that much more money to make a difference.


Why should you do this? Full-RBF/zeroconf has been discussed to death. 
But tl;dr: You'll earn more money, and help transition Bitcoin to a 
more secure mempool policy based on economic incentives rather than 
trust.


If you're a miner and want to participate, the easiest way to so is to 
use the mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 
release (eg the 24.0rc3 tag), or use the mempoolreplacement=fee option 
in Bitcoin Knots.
You can also just modify the code yourself by removing the opt-in RBF 
check. For example against the v23.0 tag:


$ git diff
diff --git a/src/validation.cpp b/src/validation.cpp
index 214112e2b..44c364623 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, 
Workspace& ws) // check all unconfirmed ancestors; otherwise an opt-in 
ancestor

// might be replaced, causing removal of this descendant.
if (!SignalsOptInRBF(*ptxConflicting)) {
- return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, 
"txn-mempool-conflict"); + // return 
state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, 
"txn-mempool-conflict"); }


ws.m_conflicts.insert(ptxConflicting->GetHash());

Once you've enabled full-RBF, you need a full-RBF peer. I'm running a 
few of them:


cup.nop.lol
mug.nop.lol
jar.nop.lol
jug.nop.lol

These nodes run a preferential peering patch 
(https://github.com/bitcoin/bitcoin/pull/25600) to ensure that full-RBF 
nodes are interconnected to each other and replacements can easily 
propagate. Also feel free to contact me if you'd like to peer with a 
private node.


If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m

...and yes, I'm well aware that miners could collect this bounty in 
other ways, eg by raising minimum fees. Doing that also breaks 
zeroconf, so I'm not too concerned.


--
https://petertodd.org 'peter'[:-1]@petertodd.org [1 [1]]
___
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


Links:
--
[1] http://petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
--
[1] http://petertodd.org___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[yancy via bitcoin-dev]

Bob has staked liquidity in a payment channel with Alice who later
double spends the same inputs (at a very low feerate) resulting in a
stalemate where neither can spend the UTXOs.


I just realized I made a mistake.  RBF will always mine the higher fee 
transaction, so in this case, full-rbf would prevent a transaction from 
being pinned.


On 2022-11-08 15:54, yancy via bitcoin-dev wrote:


Peter,

It sounds like there are two attack vectors; neither of which require
full-rbf (correct me if I'm wrong).

1) Bob has staked liquidity in a payment channel with Alice who later
double spends the same inputs (at a very low feerate) resulting in a
stalemate where neither can spend the UTXOs.  The TX that creates the
payment channel with Bob will never be mined since the mining pool
sees the double spend?

2) Alice spams the network with a double spend wide enough that the
double spend makes it into a block before the remainder of the network
sees the first spend.

In that case of 1), what if Bob required a opt-in rbf?  Wouldn't that
solve the issue?  Bob could just create a replacement transaction with
enough fee to get back his UTXO?

For 2) it seems to me that neither full-rbf or opt-in rbf resolves
this, although it's a probabilistic attack and requires spamming many
nodes.

Cheers,
-Yancy

On 2022-11-07 15:32, Peter Todd wrote:


On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
 wrote:
AJ/Antoine et al

What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
Assuming Alice is a well funded advisory, with enough resources to
spam the network so that enough nodes see her malicious transaction
first, how does full-rbf solve this vs. opt-in rbf?


First of all, to make things clear, remember that the attacks were
talking about are aimed at _preventing_ a transaction from getting
mined. Alice wants to cheaply broadcast something with low fees that
won't get mined soon (if ever), that prevents a protocol from making
forward progress.

With full-rbf, who saw what transaction first doesn't matter: the
higher fee paying transaction will always(*) replace the lower fee
one. With opt-in RBF, spamming the network can beat out the
alternative.

*) So what's the catch? Well, due to limitations in today's mempool
implementation, sometimes we can't fully evaluate which tx pays the
higher fee. For example, if Alice spams the network with very _large_
numbers transactions spending that input, the current mempool code
doesn't even try to figure out if a replacement is better.

But those limitations are likely to be fixable. And even right now,
without fixing them, Alice still has to use a lot more money to pull
off these attacks with full-rbf. So full-rbf definitely improves the
situation even if it doesn't solve the problem completely.
___
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] On mempool policy consistency

[yancy via bitcoin-dev]

Peter,

It sounds like there are two attack vectors; neither of which require 
full-rbf (correct me if I'm wrong).


1) Bob has staked liquidity in a payment channel with Alice who later 
double spends the same inputs (at a very low feerate) resulting in a 
stalemate where neither can spend the UTXOs.  The TX that creates the 
payment channel with Bob will never be mined since the mining pool sees 
the double spend?


2) Alice spams the network with a double spend wide enough that the 
double spend makes it into a block before the remainder of the network 
sees the first spend.


In that case of 1), what if Bob required a opt-in rbf?  Wouldn't that 
solve the issue?  Bob could just create a replacement transaction with 
enough fee to get back his UTXO?


For 2) it seems to me that neither full-rbf or opt-in rbf resolves this, 
although it's a probabilistic attack and requires spamming many nodes.


Cheers,
-Yancy

On 2022-11-07 15:32, Peter Todd wrote:


On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
 wrote:
AJ/Antoine et al

What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
Assuming Alice is a well funded advisory, with enough resources to spam 
the network so that enough nodes see her malicious transaction first, 
how does full-rbf solve this vs. opt-in rbf?


First of all, to make things clear, remember that the attacks were
talking about are aimed at _preventing_ a transaction from getting
mined. Alice wants to cheaply broadcast something with low fees that
won't get mined soon (if ever), that prevents a protocol from making
forward progress.

With full-rbf, who saw what transaction first doesn't matter: the
higher fee paying transaction will always(*) replace the lower fee
one. With opt-in RBF, spamming the network can beat out the
alternative.

*) So what's the catch? Well, due to limitations in today's mempool
implementation, sometimes we can't fully evaluate which tx pays the
higher fee. For example, if Alice spams the network with very _large_
numbers transactions spending that input, the current mempool code
doesn't even try to figure out if a replacement is better.

But those limitations are likely to be fixable. And even right now,
without fixing them, Alice still has to use a lot more money to pull
off these attacks with full-rbf. So full-rbf definitely improves the
situation even if it doesn't solve the problem completely.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On mempool policy consistency

[yancy via bitcoin-dev]

Peter,

There's nothing special about a "full-rbf transaction" other than the 
fact
that it's replacing a previously broadcast transaction that didn't 
signal

replacement.


Thanks, this is a piece I haven't seen.  It sounds like "full-rbf" 
policy is fundamentally different from BIP125, where in BIP125 a 
transaction must signal that it can be replaced.  If I'm reading what 
you said correctly, then "full-rbf" policy will allow the replacement of 
any transaction, whether it's signaled or not..


Since all the machinery to do replacemnt already exists, adding a 
full-rbf
config flag is particularly trivial. It requires just a single line in 
the

mempool code.


Agree the flag is trivial.  The interplay between mempool policies may 
not be trivial.


Cheers,
-Yancy

On 2022-10-31 18:51, Peter Todd wrote:


On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote:


Protocol Devs,

After reading through this email thread and BIP125, I'm curious if 
non-rbf
nodes will relay full-rbf transactions and vice versa.  That is to 
say, if

only one non-rbf node exists on the network, however, every other node
implements full-rbf, will the transaction still be propagated?  IE can 
we
always guarantee a path through the network for either transaction 
type no

matter what the combination of network policies are?


1) There are nodes that signal full-rbf, and preferentially peer to 
each other,
thus ensuring good transaction propagation. The most recent patch to 
implement

this is: https://github.com/bitcoin/bitcoin/pull/25600

There's enough peers running full-rbf that the last time I started up a 
new
node on a fresh IP address, it happened to have a peer relaying 
full-rbf

replacements to it. And of course, if people want full-rbf to work more
reliably, it's very easy to just run some nodes with a large number of 
outgoing
peers. Changing the hard-coded 8 outgoing peers to, say, 800, isn't 
very hard.


2) There's nothing special about a "full-rbf transaction" other than 
the fact
that it's replacing a previously broadcast transaction that didn't 
signal
replacement. There is not consensus over the mempool, so in certain 
cases
non-full-rbf nodes will in fact broadcast replacements when they didn't 
happen

to receive the "first" transaction first.

The latter makes testing full-rbf a bit problematic, as if you don't 
take

special measures to ensure good propagation a small % of the time the
"replacement" transaction will in fact be the one that gets gets mined.

Does fullrbf offer any benefits other than breaking zeroconf
business practices?  If so, what are they?
I think AJ mentioned this earlier, but adding more configuration 
options

always increases code complexity, and with that, there is likely more
unforeseen bugs.  However, there is a section of network participants 
that
rely on both types of transaction policy, so from my limited 
view-point, it

seems worth accommodating if possible.


Since all the machinery to do replacemnt already exists, adding a 
full-rbf
config flag is particularly trivial. It requires just a single line in 
the

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

Re: [bitcoin-dev] On mempool policy consistency

[yancy via bitcoin-dev]

AJ/Antoine et al


What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?


Assuming Alice is a well funded advisory, with enough resources to spam 
the network so that enough nodes see her malicious transaction first, 
how does full-rbf solve this vs. opt-in rbf?


Cheers,
-Yancy

On 2022-10-27 19:21, Anthony Towns via bitcoin-dev wrote:

On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalho via bitcoin-dev 
wrote:


I took the time to read your whole post. Despite a diplomatic tone, I 
find
your takeaways from all your references to remain conveniently biased 
for

protecting the plan of RBF


Yes, I am heavily biased against zeroconf: there's no way I'd 
personally

be willing to trust it for my own incoming funds, no matter how much
evidence you show me that it's safe in practice. Show me a million
transactions where every single one worked fine, and I'm still going to
assume that the payment going to me is going to be the one that makes
the error rate tick up from 0% to 0.0001%. That's okay; just because I
wouldn't do something, doesn't mean other people shouldn't.

It does mean I'm not going to be a particularly good advocate for 
zeroconf

though. I mean, I might still be a fine advocate for giving people time
to react, making it clear what's going on, finding ways that might make
everyone happy, or just digging it to random technical details; but,
for me, I'm more interested in a world where chargebacks are 
impossible,

not where we just make the best of what was possible with technology
from five or ten years ago.

But that's fine: it just means that people, like yourself, who will
tolerate the risks of zeroconf, should be involved in the discussion.

You show multiple examples where, when I read them, I assume the next 
thing
you will say will be "so we really should stop trying to impose 
optional
features, particularly when they affect existing use cases" but 
instead you

persist.


Sure, that's natural: you read a sign saying "you can have any ice 
cream

you want for 5c" and think "Awesome, who wouldn't want cheap chocolate
ice cream!!" and see me going for a Golden Gaytime and think "wtf 
dude".

Different strokes.

For me, I see the gmaxwell github comment I quoted saying:

There is also a matter of driving competent design rather than lazy
first thing that works.

and think "yeah, okay, maybe we should be working harder to push 
lightning

adoption, rather than letting people stick with wallet UX from 2015"
and have altcoins take over >50% of payment volume.

Likewise,

There is also a very clear pattern we've seen in the past where
people take anything the system lets them do as strong evidence that
they have a irrevocable right to use the system in that way, and that
their only responsibility-- and if their usage harms the system it's
the responsibility of the system to not permit it.

seems a pretty good match against your claim "I expect the things I do
with Bitcoin today to work FOREVER." Better to nip that thinking in the
bud; and even if the best time to do that was years ago, the second 
best

time to do it is still now.

By contrast, from the same post, I'd guess you're focussing on:

Network behavior is one of the few bits of friction
driving good technical design rather than "move fast, break things, and
force everyone else onto my way of doing thing rather than discussing
the design in public".

and thinking "yeah, move fast, break things, force everyone else --
that's exactly what's going on here, and shouldn't be".

But that's also okay: even when there is common ground to be found,
sometimes it requires actual work to get people who start from 
different

views to get there.

The problem is that RBF has already been an option for years, and 
anyone

that wants to use it can.


Is that true? Antoine claims [1 [1]] that opt-in RBF isn't enough to 
avoid

a DoS issue when utxos are jointly funded by untrusting partners, and,
aiui, that's the main motivation for addressing this now.

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html


The scenario he describes is: A, B, C create a tx:

inputs: A1, B1, C1 [opts in to RBF]
fees: normal
outputs:
[lightning channel, DLC, etc, who knows]

they all analyse the tx, and agree it looks great; however just before
publishing it, A spams the network with an alternative tx, double
spending her input:

inputs: A1 [does not opt in to RBF]
fees: low
outputs: A

If A gets the timing right, that's bad for B and C because they've
populated their mempool with the 1st transaction, while everyone else
sees the 2nd one instead; and neither tx will replace the other. B and
C can't know that they should just cancel their transaction, eg:

inputs: B1, C1 [opts in to RBF]
fees: 50% above normal
outputs:
[smaller channel, refund, whatever]

and might instead waste time trying to fee bump the tx to get it mined,
or similar.

What should folks 

Re: [bitcoin-dev] On mempool policy consistency

[yancy via bitcoin-dev]

Protocol Devs,

After reading through this email thread and BIP125, I'm curious if 
non-rbf nodes will relay full-rbf transactions and vice versa.  That is 
to say, if only one non-rbf node exists on the network, however, every 
other node implements full-rbf, will the transaction still be 
propagated?  IE can we always guarantee a path through the network for 
either transaction type no matter what the combination of network 
policies are?



Does fullrbf offer any benefits other than breaking zeroconf
business practices?  If so, what are they?


I think AJ mentioned this earlier, but adding more configuration options 
always increases code complexity, and with that, there is likely more 
unforeseen bugs.  However, there is a section of network participants 
that rely on both types of transaction policy, so from my limited 
view-point, it seems worth accommodating if possible.


Cheers,
-Yancy

On 2022-10-31 17:25, Greg Sanders via bitcoin-dev wrote:


Thanks for your full thoughts Suhas,

The idea of V3 is that we're currently leaving fees on the table by
allowing use-cases to be pinned, not that we like Lightning and we
think miners should stop being profit maximizing somehow to enable
safer/better layer 2 systems.

If someone wants to bump fees for V3 transactions(or replace them!),
there's a much simpler "API" to do so than in legacy policy land. The
fact that it disallows more idiotic ways to add more total fees means
wallets "shouldn't do that". If it ends up that V3 is disallowing too
many "natural" ways to fee bump, that's a strike against the V3 idea
and should be discussed. For 0-conf services we have potential thieves
who are willing to *out-bid themselves* to have funds come back to
themselves. It's not a "legitimate" use-case, but a rational one.

I have mostly come around to not pushing for fullrbf due to the issues
you mentioned, except taking away the option. Removing a
quite-likely-incentive-compatible option from the software just
encourages miners to adopt an additional patch if they ever deem it
necessary to increase their revenue, even if that revenue is from
hurting 0-conf businesses.

Maybe putting/leaving in a default-false flag for disabling these
"carve outs" is the least bad option. V3 usage patterns shouldn't
crumble if a large majority of miners opt out, but 0-conf use cases
crumble after a small percentage of adoption.

To recap my thoughts:

1) I have put away my fullrbf hats, I will not advocate anyone running
it as I think it doesn't really do anything useful for users who
aren't trying to double-spend merchants.

2) Forcing miners to honor fees left on the table with respect to
0-conf, or forcing them to run a custom patchset to go around it, is a
step backwards.

Greg

On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev
 wrote:


AJ,

Thanks for the thoughtful post. I think your observations about how
we view mempool policy in the Bitcoin Core project, and how that
seems to be changing in the discussions around `-mempoolfullrbf`,
are on-point and provide a helpful baseline for considering future
policy changes.

For a long time I viewed fullrbf as an eventuality and I considered
myself to be philosophically supportive of the idea.  However, after
giving this issue some thought in the past few weeks, I am reversing
my thinking on this.  Concretely, I will argue that we should
continue to maintain a relay policy where replacements are rejected
for transactions that don't opt-in to RBF (as described in BIP 125),
and moreover, that we should remove the `-mempoolfullrbf` flag from
Bitcoin Core's latest release candidate and not plan to release
software with that flag, unless (or until) circumstances change on
the network, which I'll discuss below.

This is, of course, a nuanced topic, and among the considerations is
a philosophy of how to think about the relay policy and
configuration options that we make available in Bitcoin Core (a
consideration that is perhaps unique to that project, but I think
relevant for this mailing list).

I'll start with some technical issues regarding the benefits of
enabling fullrbf on the network.  In the current BIP 125 regime,
every time a transaction is created, a choice is made whether to
subject the transaction to BIP 125's RBF rules or not (based on
the sequence values of the inputs).  So given that users can already
opt-in to RBF, the benefit of a "fullrbf" network policy would
be if, somehow, RBF users were still denied the benefits of RBF due
to the existence of other transactions that don't opt-in.

Along those lines, Antoine Riard brought up[1] a DoS vector that is
available to someone who wants to interfere with multi-party funded
transactions, and suggested that fullrbf would eliminate the
problem.  After exploring that question again in this thread (thanks
to Greg Sanders for clarifying this to me), I understand that the
issue is around ensuring that a multiparty (coinjoin-type) protocol
is able to make eventual 

Re: [bitcoin-dev] On mempool policy consistency

[yancy via bitcoin-dev]

Whether that's terrible or not depends on how easy it is to retry (and 
how
likely the retry is to succeed) after a failure -- if a TCP packet 
fails,
it just gets automatically resent, and if that succeeds, there's a 
little

lag, but your connection is still usable


I'm not sure if that analogy fits here.  A TCP packet will be retried 
(as opposed to UDP), although usually the retry strategy is because of 
an underlying connection issue, not a protocol mismatch or in this case 
"policy" mismatch, right?


If network propagation and node discovery becomes an issue, and as 
Antoine mentions, there becomes a need for competing services as I 
understand it, could that give rise to indexes and trackers who spider 
the network to create world view?  Perhaps it's a bad idea since "third 
party" trackers are security holes, however, to my knowledge, we already 
have "trusted" nodes during the initial bootstrap process.  Even so, I 
don't think we could preclude such solutions from occurring organically 
if the need is arises.


Cheers,
-Yancy

On 2022-10-30 02:02, Anthony Towns via bitcoin-dev wrote:


On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Harding via
bitcoin-dev wrote:

I think this might be understating the problem.  A 95% chance of 
having
an outbound peer accept your tx conversely implies 1 in 20 payments 
will

fail to propagate on their initial broadcast.


Whether that's terrible or not depends on how easy it is to retry (and 
how
likely the retry is to succeed) after a failure -- if a TCP packet 
fails,
it just gets automatically resent, and if that succeeds, there's a 
little
lag, but your connection is still usable. I think it's *conceivable* 
that

a 5% failure rate could be detectable and automatically rectified. Not
that I have a good idea how you'd actually do that, in a way that's
efficient/private/decentralised...


Some napkin math: there are about 250,000 transactions a day; if
we round that up to 100 million a year and assume we only want one
transaction per year to fail to initially propagate on a network where
30% of nodes have adopted a more permissive policy, lightweight 
clients

will need to connect to over 50 randomly selected nodes.[1]


A target failure probability of 1-in-1e8 means:

* with 8 connections, you need 90% of the network to support your txs
* with 12 connections, you need ~79%
* with 24 connections (eg everyone running a long-lived node is
listening, so long lived nodes make 12 outbound and receive about
~12 inbound; shortlived nodes just do 24 outbound), you need ~54%

So with that success target, and no preferential peering, you need
a majority of listening nodes to support your tx's features in most
reasonable scenarios, I think.


For a more
permissive policy only adopted by 10% of nodes, the lightweight client
needs to connect to almost 150 nodes.


I get 175 connections needed for that scenario; or 153 with a target
failure rate of 1-in-10-million.

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] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[yancy via bitcoin-dev]

...and the easiest way to avoid Bitcoin being a system that doesn't 
arbitrarily
change rules, is to rely on economically rational rules that aren't 
likely to

change!


Yes, I think many people on this thread have been making the same point. 
 This is the basis of the Nash Equilibrium, from what I remember.



This, Satoshi (who doesn't really matter anyways I guess?)


It doesn't seem to me Satoshi was classically trained in CS else maybe 
he/she/they might have referenced the Nash Equilibrium.  Looking at some 
of the other references, including a statistics book titled "An 
Introduction to Probability Theory and its Applications" from 1957 makes 
me think this Satoshi person was closer in training and practice to a 
mathematician.


Cheers,
-Yancy

On 2022-10-21 02:26, Peter Todd via bitcoin-dev wrote:


On Thu, Oct 20, 2022 at 04:54:00PM -0700, Jeremy Rubin wrote:


The difference between honest majority and longest chain is that the
longest chain bug was something acknowledged by Satoshi & patched
https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420
.

OTOH, we have more explicit references that the honest majority really
should be thought of as good guys vs bad guys... e.g.


The point is Satoshi got a lot of very fundamental stuff wrong. 
Bringing up
what Satoshi wrote now, almost 14 years later, misleads less-technical 
readers
into thinking our understanding of Bitcoin is still based on that 
early,

incorrect, understanding.

Incidentally, you realize that it was _Satoshi_ who added RBF to 
Bitcoin with
nSequence replacements. My contribution was to fix that obviously 
broken design
with fee-based RBF (with nSequence a transaction could be replaced up 
to 4
billion times, using essentially unlimited P2P bandwidth; it was a 
terrible

idea).

I do think the case can be fairly made for full RBF, but if you don't 
grok

the above maybe you won't have as much empathy for people who built a
business around particular aspects of the Bitcoin network that they 
feel
are now being changed. They have every right to be mad about that and 
make
disagreements known and argue for why we should preserve these 
properties.


Those people run mild sybil attacks on the network in their efforts to
"mitigate risk" by monitoring propagation; fundamentally doing so is
centralizing and unfair, as only a small number of companies can do 
that
without DoS attacking the P2P network. It's pretty obvious that 
reliance to
zeroconf is harmful to Bitcoin, and people trying to do that have 
repeatedly
taken big losses when their risk mitigations turned out to not work. 
Their only

right to be mad comes from the 1st Ammendment.

As someone who wants for Bitcoin to be a system which doesn't 
arbitrarily
change rules based on the whims of others, I think it important that 
we can

steelman and provide strong cases for why our actions might be in the
wrong, so that we make sure our justifications are not only 
well-justified,
but that we can communicate them clearly to all participants in a 
global

value network.


...and the easiest way to avoid Bitcoin being a system that doesn't 
arbitrarily
change rules, is to rely on economically rational rules that aren't 
likely to

change!

___
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] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[yancy via bitcoin-dev]

I had one other idea on the topic.  Namely, in the last section 
"calculation", Satoshi talks more about what he/she/they consider to be 
bad actors.  The idea that someone is not doing "tip mining" does not 
mean they are dishonest.


We consider the scenario of an attacker trying to generate an alternate 
chain faster than the honest
chain. Even if this is accomplished, it does not throw the system open 
to arbitrary changes, such
as creating value out of thin air or taking money that never belonged 
to the attacker. Nodes are
not going to accept an invalid transaction as payment, and honest nodes 
will never accept a block
containing them. An attacker can only try to change one of his own 
transactions to take back

money he recently spent.


It seems to me that there's a distinction in the game theoretics between 
"not tip mining" and actively being a bad actor (changing a past 
transaction signed by yourself).


I rewrote the "AttackerSuccessProbability" C function in Rust for fun:
https://github.com/yancyribbens/attacker-success-probability-rust

Cheers,
-Yancy

On 2022-10-18 18:27, Jeremy Rubin via bitcoin-dev wrote:


I think the issue with


I still think it is misguided to think that the "honest" (i.e. rule
following) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive
compatible for the system to be functional.  The honest majority is
only considered an assumption because even if following the rules
were clearly the 100% dominant strategy, this doesn't prove that the
majority is honest, since mathematics cannot say what is happening
in the real world at any given time.  Still, we must have a reason
to think that the majority would be honest, and that reasoning
should come from an argument that the rule set is incentive
compatible.


epistemically is that even within the game that you prove the dominant
strategy, you can't be certain that you've captured (except maybe
through clever use of exogenous parameters, which reduces to the same
thing as % honest) the actual incentives of all players. For example,
you would need to capture the existence of large hegemonic governments
defending their legacy currencies by attacking bitcoin.

I think we may be talking past each other if it is a concern /
valuable exercise to decrease the assumptions that Bitcoin rests on to
make it more secure than it is as defined in the whitepaper. That's an
exercise of tremendous value. I think my point is that those things
are aspirational (aspirations that perhaps we should absolutely
achieve?) but to the extent that we need to fix things like the fee
market, selfish mining, mind the gap, etc, those are modifying Bitcoin
to be secure (or more fair is perhaps another way to look at it) in
the presence of deviations from a hypothesized "incentive compatible
Bitcoin", which is a different thing that "whitepaper bitcoin". I
think that I largely fall in the camp -- as evidenced by some past
conversations I won't rehash -- that all of Bitcoin should be
incentive compatible and we should fix it if not. But from those
conversations I also learned that there are large swaths of the
community who don't share that value, or only share it up to a point,
and do feel comfortable resting on honest majority assumptions at one
layer of the stack or another. And I think that prior / axiom is a
pretty central one to debug or comprehend when dealing with, as is
happening now, a fight over something that seems obviously not
incentive compatible.

--
@JeremyRubin [1 [1]]

On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor
 wrote:

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
 wrote:

However, what *is* important about what Satoshi wrote is that it
is sort of the "social contract" of what Bitcoin is that we can
all sort of minimally agree to. This makes it clear, when we try
to describe Bitcoin with differing assumptions than in the
whitepaper, what the changes are and why we think the system might
support those claims. But if we can't prove the new description
sound, such as showing tip mining to be rational in a fully
adversarial model, it doesn't mean Bitcoin doesn't work as
promised, since all that was promised originally is functioning
under an honest majority. Caveat Emptor!
I still think it is misguided to think that the "honest" (i.e. rule
following) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive
compatible for the system to be functional.  The honest majority is
only considered an assumption because even if following the rules
were clearly the 100% dominant strategy, this doesn't prove that the
majority is honest, since mathematics cannot say what is happening
in the real world at any given time.  Still, we must have a reason
to think that the majority would be honest, and that reasoning
should come from an argument that the rule set is incentive
compatible.

The stability of mining, 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[yancy via bitcoin-dev]

not sure if this is helpful, but when i'm code reviewing a change to
an existing, functioning and very complex system, i rarely go back to
"first principles" to analyze that change independently, and instead
try to decide if it's better or worse than what we have now


I agree that it's important to not be too dogmatic, which includes 
Satoshi and the white paper. It's fun to look back and read to try to 
find inspiration, although, it seems to me, a lot has been learned since 
then.  And a lot will be learned in the future.  I was thinking to 
myself, what if in the distant future, quantum entanglement could be 
used to update all nodes simultaneously across any distance in space? 
How cool would that be?  How might that change from the original vision? 
 Well, if we ever get that far, I'm sure Satoshi could not have planned 
for that, or maybe they could have.. :)


On 2022-10-18 19:33, Erik Aronesty via bitcoin-dev wrote:


not sure if this is helpful, but when i'm code reviewing a change to
an existing, functioning and very complex system, i rarely go back to
"first principles" to analyze that change independently, and instead
try to decide if it's better or worse than what we have now

you can introduce a new feature, for example, that has a bunch of
noncritical bugs, especially in ux, and then you can weigh in on
whether its better to get it out now for the people that need it, or
bikeshed ux for another 2 releases

i'm often a fan of the former

if someone proposes a change to bitcoin, we should probably review it
as "better or worse than what we have", rather than "has perfectly
aligned incentives promoting honest behavior even among selfish
actors"

we know bitcoin functions now with a complex series of incentives,
especially regarding node operators

in other words, does the change "improve what we have" is a better bar
than "stands on its own"

in that way the system can slowly improve over time, rather than be
stuck

On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev
 wrote:

I think the issue with

I still think it is misguided to think that the "honest" (i.e.
rule following) majority is to just be accepted as an axiom and if
it is violated, well, then sorry.  The rules need to be incentive
compatible for the system to be functional.  The honest majority
is only considered an assumption because even if following the
rules were clearly the 100% dominant strategy, this doesn't prove
that the majority is honest, since mathematics cannot say what is
happening in the real world at any given time.  Still, we must
have a reason to think that the majority would be honest, and that
reasoning should come from an argument that the rule set is
incentive compatible.
epistemically is that even within the game that you prove the
dominant strategy, you can't be certain that you've captured (except
maybe through clever use of exogenous parameters, which reduces to
the same thing as % honest) the actual incentives of all players.
For example, you would need to capture the existence of large
hegemonic governments defending their legacy currencies by attacking
bitcoin.

I think we may be talking past each other if it is a concern /
valuable exercise to decrease the assumptions that Bitcoin rests on
to make it more secure than it is as defined in the whitepaper.
That's an exercise of tremendous value. I think my point is that
those things are aspirational (aspirations that perhaps we should
absolutely achieve?) but to the extent that we need to fix things
like the fee market, selfish mining, mind the gap, etc, those are
modifying Bitcoin to be secure (or more fair is perhaps another way
to look at it) in the presence of deviations from a hypothesized
"incentive compatible Bitcoin", which is a different thing that
"whitepaper bitcoin". I think that I largely fall in the camp -- as
evidenced by some past conversations I won't rehash -- that all of
Bitcoin should be incentive compatible and we should fix it if not.
But from those conversations I also learned that there are large
swaths of the community who don't share that value, or only share it
up to a point, and do feel comfortable resting on honest majority
assumptions at one layer of the stack or another. And I think that
prior / axiom is a pretty central one to debug or comprehend when
dealing with, as is happening now, a fight over something that seems
obviously not incentive compatible.

--
@JeremyRubin [1 [1]]

On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor
 wrote:

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
 wrote:

However, what *is* important about what Satoshi wrote is that it is
sort of the "social contract" of what Bitcoin is that we can all
sort of minimally agree to. This makes it clear, when we try to
describe Bitcoin with differing assumptions than in the whitepaper,
what the changes are and why we think the system might support those
claims. But if we can't prove the new description sound, such as
showing tip 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[yancy via bitcoin-dev]

Hi Jeremy,

Thanks for the reply. I do find the semantics of mempool and block org 
interesting (although there's a lot on the topic I don't know).



E.g., suppose:

Block N: Fees = 10, reward = 1

Mempool: Fees = 2

Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging
leads to reward of up to 10 + 1 + c, (c < 2, where c is the extra
transactions that fit).


If I'm reading this correctly, Block N was already mined, but the miner 
who mined block N+1 repacks the transactions from block N because they 
have more to gain.  Wouldn't such a situation be resolved in the same 
way as two miners who find a block at a similar time? E.g the network 
will choose depending on when block N+2 is created.



Assume instead your reward is 8, leaving 3+c on the table.


Mining block N+1 with the mempool leads to reward 2+8 = 10, reorging 
leads to 10 + 8 + c?  Wouldn't that leave 8+c?



If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for
them, which is the new one you made as a non-tip miner since you
"shared" some fee.


I'm curious how the "fee sharing" would be organized.  To see if I 
understand, You're asking what would happen if one of the two miners 
incentives (bribes in this case) the next miner (block N+1) to choose 
one of the competing tip miners?



You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require
larger incentive).


Agree.


However, as many have pointed out, perhaps not following the simple
"honest tip mining" strategy is bad for bitcoin, so maybe we should
expect it not to happen often?


The idea that people won't do something because it's "bad for Bitcoin" 
doesn't fit an adversarial model.  Even in the above examples (which I 
think wouldn't expect to happen often), I would argue the network still 
conforms to a Nash Equilibrium without requiring trust.  Although It's 
mostly speculation without some empirical data.


Cheers,
-Yancy

On 2022-10-17 21:10, Jeremy Rubin wrote:


Building on the most work chain is perhaps not rational in many normal
circumstances that can come up today under the stated reference
strategy:

1) Take highest paying transactions that fit
2) Mine on tips

E.g., suppose:

Block N: Fees = 10, reward = 1

Mempool: Fees = 2

Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging
leads to reward of up to 10 + 1 + c, (c < 2, where c is the extra
transactions that fit). Assume instead your reward is 8, leaving 3+c
on the table.

If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for
them, which is the new one you made as a non-tip miner since you
"shared" some fee.

You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require
larger incentive).

However, as many have pointed out, perhaps not following the simple
"honest tip mining" strategy is bad for bitcoin, so maybe we should
expect it not to happen often? Or other strategies to emerge around
selecting transactions so that the next M blocks have a similar fee
profile, as opposed to picking greedily for the next block.

--
@JeremyRubin [1 [1]]

On Sun, Oct 16, 2022 at 3:03 PM  wrote:

The proof-of-work also solves the problem of determining
representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it
could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially
one-CPU-one-vote. The majority
decision is represented by the longest chain, which has the
greatest
proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes,
the
honest chain will grow the
fastest and outpace any competing chains. To modify a past block,
an
attacker would have to
redo the proof-of-work of the block and all blocks after it and
then
catch up with and surpass the
work of the honest nodes. We will show later that the probability
of a
slower attacker catching up
diminishes exponentially as subsequent blocks are added.
It's interesting that Nash Equilibrium isn't mentioned here.  Since
each miner has the option to either contribute to the longest chain
or not, even if the miners know what strategy the other miners will
use, they still wouldn't change their decision to contribute to the
majority.

For example, if I run a shop that takes rain checks, but I sell an
item to a higher bidder who didn't have a hold on the item, that
is
not honest, but it may be selfish profit maximizing.
It would be honest if the store policy said ahead of time they are
allowed to sell rain checks for more in such an occurrence.
Although this is a good example of the difference between honest and
rational.  I think this means it's not a Nash Equilibrium if we
needed to rely on the store owner to be honest.

Satoshi said an honest majority is 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[yancy via bitcoin-dev]

The proof-of-work also solves the problem of determining
representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it
could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially
one-CPU-one-vote. The majority
decision is represented by the longest chain, which has the greatest
proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes, the
honest chain will grow the
fastest and outpace any competing chains. To modify a past block, an
attacker would have to
redo the proof-of-work of the block and all blocks after it and then
catch up with and surpass the
work of the honest nodes. We will show later that the probability of a
slower attacker catching up
diminishes exponentially as subsequent blocks are added.


It's interesting that Nash Equilibrium isn't mentioned here.  Since each 
miner has the option to either contribute to the longest chain or not, 
even if the miners know what strategy the other miners will use, they 
still wouldn't change their decision to contribute to the majority.



For example, if I run a shop that takes rain checks, but I sell an
item to a higher bidder who didn't have a hold on the item, that is
not honest, but it may be selfish profit maximizing.


It would be honest if the store policy said ahead of time they are 
allowed to sell rain checks for more in such an occurrence.  Although 
this is a good example of the difference between honest and rational.  I 
think this means it's not a Nash Equilibrium if we needed to rely on the 
store owner to be honest.



Satoshi said an honest majority is required for the chain to be
extended. Honest is not really defined though. Honesty, in my
definition, is that you follow a pre specified rule, rational or not.


My take is that "rational" is probably a better word than honest.  In 
terms of a Nash Equilibrium, each participant is simply trying to 
maximize their outcome and honesty doesn't matter (only that 
participants are rational).



It seems a lot of the RBF controversy is that Protocol developers have
aspired to make the honest behavior also be the rational behavior.
This is maybe a good idea because, in theory, if the honest behavior
is rational then we can make a weaker assumption of selfishness
maximizing a parameter.


I'm curious, can RBF can be described by a Nash Equilibrium?  If yes, 
then it also shouldn't matter if participants are honest?



Overall, it might be nice to more tightly document what bitcoins
assumptions are in practice and what those assumptions do in terms of
properties of Bitcoin, as well as pathways to weakening the
assumptions without compromising the behaviors users expect the
network to have.  An "extended white paper" if you will.


White paper 1.1 :D


A last reflection is that Bitcoin is specified with an honest majority
assumption, but also has a rational dishonest minority assumption over
both endogenous (rewards) and exogenous (electricity) costs. Satoshi
did not suggest, at least as I read it, that Bitcoin works with an
rational majority assumption. (If anyone thinks these three are
similar properties you can make some trivial counterexamples)


My take is the opposite unless I'm missing something.  Participants are 
always incentivized to choose the rational solution (Not to waste 
electricity on a minority chain).


Cheers,
-Yancy

On 2022-10-16 19:35, Jeremy Rubin via bitcoin-dev wrote:


The Bitcoin white paper says:

The proof-of-work also solves the problem of determining
representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it
could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially
one-CPU-one-vote. The majority
decision is represented by the longest chain, which has the greatest
proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes, the
honest chain will grow the
fastest and outpace any competing chains. To modify a past block, an
attacker would have to
redo the proof-of-work of the block and all blocks after it and then
catch up with and surpass the
work of the honest nodes. We will show later that the probability of a
slower attacker catching up
diminishes exponentially as subsequent blocks are added.

This, Satoshi (who doesn't really matter anyways I guess?) claimed
that for Bitcoin to function properly you need a majority honest
nodes.

There are multiple behaviors one can describe as honest, and
economically rational or optimizing is not necessarily rational.

For example, if I run a shop that takes rain checks, but I sell an
item to a higher bidder who didn't have a hold on the item, that is
not honest, but it may be selfish profit maximizing.

Satoshi said an honest majority is required for the chain to be
extended. Honest is not really defined though. Honesty, in my
definition, is that you follow a pre specified rule, rational or not.

It seems a lot of the RBF 

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options

[yancy via bitcoin-dev]

Prayank,

I believe the p2pderivatives DLC application is still under active 
development here (single oracle):

https://github.com/p2pderivatives/rust-dlc

I was once involved in the project in a galaxy far far away but haven't 
kept up with the project.  Also, I'm a few days behind in the Bitcoin 
Advent Calendar :)


Cheers,
-Yancy


On 2021-12-24 17:42, Prayank via bitcoin-dev wrote:

Hi Jeremy,


Wheres the info come from? Well, multiple places. We could get it

from a third party (maybe using an attestation chain of some sort?),
or there are certain ways it could be self-referential (like for
powswap [1]).


Now let’s define a threshold oracle – we wouldn’t want to

trust just one lousy oracle, so let’s trust M out of N of them!

Similar approach is used in discreet log contracts for multi oracles.
There is even a project for P2P derivatives but it was not used for
any real trades on mainnet or further developed. What difference would
OP_CTV make in this project if its implemented in Bitcoin?

https://github.com/p2pderivatives/p2pderivatives-client

https://github.com/p2pderivatives/p2pderivatives-server

https://github.com/p2pderivatives/p2pderivatives-oracle


Does this NEED CTV?


No, not in particular. Most of this stuff could be done with online
signer server federation between you and counterparty. CTV makes some
stuff nicer though, and opens up new possibilities for opening these
contracts unilaterally.

Nicer? How would unilateral derivatives work because my understanding
was that you always need a peer to take the other side of the trade. I
wish we could discuss this topic in a trading community with some
Bitcoiners that even had some programming knowledge.

Derivatives are interesting and less explored or used in Bitcoin
projects. They could be useful in solving lot of problems.

--

Prayank

A3B1 E430 2298 178F


Links:
--
[1] https://powswap.com
___
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] Taproot Activation Meeting 4/20 Cancelled

[yancy via bitcoin-dev]

I appreciate the bluntness, Jeremy, and agree it's high time folks enjoy the 
holiday.

Cheers,
-Yancy
___
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

[yancy via bitcoin-dev]

Ok thanks.  Using the correct terminology helps people understand what you're 
talking about and take you seriously.

Cheers,
-Yancy

Mar 13, 2021 4:02:18 PM Lonero Foundation :

> Hi, I know the differences between the cryptographic hashing algorithm and 
> key validation. I know hashing is for SHA, but was referring to asymmetric 
> cryptography in regards to the key validation. I should have used a different 
> term though instead of, "In regards to cryptographic hashing,", I should have 
> stated in regards to cryptographic key validation. There are a few other 
> dubious clarifications or minor edits I should make in order to not draw 
> confusion. I will do a repo update today. Honest mistake, but enough with the 
> sarcasm.
> 
> Best regards, Andrew
> 
> On Sat, Mar 13, 2021, 3:13 AM em...@yancy.lol  wrote:
>> My email was not intended as an insult.  Your proposal seemed a bit like 
>> gibberish and made some obvious mistakes as pointed out before (such as 
>> conflating secp256k1 with sha256), and so I was genuinely curious if you 
>> were a bot spamming the list.
>>  
>> Maybe a more interesting topic is, can GPT3 be used to generate a BIP?  How 
>> long before our AI overlord produces improvements to Bitcoin?  At what point 
>> will the AI have more than 51% of commit frequency?  Will we have lost the 
>> war to our new centralized overlord?
>> 
>> Cheers,
>> -Yancy
>> 
>> 
>> On Saturday, March 13, 2021 00:31 CET, Lonero Foundation 
>>  wrote:
>>  
>>> Also, I already stated I was referring to signature validation cryptography 
>>> in that aspect: 
>>> https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-book/content/digital-signatures/ecdsa-sign-verify-examples.html
>>> My BIP has a primary purpose in regards to what I want to develop proofs 
>>> for and the different cryptographic elements I want to develop proofs for.
>>> That said to those who disagree with the premise, I do prefer constructive 
>>> feedback over insults or making fun of one another. After all this is an 
>>> improvement proposal with a specific purpose aiming to develop a specific 
>>> thing, not a guy who is just wanting to copy and paste a repository and 
>>> call it a day.
>>>  
>>> Best regards, Andrew
>>>  
>>> On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation 
>>>  wrote:
 Hi, I also want to emphasize that my main point isn't just to create a BTC 
 hardfork or become another Bitcoin Cash, Gold, or SV. The main point in 
 regards to this BIP actually expands POW rather than replaces or creates 
 an alternative. Many of the problems faced in regards to security in the 
 future as well as sustainability is something I believe lots of the 
 changes I am proposing can fix. In regards to technological 
 implementation, once this is assigned draft status I am more than willing 
 to create preprints explaining the cryptography, hashing algorithm 
 improvements, and consensus that I am working on. This is a highly 
 technologically complex idea that I am willing to "call my bluff on" and 
 expand upon. As for it being a draft, I think this is a good starting 
 point at least for draft status prior to working on technological 
 implementation.
  
 Best regards, Andrew
  
 On Fri, Mar 12, 2021 at 5:37 PM em...@yancy.lol  wrote:
> I think Andrew himself is an algo.  The crypto training set must not be 
> very good.
> 
> Cheers,
> -Yancy
> 
> On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev 
>  wrote:
>  
>> …
> 
> 
> 
>  
>> 
>> 
>> 
>>  
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev