On Fri, Dec 09, 2022 at 03:58:37PM +, angus via bitcoin-dev wrote:
> Those in favour of Full RBF see trusting and relying on predictable
> mempool policy as a fundamentally flawed bad idea.
I don't believe that claim is true, at least in general: the motivation
for the -mempoolfullrbf PR was
Zman,
Price Theory simply explains the relationship between supply & demand. Your
post makes some logical leaps in that you are implying that demand follows
supply, which of course is not true, nor is that a claim of Price Theory.
If Bitcoin has less utility, it will have less demand, regardless
Good morning John, et al,
> > As has been pointed out by may others before, full RBF is aligned with
> > miner (and user) economic incentives
>
>
> This is a theory, not a fact. I can refute this theory by pointing out
> several aspects:
> 1. RBF is actually a fee-minimization feature that
>
>
>
> Many zero-conf proponents work on the bleeding edge of supporting
> Lightning, including myself. Lightning is not risk-free and the base layer
> should not be assuming it as a primary dependency for commercial payments.
>
for low-value payments, lightning is the only workable version
>
> The perception seems to be that Core adding the full RBF option is
> increasing the risk to zero-conf users, but I'm not convinced that that is
> the case.
If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.
It's always been the risk of getting
See below feedback from CEO of Coinspaid Re - Bitcoin Zero conf market value
Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz
-- Forwarded message -
From: Max Krupyshev
Date: Sat,
Can also set you up with a trial account - interface is via API - just let
me know which email you wish for me to use and I will send over an
activation link which is active for 24 hours.
Happy to do it for other members list as well.
On Sat, 3 Dec 2022 at 13:01 Daniel Lipshitz wrote:
>
Shapeshift used to be clients in fact one of our first when we started in
2016.
They no longer use our service but from time to time use us for fee
recommendations. So we actually should remove their logo as a current
client.
If you wish to test it out try find a merchant using Coinpayments or
On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
> Yes I can see how that is not clear, apologies.
>
> Just BTC.
> From Jan1 2022 up till end of November 2022 GAP600 has processed circa 15M
> trxs. With a value of 2.3B USD.
> In 2021 we did - circa 12.5M.
> In 2020 we did circa
HI Antoine
Thank you for all the references - I agree with Sergej
statement "opportunity makes the thief"
The 1.5M trxs are all BTC which our clients query, I dont have specifics
for those trxs i.e. reasons for not being confirmed. However we target to
achieve +90% confirmation of trxs for our
Yes I can see how that is not clear, apologies.
Just BTC.
>From Jan1 2022 up till end of November 2022 GAP600 has processed circa 15M
trxs. With a value of 2.3B USD.
In 2021 we did - circa 12.5M.
In 2020 we did circa 6.5M.
We have been in production since 2016 and working on the project since
Hi Daniel,
>From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the
If fullRBF would become default and this would become dominant, zero-conf
acceptance would become extremely difficult and would impact significantly
this market share because its not the everyday users who would actually
worry about it however the attackers would be all over it.
As it is today
On Thu, Dec 01, 2022 at 02:27:16PM +0200, Daniel Lipshitz via bitcoin-dev wrote:
> Statistics for consideration as a sample of the zero conf use case -
>
>
>1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>15M transactions
>2. These transactions have a
There has never been any enforcement of miner preferences. The convention
is changing quickly, since miners are squeezed for cash and want to
capture every nickel, plus there are bounties for full rbf being posted
every day.
I would suggest considering to continue doing business, as usual, as
Good morning ArmchairCryptologist,
> --- Original Message ---
> On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > I mean, if you think the feedback is wrong, that's different: maybe we
> > shouldn't care that
--- Original Message ---
On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev
wrote:
> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that
--- Original Message ---
On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev
wrote:
> 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
On Fri, 21 Oct 2022 at 21:43, Peter Todd wrote:
> On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > On Thu, 20 Oct 2022 at 23:07, Greg Sanders wrote:
> >
> > > A large number of coins/users sit on custodial rails and this would
> > > essentially encumber
There are many countermeasures that can be done, we've only implemented a
subset of them as more haven't been needed.
Mainly we wait some time to make sure any conflicting transaction has time
to propagate on the network. We have well connected nodes with basic
redundancy.
When they are available
Hi Dave,
> One way to address this risk is by turning it into a certainty. If the
price of BTC increases between when the invoice is generated and when a
transaction is included in a block, give the customer a future purchase
credit equal in value to the difference between the price they paid
On 2022-10-19 04:29, 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), it's FX risk as the merchant must
commit to a certain BTCUSD rate ahead of time for a purchase. Over
time some transactions
On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> On Thu, 20 Oct 2022 at 23:07, Greg Sanders wrote:
>
> > A large number of coins/users sit on custodial rails and this would
> > essentially encumber protocol developers to those KYC/AML institutions. If
> > Binance
On Thu, Oct 20, 2022 at 12:05:33AM -0400, Peter Todd wrote:
> ...and I checked this with Electrum on Android, which has a handy "Cancel
> Transaction" feature in the UI to easily cancel a payment. Which I did. You
> should have a pending payment from this email, and unsurprisingly I don't have
>
On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
> This is factually incorrect and not required for us to do what we do.
So how do you detect people sending conflicting transactions?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
On Fri, 21 Oct 2022 at 16:01, Greg Sanders wrote:
> Full-rbf is an odd duck, because while it is not a consensus issue, it
> does affect a large % of transactions made by wallets already, contrary to
> most policy changes.
>
Yeah, there are several policy features that are not consensus related
> Yeah, there are several policy features that are not consensus related
but end up de facto setting rules for how bitcoin behaves.
Yes, it's status quo so wallets "just know" not to do them. The fact that
the status quo would be changing is important, in that it may degrade UX
for 0-conf
Full-rbf is an odd duck, because while it is not a consensus issue, it does
affect a large % of transactions made by wallets already, contrary to most
policy changes. We have a status quo that is understandable, but
unfortunately long-term incentive incompatible.
It's also a UX issue, not a
On Thu, 20 Oct 2022 at 23:07, Greg Sanders wrote:
> A large number of coins/users sit on custodial rails and this would
> essentially encumber protocol developers to those KYC/AML institutions. If
> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> should this be an issue
On Thu, 20 Oct 2022 at 21:58, Anthony Towns wrote:
> So, what I'm hearing is:
>
> * lightning works great, but is still pretty small
> * zeroconf works great for txs that opt-out of RBF
> * opt-in RBF is a pain for two reasons:
> - people don't like that it's not treated as zeroconf
>
This is factually incorrect and not required for us to do what we do.
On Fri, 21 Oct 2022 at 00:13, Peter Todd wrote:
> 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:
> > > >
> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these
and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could
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
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 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
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
> 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 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
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
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
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
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
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
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
On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as default
> policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even
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 what I suppose there is at least a set of
full-nodes
Another downside is that the sender may not opt into a non-pinnable future
format like "V3 transactions", making CPFP difficult. They may spend a lot
of fees to do this however, so maybe we're really reaching here.
On Wed, Oct 19, 2022 at 12:07 PM Sergej Kotliar via bitcoin-dev <
It's an interesting idea, presumably it would work w the new package relay.
Scorched earth bidding war is definitely fine to deter this type of abuse.
Need to consider it more thoroughly from all sides tho. CPFP on the server
side generally has a couple of downsides:
* Requires a hot wallet to
Isn't the extreme of this that the merchant tries to lock in gains on the
upswing via CPFP, and users on the downswing, both doing scorched earth,
tossing the delta to fees?
Seems like a MAD situation?
On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <
If they do this to you, and the delta is substantial, can't you sweep all
such abusers with a cpfp transaction replacing their package and giving you
the original txn?
On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
>
> Currently Lightning is somewhere around 15% of our total bitcoin
payments. This is very much not nothing, and all of us here want Lightning
to grow, but I think it warrants a serious discussion on whether we want
Lightning adoption to go to 100% by means of disabling on-chain commerce.
Is this
Hi all,
Chiming in on this thread as I feel like the real dangers of RBF as default
policy aren't sufficiently elaborated here. It's not only about the
zero-conf (I'll get to that) but there is an even bigger danger called the
american call option, which risks endangering the entirety of BIP21
Hi aj,
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
Yes, this
On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> > 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > payments indefinitely
> > 2) Draw a line in the sand now, but give people who are currently
> > accepting unconfirmed txs time to
Hi John,
I hear your worry about RBF issuing concerns for 0conf acceptance
merchants. I don't think it has been denied in the first communication of
this opt-in rbf proposal back in June. Merchants/0confs builders have been
invited to bring voices to the surface at that time [0]. So this new
Hi AJ,
> 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> payments indefinitely
>
> 2) Draw a line in the sand now, but give people who are currently
> accepting unconfirmed txs time to update their software and business
> model
>
> 3) Encourage mainnet
Hi Dario,
Sorry for the latency in reply to the reaction about the full-rbf setting
I've initially pushed in 0.24, TABConf week has been a busy one.
>From my understanding, there is no disagreement from Muun wallet about the
gradual deployment of full-rbf by Bitcoin Core nodes, this is more a
AJ,
Thanks for the latest PR and discussion, even if we know we're all (very,
very, very) tired of it running almost 10 years now. I think we're close to
a resolution, (2), or (3) as you note.
As ariard notes in
https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we
seem to
On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev wrote:
> On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev wrote:
> > In my view, it is just what I said: a step towards getting full RBF
> > on the network, by allowing experimentation and socializing
Peter,
Your argument is totally hypocritical and loses when comparing quantities.
Enforcing RBF is observably more "harmful to Bitcoin" (whatever that
means...) when it tries to "risk-manage propagation" of replacements, as
there more Bitcoiners that want to mutually utilize 0conf than users
Erik, I am fully aware of Lightning and have a been a proponent and builder
of it since it was launched, including getting Bitfinex to support LN,
building a RN LDK implementation in our upcoming app, etc, but frankly LN
has nowhere near the adoption of onchain payments for commerce, and LN
Also, lightning works fine and is readily available in convenient mobile
apps used by millions of people, or in . So the need for a 0conf has been
mitigated by other solutions for fast payments with no need for a trust
relationship. And for people that don't like mobile risks, core lightning
On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev wrote:
> In support of Dario's concern, I feel like there is a degree of gaslighting
> happening with the advancement of RBF somehow being okay, while merchants
> wanting to manage their own 0conf risk better being not okay.
On Fri, Oct 14, 2022 at 02:44:04AM +, alicexbt via bitcoin-dev wrote:
> > Relay of fullrbf transactions works reasonable well
> > already, unless you get unlucky with your selected peers. The only
> > missing piece is a few percent of hashrate that will accept fullrbf
> > replacement
In support of Dario's concern, I feel like there is a degree of gaslighting
happening with the advancement of RBF somehow being okay, while merchants
wanting to manage their own 0conf risk better being not okay.
The argument against 0conf acceptance seems to be "miners can facilitate
doublespends
Hi cndm1,
> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
>
> - Bitrefill's on-chain payments for gift cards and phone top-ups
Bitrefill already supports lightning, so for them it would be easy to
solve by displaying the lightning transfer by default and only show
the on-chain payment as a fallback. Currently the on-chain payment at
Bitrefill and other
On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev wrote:
> In my view, it is just what I said: a step towards getting full RBF
> on the network, by allowing experimentation and socializing the notion
> that developers believe it is time.
We "believe it is time" for what
Hello Pieter,
Thanks for taking the time to comment! I'll answer inline.
On Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille
wrote:
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network.
That is
> presumably
On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns
wrote:
> On Tue, Oct 11, 2022 at 04:18:10PM +, Pieter Wuille via bitcoin-dev wrote:
>
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev
> > bitcoin-dev@lists.linuxfoundation.org wrote:
> >
> > >
On Tue, Oct 11, 2022 at 04:18:10PM +, Pieter Wuille via bitcoin-dev wrote:
> On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev
> wrote:
> > Thanks for the fast answer! It seems I missed the link to the PR, sorry for
> > the
> > confusion. I'm referring to the
On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev
wrote:
> Hello David,
>
> Thanks for the fast answer! It seems I missed the link to the PR, sorry for
> the
> confusion. I'm referring to the opt-in flag for full-RBF from #25353
>
Hi Dario,
There aren't any risks with latest release of bitcoin core. However its not
just munn or other things mentioned, even other bitcoin projects could be
affected if [#25600][1] is merged.
Anyway I cannot comment anymore, neither in the PR or repository. I tried my
best. Peter Todd has
Hello David,
Thanks for the fast answer! It seems I missed the link to the PR, sorry for
the
confusion. I'm referring to the opt-in flag for full-RBF from #25353
(https://github.com/bitcoin/bitcoin/pull/25353).
On Fri, Oct 7, 2022 at 2:21 PM David A. Harding wrote:
> On 2022-10-07 06:20, Dario
On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote:
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to the new policies.
Policies are a per-node decision, and cannot
David, Dario,
The only other effort I'm aware of is
https://github.com/bitcoin/bitcoin/pull/25600 , which as you can see, has
no consensus yet, isn't in 24.0, so at earliest would be 25.0, even if
somehow immediate resolution to the discussions were found.
Cheers,
Greg
On Fri, Oct 7, 2022 at
On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
Hello list,
I'm Dario, from Muun wallet [...] we've been reviewing the latest
bitcoin core release
candidate [...] we understood we had at least a year from the initial
opt-in deployment until opt-out was deployed, giving us
78 matches
Mail list logo
