Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-01 📝 Original message:There has never been any ...
📅 Original date posted:2022-12-01
📝 Original message: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 if
full rbf is present.
This means:
- managing risk
- waiting for confirmations if the risk is too high
- using lightning if possible
No other coin or chain offers a safer way to do business than lightning
over bitcoin.
On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto transactions, BTC is a primary part of our business. Our guarantee
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainnet.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be fully
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> 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 cumulative value of 2.3B USD value.
> 3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf. I realise there are other
> considerations which BTC has, I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221201/cc56e561/attachment.html>;
📝 Original message: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 if
full rbf is present.
This means:
- managing risk
- waiting for confirmations if the risk is too high
- using lightning if possible
No other coin or chain offers a safer way to do business than lightning
over bitcoin.
On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto transactions, BTC is a primary part of our business. Our guarantee
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainnet.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be fully
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> 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 cumulative value of 2.3B USD value.
> 3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf. I realise there are other
> considerations which BTC has, I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221201/cc56e561/attachment.html>;