Why Nostr? What is Njump?
2023-06-07 15:37:02
in reply to

Loi Luu [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-09 📝 Original message:> > The proposed fix is to ...

📅 Original date posted:2015-06-09
📝 Original message:>
> The proposed fix is to add a new rule on how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this change,
> we can suggest the default fee per transaction to be doubled


I would propose another practical rule rather than burning 50% of the fee.
For example, you can
credit 50% of the transaction fee to the next block. Thus, the attacker
cannot perform
the attack with 0-fee any more, yet you don't have to double the price of
the TX fee for the fix.

Thanks,
Loi Luu.

On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <raystonn at hotmail.com> wrote:

> When implemented, the block size limit was put in place to prevent the
> potential for a massive block to be used as an attack to benefit the miner
> of that block. The theory goes that such a massive block would enrich its
> miner by delaying other miners who are now busy downloading and validating
> that huge block. The original miner of that large-block would be free to
> continue hashing the next block, giving it an advantage.
>
> Unfortunately, this block size limit opened a different attack. Prior to
> the limit, any attempt to spam the network by anyone other than someone
> mining their own transactions would have been economically unfeasible. As
> every transaction would have a fee, there would have been a real cost for
> every minute of spam. The end result would have been a transfer of wealth
> from spammer to Bitcoin miners, which would have harmed the spammers and
> encouraged further mining of Bitcoin, a very antifragile outcome.
>
> But now we have the block size limit. Things are very different with this
> feature in place. The beginning of a spam attack on the Bitcoin network
> will incur transaction fees, just like before. But if spam continues at a
> rate exceeding the block size limit long enough for transactions to be
> dropped from mempools, the vast majority of spam transaction fees will
> never
> have to be paid. In fact, as real users gain in desperation and pay higher
> fees to get their transactions through in a timely manner, the spammers
> will
> adjust their fees to minimize the cost of the attack and maximize
> effectiveness. Using this method, they keep their fees at a point that
> causes most of the spam transactions to be dropped without confirmation
> (free spam), while forcing a floor for transaction fees. Thus, while spam
> could be used by attackers to disable the network entirely, by paying
> high-enough fees to actually fill the blocks with spam, it can also be used
> by a single entity to force a transaction fee floor. Real users will be
> forced to pay a transaction fee higher than the majority of the spam to get
> their transactions confirmed. So this is an effective means for a minority
> of miners to force higher fees through spam attacks, even in the face of
> benevolent miners who would not support a higher fee floor by policy.
> Miners would simply have no way to fix this, as they can only put in the
> transactions that will fit under the block size limit.
>
> In the face of such a spam attack, Bitcoin's credibility and usability
> would
> be severely undermined. The block size limit enables this attack, and I
> now
> argue for its removal. But we can't just remove it and ignore the problem
> that it was intended to address. We need a new fix for the large-block
> problem described in the first paragraph that does not suffer from the
> dropped-transaction spam-attack problem that is enabled by the block size
> limit today. My proposal is likely to be controversial, and I'm very much
> open to hearing other better proposals.
>
> Large blocks created by a miner as a means to spam other miners out of
> competition is a problem because miners do not pay fees for their own
> transactions when they mine them. They collect the fees they pay. This
> breaks the economic barrier keeping people from spamming the network, as
> the
> spamming is essentially free. The proposed fix is to add a new rule on how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this change,
> we can suggest the default fee per transaction to be doubled. Half of
> every
> fee would be burned and disappear forever, effectively distributing the
> value of those bitcoins across the entire money supply. The other half
> would be collected by the miner of the block as is done today. This
> solution would mean large blocks would cost a significant number of bitcoin
> to create, even when all of the transactions are created by the miner of
> that block. For this to work, we'd need to ensure a minimum fee is paid
> for
> most of the transactions in every block, and the new transaction fee rule
> is
> in place. Then the block size limit can be removed.
>
> Raystonn
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/3947db5f/attachment.html>;
Author Public Key
npub1sfcfe78cjz6225gcewalfpc3sh3rygzjmuzp2y6phghj4ec5zwrs8xh35z