<unnamed>

Public Key

npub1h0jpmhuc5ufwtzz92ut7erelpzfu2vrfntc2nr97smq27qfckfwsyc9su0

Profile Code

nprofile1qqstheqam7v2wyh93pz4w9lv3uls3y79xp5e4u9f3jlgds90qyutyhgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmv3m7jz7

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:26:36 CEST

- reply

📅 Original date posted:2020-08-21
📝 Original message:It's been 5 years since minrealytxfee was lowered. At the time
bitcoin was trading for $255 and it was agreed that the fee of 5000
sat/vkB was too high. It was lowered to 1000 sat/vkB. In regards to
how much anti-DoS protection that provided, it comes out to $0.00255 /
vkB in USD terms. To have parity with the last reduction, we would
need to reduce minrealytxfee to 22 sat/vKB, though an even more
conservative reduction to 100 or 50 sat/vKB would be welcome.
With the growing adoption of LN, there is a need for ultra-low-fee
on-chain TXNs. Having these queue and confirm overnight, or even
waiting until the Sunday lull would still probably be welcome to many
users. The fact that the mempool is going empty at least every week
indicates that miners have not reached the floor of what they are
willing to mine.
About 2 years ago there was a PR (#13922) to try to make a reduction
from 1000 to 200 sat/vkB. It was widely accepted but the submitter
eventually closed it in favor of PR #13990.
If minrelaytxfee is already parameterized and configurable in
bitcoin.conf, how could it be detrimental to operation of a node to
change the default?
References:
* https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
* https://github.com/bitcoin/bitcoin/pull/13922
* https://github.com/bitcoin/bitcoin/pull/13990

2023-06-07 20:08:33 CEST

- reply

📅 Original date posted:2017-12-08
📝 Original message:I know there are posts, and an issue opened against it, but is there anyone
writing a BIP for Sign / Verify message against a SegWit address?
I realize it is not a feature in wide use, but I think it still serves an
important purpose, such as when proof of assets are requested.
ref: https://github.com/bitcoin/bitcoin/issues/10542
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171208/3315b91a/attachment.html>

2023-06-07 17:41:52 CEST

- reply

📅 Original date posted:2015-07-10
📝 Original message:Some miners have voluntarily deployed CPFP.
I had a thread about it earlier this month where some other ideas got
tossed around.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009304.html
The specific pull request to get it into the reference implementation
is still open based on a merge conflict
https://github.com/bitcoin/bitcoin/pull/1647
Peter Todd has another thread on RBF which you mentioned earlier
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html
There is also a beautiful example of CPFP in action from Eligius in
this transaction:
https://blockchain.info/tx/4cc3e2b6407ae8cdc1fd62cb3235f9c92654277684da8970db19a0169e44c68c
Follow the spent outputs and you will see the person is trying to
incentive the transaction by upping the fees of dependent
transactions. It set in the mempool until Eligius won a block, then
it made it into the chain. CPFP still works, but only in an Eligius
block (that I can see). So it's better than nothing.