On Sat, Feb 4, 2023 at 6:28 PM Peter Todd wrote:
> On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:
> > We have standard commercial information about the payment processors, non
> > custodial liquidity providers and merchants which become our clients - we
> > do not have any kyc/a
On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:
> We have standard commercial information about the payment processors, non
> custodial liquidity providers and merchants which become our clients - we
> do not have any kyc/aml information or telephone number on who is sending
> our
> 0-conf on Bitcoin with its understood risks is a significant use case
and that use case doesn't change, at all, with full rbf. the risk profile
will, likely, remain the same. observation of the fee paid, history of
doing business with the customer, transaction size are all needed.
On Mon, J
> > 0-conf on Bitcoin with its understood risks is a significant use case
>
> and that use case doesn't change, at all, with full rbf. the risk
> profile will, likely, remain the same. observation of the fee paid,
> history of doing business with the customer, transaction size are all
> needed.
Some further clarity on our unique trx hashes queried to our platform, our
initial and followup numbers on unique trx hashes queried were not accurate
- apologies. Bitcoin addresses queried and Usd value and unique were
accurate. This is as a result of our platform viewing each queried bitcoin
addr
On Sat, Jan 14, 2023 at 1:53 AM Peter Todd wrote:
> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
> > GAP600 is not a trxs processor or liquidity provider we service
> merchants,
> > payment processors & non-custodial liquidity providers - our service is
> > purely the 0-conf e
On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
> GAP600 is not a trxs processor or liquidity provider we service merchants,
> payment processors & non-custodial liquidity providers - our service is
> purely the 0-conf enabling our clients to accept 0-conf. Clients access our
> ser
GAP600 is not a trxs processor or liquidity provider we service merchants,
payment processors & non-custodial liquidity providers - our service is
purely the 0-conf enabling our clients to accept 0-conf. Clients access our
service via API - sending us the Trx hash & output address. Our service is
n
NACK
support for 0-conf is harmful for reasons already stated ad nauseum
On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> A 0-conf double spend caused by FSS-RBF would be harmless since the
> original output (address and amounts)
On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:
> > With multi-party transactions such as coinjoins and multi-party lightning
> > channels, we want full-rbf behavior because it avoids accidental
> > double-spends
> > holding up progress in these protocols.
>
> what is meant by acc
A 0-conf double spend caused by FSS-RBF would be harmless since the
original output (address and amounts) remain in the double spending trx.
So all a merchant would need to do is monitor block inclusion for the
relevant output. Addition of some wallet logic would resolve it easily.
Technically t
On Tue, 13 Dec 2022 at 23:41 Peter Todd wrote:
> On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> > I dont think there was anything technical with the implementation and as
> > far as I can tell this is well developed and ready.
>
> There are lots of problems with my first-seen-
On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> I dont think there was anything technical with the implementation and as
> far as I can tell this is well developed and ready.
There are lots of problems with my first-seen-safe proposal. The only reason I
proposed it in 2015 was a
This would not effect optinrbf only fullRBF
On Tue, 13 Dec 2022 at 16:00 Lucas Ontivero wrote:
> Some wallets like Electrum would be affected by that because they use RBF
> to batch transactions so, outputs cannot be exactly the same as before.
>
> On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshit
Some wallets like Electrum would be affected by that because they use RBF
to batch transactions so, outputs cannot be exactly the same as before.
On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I dont think there was anything tech
I dont think there was anything technical with the implementation and as
far as I can tell this is well developed and ready.
The reasons I can find for not being adopted are listed here -
https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe
Replace-by-fee
Those reasons do no
Why wasn't this solution put in place back then? Are there problems with
the design?
While I still think there are unhealthy side-effects of Full-RBF (like more
doublespending at unknowing merchants, after years of FSS protection) I
think discussion of this FSS-RBF feature is worth considering.
-
Thank you for bringing that to my attention, apologies for not being aware
of it.
First-seen-safe replace-by-fee as detailed here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
by Peter Todd seems to be a very suitable option and route which balances
FullRBF while re
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Intro
Currently there is a significant use case of 0-Conf acceptance of
transactions. Merchants and service providers are fully aware of the risks
related to 0-conf. Full RBF if it would be significantly enabled would most
likely make 0-conf not possible and significantly limit this current use
cas
20 matches
Mail list logo
