Paul Iverson [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-28 to 2017-12-23
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:08:59

- reply

📅 Original date posted:2017-12-21
📝 Original message:I agree with Greg. What is happening is a cause for celebration: it is the
manifestation of our long-desired fee market in action. That people are
willing to pay upwards of $100 per transaction shows the huge demand to
transact on the world's most secure ledger. This is what success looks
like, folks!
Now that BTC is being phased out as a means of payment nearly everywhere
(e.g., Steam dropping BTC as a payment option) (to be replaced with the
more-suitable LN when ready), I'd propose that we address the stuck
transaction issue by making replace-by-fee (RBF) ubiquitous. Why not make
every transaction RBF by default, and then encourage via outreach and
education other wallet developers to do the same?
The frustration with BTC today is less so the high-fees (people realize
on-chain transactions in a secure decentralized ledger are necessarily
costly) but by the feeling of helplessness when their transaction is
stuck. Being able to easily bump a transaction's fee for users who are in
a hurry would go a long way to improving the user experience.
Paul.
On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Personally, I'm pulling out the champaign that market behaviour is
> indeed producing activity levels that can pay for security without
> inflation, and also producing fee paying backlogs needed to stabilize
> consensus progress as the subsidy declines.
>
> I'd also personally prefer to pay lower fees-- current levels even
> challenge my old comparison with wire transfer costs-- but we should
> look most strongly at difficult to forge market signals rather than
> just claims-- segwit usage gives us a pretty good indicator since most
> users would get a 50-70% fee reduction without even considering the
> second order effects from increased capacity.
>
> As Jameson Lopp notes, more can be done for education though-- perhaps
> that market signal isn't efficient yet. But we should get it there.
>
> But even independently of segwit we can also look at other inefficient
> transaction styles: uncompressed keys, unconfirmed chaining instead of
> send many batching, fee overpayment, etc... and the message there is
> similar.
>
> I've also seen some evidence that a portion of the current high rate
> congestion is contrived traffic. To the extent that it's true there
> also should be some relief there soon as the funding for that runs
> out, in addition to expected traffic patterns, difficulty changes,
> etc.
>
>
> On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I asked adam back at hcpp how the block chain would be secured in the
> long
> > term, once the reward goes away. The base idea has always been that fees
> > would replace the block reward.
> >
> > At that time fees were approximately 10% of the block reward, but have
> now
> > reached 45%, with 50% potentially being crossed soon
> >
> > https://fork.lol/reward/feepct
> >
> > While this bodes well for the long term security of the coin, I think
> there
> > is some legitimate concern that the fee per tx is prohibitive for some
> use
> > cases, at this point in the adoption curve.
> >
> > Observations of segwit adoption show around 10% at this point
> >
> > http://segwit.party/charts/
> >
> > Watching the mempool shows that the congestion is at a peak, though it's
> > quite possible this will come down over the long weekend. I wonder if
> this
> > is of concern to some.
> >
> > https://dedi.jochen-hoenicke.de/queue/more/#24h
> >
> > I thought these data points may be of interest and are mainly FYI.
> Though
> > if further discussion is deemed appropriate, it would be interesting to
> hear
> > thoughts.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> 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/20171221/57708e63/attachment.html>

2023-06-07 18:08:21

- reply

📅 Original date posted:2017-12-23
📝 Original message:Allowing a "no-RBF" flag serves only to fool new users into believing that
0-conf is more secure than it is. There is already too much confusion about
this point.
In Bitcoin was assume that miners are profit-maximizing agents, and so we
must assume that (flag or not) miners will replace transactions from
mempool with conflicts paying a higher fee. From that viewpoint, full RBF
is already "de facto" policy in Bitcoin. So I agree with Luke and Peter:
remove the flag and make all transactions RBF as "de jure" policy too.
At the same time, we need more outreach and education to clarify the risks
of 0-conf, and we need to show miners how they can earn more profits by
adopting full RBF.
Paul.
On Sat, Dec 23, 2017 at 8:25 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> While the usability of non-RBF transactions tends to be quite poor, there
> are some legitimate risk-analysis-based reasons why people use them (eg to
> sell BTC based on a incoming transaction which you will need to convert to
> fiat, which has low cost if the transaction doesn't confirm), and if people
> want to overpay on fees to do so, no reason not to let them, including if
> the merchant is willing to CPFP to do so.
>
> Honestly, I anticipate very low usage of such a flag, which is
> appropriate, but also strongly support including it. If things turn out
> differently with merchants reducing the usability of BTC without taking
> over the CPFP responsibility we could make the option imply
> receiver-pays-fee, but no reason to overcomplicate it yet.
>
> On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev wrote:
>>
>>> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:
>>>
>>>> I recently submitted a pull request that would turn on RBF by default,
>>>> which triggered some discussion [2]. To ease the transition for merchants
>>>> who are reluctant to see their customers use RBF, Matt Corallo suggested
>>>> that wallets honor a no125=1 flag.
>>>>
>>>> So a BIP-21 URI would look like this:
>>>> bitcoin:175t...45W?amount=20.3&no125=1
>>>>
>>>> When this flag is set, wallets should not use RBF, regardless of their
>>>> default, unless the user explicitly overrides the merchant's preference.
>>>>
>>>
>>> This seems counterproductive. There is no reason to ever avoid the RBF flag.
>>> I'm not aware of any evidence it even reduces risk of, and it certainly
>>> doesn't prevent double spending. Plenty of miners allow RBF regardless of the
>>> flag, and malicious double spending doesn't benefit much from RBF in any case.
>>>
>>
>> I'll second the objection to a no-RBF flag.
>>
>>
> _______________________________________________
> 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/20171223/5d90c5a8/attachment.html>

2023-06-07 17:58:13

- reply

📅 Original date posted:2017-03-28
📝 Original message:Thank you for the proposal Wang Chung!
It is clear that, spam aside, blocks are getting full and we need increase
them soon. What I don't like about your proposal is it forces all node
operators to implicitly accept larger blocks in 2020, even maybe against
their will. 32 MB blocks might result in a loss of decentralization, and it
might be too difficult to coordinate for small blocks before it's too late.
So I think Core can't decide on hard forks like this. It must be left up to
the users. I think only choice is for Core to add a run-time option to
allow node operators to increase block size limit, so that this very
controversial decision is not coming from Core. It must come from the
community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/df218008/attachment-0001.html>