Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-26 📝 Original message:On Fri, Jun 26, 2015 at ...
📅 Original date posted:2015-06-26
📝 Original message:On Fri, Jun 26, 2015 at 08:18:07PM +0100, Ross Nicoll wrote:
> I'd argue that at the point where there's consistently more
> transactions than the network can handle, there are two significant
> risks. Firstly, that people don't care enough to pay the transaction
> fees required to get their transaction prioritised over another's,
> and secondly that as transactions start outright failing (which will
> happen with enough transactions backlogged) the network is
> considered unreliable, the currency illiquid, and there's a virtual
> "bank rush" to get into a more usable currency.
The supply and demand fee market means that there is a range of
reliability levels depending on what fee you pay; regardless of how high
demand is if you pay a sufficiently high fee that outbids less
important/lower fee transactions you'll get reliable transaction
confirmaiton.
The perceived lack of reliability is a function of the poor state of
wallet software, not an inherent problem with the system. Fixing that
software is much easier and much less risky than any hard-fork ever will
be.
From my article on transaction fees during the CoinWallet.eu flood:
What needs to be done
=====================
Transaction fees aren't going away, blocksize increase or not. CoinWallet.eu is
only spending $5k flooding the network; even an 8MB blocksize increase can only
raise the cost of that attack to $40k, which is still very affordable. For
instance an attacker looking to manipulate the Bitcoin price could probably
afford to spend $40k doing it with the right trading strategy; let alone
governments, banks, big businesses, criminal enterprises, etc. to whom $40k is
chump-change. Wallets need to become smarter about fees, as does the rest of
the Bitcoin community.
What we need to do:
* Add fee/KB displays to block explorers.
* Change wallets to calculate and set fees in fee/KB rather than fixed fees regardless of tx size.
* Make websites with easy to understand displays of what the current mempool
backlog is, and what fee/KB is needed to get to the front of the queue. We've
done a great job for Bitcoin price charts, let's extend that to transaction
fees.
* Add the ability to set any fee/KB to wallets, rather than be stuck with
predefined options that may not be high enough.
* Add support for fee-bumping via (FSS)-RBF to wallets and Bitcoin Core.
Capacity limits are just a fact of life in the design of the Bitcoin protocol,
but that doesn't mean we can't give users the tools to deal with them
intelligently.
-https://gist.github.com/petertodd/8e87c782bdf342ef18fb
--
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/60768123/attachment.sig>;
📝 Original message:On Fri, Jun 26, 2015 at 08:18:07PM +0100, Ross Nicoll wrote:
> I'd argue that at the point where there's consistently more
> transactions than the network can handle, there are two significant
> risks. Firstly, that people don't care enough to pay the transaction
> fees required to get their transaction prioritised over another's,
> and secondly that as transactions start outright failing (which will
> happen with enough transactions backlogged) the network is
> considered unreliable, the currency illiquid, and there's a virtual
> "bank rush" to get into a more usable currency.
The supply and demand fee market means that there is a range of
reliability levels depending on what fee you pay; regardless of how high
demand is if you pay a sufficiently high fee that outbids less
important/lower fee transactions you'll get reliable transaction
confirmaiton.
The perceived lack of reliability is a function of the poor state of
wallet software, not an inherent problem with the system. Fixing that
software is much easier and much less risky than any hard-fork ever will
be.
From my article on transaction fees during the CoinWallet.eu flood:
What needs to be done
=====================
Transaction fees aren't going away, blocksize increase or not. CoinWallet.eu is
only spending $5k flooding the network; even an 8MB blocksize increase can only
raise the cost of that attack to $40k, which is still very affordable. For
instance an attacker looking to manipulate the Bitcoin price could probably
afford to spend $40k doing it with the right trading strategy; let alone
governments, banks, big businesses, criminal enterprises, etc. to whom $40k is
chump-change. Wallets need to become smarter about fees, as does the rest of
the Bitcoin community.
What we need to do:
* Add fee/KB displays to block explorers.
* Change wallets to calculate and set fees in fee/KB rather than fixed fees regardless of tx size.
* Make websites with easy to understand displays of what the current mempool
backlog is, and what fee/KB is needed to get to the front of the queue. We've
done a great job for Bitcoin price charts, let's extend that to transaction
fees.
* Add the ability to set any fee/KB to wallets, rather than be stuck with
predefined options that may not be high enough.
* Add support for fee-bumping via (FSS)-RBF to wallets and Bitcoin Core.
Capacity limits are just a fact of life in the design of the Bitcoin protocol,
but that doesn't mean we can't give users the tools to deal with them
intelligently.
-https://gist.github.com/petertodd/8e87c782bdf342ef18fb
--
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/60768123/attachment.sig>;