On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> > If someone's going to systematically exploit your store via this
> > mechanism, it seems like they'd just find a single wallet with a good
> > UX for opt-in RBF and lowballing fees, and go to town -- not something
Hello list,
Given that the release of 24.0 is upon us and there is little time to make a
complex decision regarding the deployment method of full-RBF, we've
documented
the different alternatives and their trade-offs. I hope this helps get to
the
best possible deployment!
Gist:
> If it were growing in line with lightning capacity in BTC, per
bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
getting from 15% to 80% would then be about 8 years.
I'd caution against any metrics-based
On Wed, Oct 19, 2022 at 03:17:51AM +, alicexbt via bitcoin-dev wrote:
> > And the
> > impression I got from the PR review club discussion more seemed like
> > devs making assumptions about businesses rather than having talked to
> > them (eg "[I] think there are fewer and fewer businesses who
On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev wrote:
> Hello fellow Bitcoiners,
>
> After looking at some fairly exotic possible transaction types, I ran into
> the current policy limit requiring transactions to be 85 non-witness
> serialized bytes. This was introduced as
On Thu, Oct 20, 2022 at 08:07:54PM -0400, Greg Sanders wrote:
> I don't doubt the use case(it's why I opened the issue!). I didn't want the
> proposal to die in case people found it odd that 61, 62, 63, but not 64
> bytes ended up being broadcast able.
>
> Perhaps this is not an issue, especially
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
>
On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
bitcoin-dev wrote:
AJ previously wrote:
> presumably that makes your bitcoin
> payments break down as something like:
>5% txs are on-chain and seem shady and are excluded
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
There is obviously an alternative approach to the issue.
If we like opt-in RBF and would like to keep opt out RBF 0CONF working, we
could add another option to punish those nodes that replace transactions. That
is, a miner that publishes a block with a NO RBF, that is replaced (that is
easy to
On Tue, Oct 18, 2022 at 05:00:45PM +1000, Anthony Towns via bitcoin-dev wrote:
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or
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
On Tue, Oct 18, 2022 at 10:30:26AM -0400, Russell O'Connor via bitcoin-dev
wrote:
> It is most certainly the case that one can construct situations where not
> mining on the tip is going to be the prefered strategy. But even if that
> happens on occasion, it's not like the protocol immediately
On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > If someone's going to systematically exploit your store via this
> > > mechanism, it seems like they'd just find a single wallet
On Mon, Oct 17, 2022 at 08:23:20AM +0200, John Carvalho via bitcoin-dev wrote:
> Simply, 0conf acceptance can be monitored and enforced by the merchant and
> exposure to doublespends can be both mitigated and limited in size per
> block. It is less expensive to be double-spent occasionally than to
On Sun, Oct 16, 2022 at 01:35:54PM -0400, 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
I don't doubt the use case(it's why I opened the issue!). I didn't want the
proposal to die in case people found it odd that 61, 62, 63, but not 64
bytes ended up being broadcast able.
Perhaps this is not an issue, especially since this isn't a consensus
change like the Great Consensus Cleanup.
Good morning Mark,
> The idea is simple: instead of requiring that the final parameter on the
> stack be zero, require instead that it be a minimally-encoded bitmap
> specifying which keys are used, or alternatively, which are not used and must
> therefore be skipped. Before attempting
On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),
You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At
So it doesn't look like I'm ignoring a good question:
No solid noninteractive ideas, unless we get some very flexible sighash
softfork. Interactively, I think you can get collaborative fee bumps under
the current consensus regime and ephemeral anchors. The child will just be
built with inputs
On Thu, 20 Oct 2022 at 03:37, Antoine Riard wrote:
> Hi Sergej,
>
> Thanks for the insightful posting, especially highlighting the FX risk
> which was far from being evident on my side!
>
> I don't know in details the security architecture of Bitrefill zeroconf
> acceptance system, though from
Hi,
There is a reasonable tradeoff one can make to get eventual settlement
assurance prior to confirmation: lock up the funds with a counterparty in a
2-of-2 multisig with a timelock back to the owner. As long as the timelock
has not expired and the recipients trust the counterparty not to sign
It's a good idea in theory, the issue is that most wallets and services
bitcoin users use today to send bitcoin don't use solutions to that. So we
end up with "you need to use X wallet to buy stuff", which is equivalent to
"you need to use a Lightning wallet to buy stuff"
On Thu, 20 Oct 2022 at
On Thu, 20 Oct 2022 at 09:22, Anthony Towns wrote:
> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > The
> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> > (it's actually quite easily managed),
>
> You mean "it's quite easily
24 matches
Mail list logo
