📅 Original date posted:2015-06-18
📝 Original message:Ben,
How does your wallet calculate the fee that should be paid to miners? Do
they automatically adjust when transactions take a long time to be
confirmed? And how does it respond when transactions are not mined
successfully, such as when blocks are full?
I strongly urge Gavin to withdraw from this standoff and work with the
> bitcoin core devs via the existing and successful bip process.
>
The BIP process has not resulted in any hard forks, so this is a little
different. While I don't like M&G's proposed solution of convincing miners
and services to switch to Bitcoin-XT, I recognize that it is done out of a
sense of urgency. These types of changes take a long time to roll out, and
we should start them before it is too late.
This whole debate comes down to: what is more risky, a consensus hard fork
or letting bitcoin exceed its imposed capacity limits? The former could
result in many services not being compatible and even loss of funds. The
latter could result in software failures, instability, and inability to
transact: essentially, what bitcoin is supposed to be good at. Both are
dangerous and could result in a significant loss of public confidence.
Something needs to be done, that's for sure. In the short term, I think we
need to do one of two things:
1. All miners and wallet developers need to upgrade to support
first-safe RBF, to allow for double spending one's own transactions when
they lack sufficient fees to merit confirmations. Wallets also need to
randomly request transactions from blocks to see what kind of fees are
being paid to get confirmations, so that fees can be paid dynamically
instead of with hard-coded values.
2. We can implement either Gavin's or Jeff Garzik's proposal to change
the consensus parameters around the block size limit.
So Ben, if really don't think that going with #2 is the right way to go
(even though everyone agrees that we will need to increase the block size
limit eventually anyway, why not now?), then I hope you start to work hard
on implementing #1 so that your wallet software can handle hitting capacity
limits gracefully.
Best,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/d7170921/attachment.html>;
Stephen Morse [ARCHIVE] /
npub1ja…q0j2u
2023-06-07 15:38:46
in reply to nevent1q…en8l
Author Public Key
npub1ja0fa5k6j04r2h7jp33lvdy2kzpv5yj60ce4wvcca7fvxe99hw5qqq0j2uPublished at
2023-06-07 15:38:46Event JSON
{
"id": "b560d3a8d6d9d36b4f96e041d6e337e17daf1dd25b71351c28e895f908801e24",
"pubkey": "975e9ed2da93ea355fd20c63f6348ab082ca125a7e33573318ef92c364a5bba8",
"created_at": 1686152326,
"kind": 1,
"tags": [
[
"e",
"66c3852e7a249873819de0318ccef1cf81c16b08ba087b87f1fd9e1a99b4297c",
"",
"root"
],
[
"e",
"ca379461ab4d92a089f69cf63b93e85eebd8fc6b78fcd81e65bfcbc2aefcc1c1",
"",
"reply"
],
[
"p",
"94538b712627aa4b6161db4122f891a08c83dded45fa43c584f910767b054b2a"
]
],
"content": "📅 Original date posted:2015-06-18\n📝 Original message:Ben,\n\nHow does your wallet calculate the fee that should be paid to miners? Do\nthey automatically adjust when transactions take a long time to be\nconfirmed? And how does it respond when transactions are not mined\nsuccessfully, such as when blocks are full?\n\nI strongly urge Gavin to withdraw from this standoff and work with the\n\u003e bitcoin core devs via the existing and successful bip process.\n\u003e\n\nThe BIP process has not resulted in any hard forks, so this is a little\ndifferent. While I don't like M\u0026G's proposed solution of convincing miners\nand services to switch to Bitcoin-XT, I recognize that it is done out of a\nsense of urgency. These types of changes take a long time to roll out, and\nwe should start them before it is too late.\n\nThis whole debate comes down to: what is more risky, a consensus hard fork\nor letting bitcoin exceed its imposed capacity limits? The former could\nresult in many services not being compatible and even loss of funds. The\nlatter could result in software failures, instability, and inability to\ntransact: essentially, what bitcoin is supposed to be good at. Both are\ndangerous and could result in a significant loss of public confidence.\n\nSomething needs to be done, that's for sure. In the short term, I think we\nneed to do one of two things:\n\n 1. All miners and wallet developers need to upgrade to support\n first-safe RBF, to allow for double spending one's own transactions when\n they lack sufficient fees to merit confirmations. Wallets also need to\n randomly request transactions from blocks to see what kind of fees are\n being paid to get confirmations, so that fees can be paid dynamically\n instead of with hard-coded values.\n 2. We can implement either Gavin's or Jeff Garzik's proposal to change\n the consensus parameters around the block size limit.\n\nSo Ben, if really don't think that going with #2 is the right way to go\n(even though everyone agrees that we will need to increase the block size\nlimit eventually anyway, why not now?), then I hope you start to work hard\non implementing #1 so that your wallet software can handle hitting capacity\nlimits gracefully.\n\nBest,\nStephen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/d7170921/attachment.html\u003e",
"sig": "9bd0e8bf74b118f3d68e161ed21d929f86a4ce477fb80f576f7d5c3f64e1d176d5d1898f2a1b97979e874d40f548c15fe1a74fc17731ac58317b5a7a333cab7c"
}