I agree with Peter, it seems like we don't need a dust limit with full
blocks. And we should expect blocks to remain full indefinitely.
However, if we were to still have a dust limit, it shouldn't be a simple
constant. It should be determined by the mempool environment. Eg one could
define the dus
Thank you for answering. I'll check out the link you provided, while also
playing around with the fee settings for my own full node, at my home
server.
On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> It is possible, because you can find nodes
It is possible, because you can find nodes that accept low-fee transactions.
And on some statistics, for example
https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero to one
satoshi per virtual byte transactions could take more space than other
transactions. You can be convin
So, can we conclude by something, whether or not it would be possible and
feasible in the future?
On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Aug 01, 2022 at 01:19:05PM +, aliashraf.btc At protonmail
> wrote:
> > > On Sat,
On Mon, Aug 01, 2022 at 01:19:05PM +, aliashraf.btc At protonmail wrote:
> > On Sat, Jul 30, 2022 at 05:24:35PM +, alicexbt via bitcoin-dev wrote:
> > like a hashcash-based alternative broadcast scheme.
> Hi Peter,
> I've been mulling the idea of attaching work to low fee txns, both as a
>
> On Sat, Jul 30, 2022 at 05:24:35PM +, alicexbt via bitcoin-dev wrote:
> like a hashcash-based alternative broadcast scheme.
Hi Peter,
I've been mulling the idea of attaching work to low fee txns, both as a
compensation (e.g., in a sidechain, or an alt), and/or as a spam proof.
Unfortunately
On Sat, Jul 30, 2022 at 05:24:35PM +, alicexbt via bitcoin-dev wrote:
> However, I think developers should not make any changes in the default
> minimum fee rate required for relay. If there are incentives for users and
> miners to change it, they should use non-default value. In case, miners
Hi Aaradhya,
> I discussed this on the Bitcoin subreddit and some suggested that the
> developers, in the future, have to just change the "default minimum relay tx
> fee" from 1000 today to 500 at that time.
>
There are several issues and pull requests (open and closed) in which
developers tr
On Thu, Jul 28, 2022 at 05:38:19PM -1000, David A. Harding wrote:
> I think the phrasing by Aaradhya Chauhan and Peter Todd above are conflating
> the minimum output amount policy ("dust limit") with the minimum transaction
> relay feerate policy ("min tx relay fee"). Any transaction with an outpu
I'm not suggesting to initiate it anytime soon. But suppose, let's take a
situation where Bitcoin reaches and oscillates above 200k to 500k USD, then
1 sat/vB could be equivalent to 10 sat/vB of today, hampering the "dust
requirement" (ignoring inflation). I discussed this on the Bitcoin
subreddit
I think you misunderstood what I said. I did not say that it should be done
now, for the obvious reasons that the miners won't be doing any good by
such measures. But I am talking about when the price of BTC escalates to a
point when 1sat/vB becomes expensive as a dust limit. If the price
oscillate
On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
bitcoin-dev wrote:
[...] in its early days, 1 sat/vB was a good dust protection
measure. But now, I think it's a bit high [...] I think it can be done
easily [...]
[...] lower
> It's pointless for individual nodes to make changes like this on their own.
It's pointless only if you assume that mining is centralized. And it's
pointless if you also assume that there is no batching. By using different
sighashes, batching is definitely possible. In case of one-input-one-out
On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev
wrote:
>> So I'd suggest removing the fixed dust limit entirely and relying purely on
>> the mempool size limit to determine what is or is not dust.
>
>Just use those settings in your node:
>
>minrelaytxfee=0.
>blockmintxfe
> So I'd suggest removing the fixed dust limit entirely and relying purely on
> the mempool size limit to determine what is or is not dust.
Just use those settings in your node:
minrelaytxfee=0.
blockmintxfee=0.
dustrelayfee=0.
No changes in source code are needed, nodes
Hi Peter,
> But to a first approximation, at any fee above zero failing to mine a tx you
> know about is leaving money on the table
Let's assume 1 people go from A to B every day in flight. They buy tickets
for different prices and some of them are looking to pay the minimum even if
it's a
On July 26, 2022 2:19:32 PM GMT+02:00, alicexbt via bitcoin-dev
wrote:
>Hi Aaradhya,
>
>> As it's not a consensus rule, I think it can be done easily, just needing
>> support from full node operators
>
>A few miners will need to use a lower minrelaytxfee for this to work. I don't
>think mine
On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev
wrote:
> I know this might be a sort of repetition for a previous question, but I do
> want to know from enthusiasts in this group that while Bitcoin was trading
> at much lower price in its early days, 1 sat/vB was a good
Hi Aaradhya,
> As it's not a consensus rule, I think it can be done easily, just needing
> support from full node operators
A few miners will need to use a lower minrelaytxfee for this to work. I don't
think miners would want to lower their profits.
/dev/fd0
Sent with [Proton Mail](https://pr
I know this might be a sort of repetition for a previous question, but I do
want to know from enthusiasts in this group that while Bitcoin was trading
at much lower price in its early days, 1 sat/vB was a good dust protection
measure. But now, I think it's a bit high for merely a dust protection
me
20 matches
Mail list logo
