Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
Zman, Price Theory simply explains the relationship between supply & demand. Your post makes some logical leaps in that you are implying that demand follows supply, which of course is not true, nor is that a claim of Price Theory. If Bitcoin has less utility, it will have less demand, regardless of whether it is well-optimized to allow for capacity saturation. I do agree that there is an optimal state, and that such state is not likely to be at the maximum price, because price maximization is exclusive. (Whether I deem any of this as "reasonable," as you say, is irrelevant other than whether I personally, subjectively choose to participate.) The optimal state (most fees earned), would surely be a result of the most value provided (per blockspace, per time period). While we must do our best to make sure txns have the smallest footprint, and that people have ways to pay a fee proportional to their time preference, there is always a maximum quantity of demand willing to pay any given fee. My arguments express how zero-conf currently creates added demand for blockspace, by merchants/consumers, and additionally, demand for *next-block* inclusion (maximum time preference) due to merchants qualifying fee rates to be eligible for zero-conf acceptance. So, me saying that RBF is fee-minimization, which you have conceded, is apt, in that we should probably not trade off something like zero-conf utility (demand) for something like mempoolfullrbf (blanket replaceability that overrides status quo use cases). Your statement of "If more people could use RBF onchain, more people would use Bitcoin and increase the value to miners." is not economically rational unless you truly can prove that supply creates demand. This is observably false, as blocks are not full. Also, you stated "Unfortunately many 0-conf acceptors outright reject opt-in-RBF, despite the improved discovery of the optimum price, and thus there is a need for full-RBF to improve price discovery of blockspace when such acceptors are too prevalent." This is also irrational and incorrect. First, merchants do not "outright reject" opt-in RBF, they simply make the customer wait 1 conf. Second, full-rbf has no positive effect on price discovery for blockspace if it results in less people using Bitcoin for actual trade. ~John It is helpful to remember that the fees are a price on confirmation. > And in economics, there is a "price theory": > > * As price goes down, demand goes up. > * As price goes up, net-earning-per-unit goes up. > > The combination of both forces causes a curve where *total* earnings vs > price has a peak somewhere, an "optimum price", and that peak is *unlikely* > to be at the maximum possible price you might deem reasonable. > And this optimum price may very well be *lower* than the prevailing market > price of a good. > > Thus, saying "RBF is actually a fee-minimization feature" neglects the > economics of the situation. > If more people could use RBF onchain, more people would use Bitcoin and > increase the value to miners. > > Rather than a fee-minimization feature, RBF is really an optimization to > *speed up* the discovery of the optimum price, and is thus desirable. > > Unfortunately many 0-conf acceptors outright reject opt-in-RBF, despite > the improved discovery of the optimum price, and thus there is a need for > full-RBF to improve price discovery of blockspace when such acceptors are > too prevalent. > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin Contracting Primitives WG 2nd Meeting, Tuesday 20 Dec. 18:00 UTC
Hi list, I'm proposing Tuesday 20th December at 18:00 UTC, i.e 1 week from now for the 2nd Bitcoin contracting primitives WG meeting. As a soft proposal for an agenda, the first part could be to roam over all the contracting protocol use-cases and corresponding primitives, to ensure there is exhaustivity of the R&D effort w.r.t known ideas issued by the community during the past years. If you have been working on a primitive and corresponding use-cases, and it's missing in the current listing, feel free to open a PR or bump me to do so. The second part could be to take time to listen to everyone blockers in their contracting primitives/covenant research, if someone would like more review on their proposals, or if someone would like to work on a code implementation and it misses familiarity with Bitcoin Core Script interpreter, or if someone would like to experiment a minimal use-case on bitcoin-inquisition, or if someone has conceptual questions on the primitive design approach, or if someone thinking to propose a new cryptosystem at the consensus-level for Bitcoin, or whatever [0]. Communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. Logs of the previous session are available here [1]. Let it know if you have more questions or feedback. Cheers, Antoine [0] My own goal is to keep rolling the ball on a taproot annex implementation (https://github.com/bitcoin-inquisition/bitcoin/pull/9) as it could be useful as a fee-bumping primitive/constrained amount malleability extension for multi-party channels, and potentially other uses. [1] https://github.com/ariard/bitcoin-contracting-primitives-wg/blob/main/meetings/meetings-15-11.md ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Full-RBF Peering Bitcoin Core v24.0.1 Released
Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0.1 eg: git clone -b full-rbf-v24.0.1 https://github.com/petertodd/bitcoin.git What is this? It's Bitcoin Core v24.0.1, with Antoine Riard's full-rbf peering code, and some additional minor updates to it. This does two things for full-rbf nodes: 1) Advertises a FULL_RBF service bit when mempoolfullrbf=1 is set. 2) Connects to four additional FULL_RBF peers. Doing this ensures that a core group of nodes are reliably propagating full-rbf replacements. We don't need everyone to run this. But it'd be helpful if more people did. Right now I'd estimate that there are ~30 reliable nodes accepting incoming connections and running the v24.0 version of this branch. Additionally there are another ~50 reliable Bitcoin Knots nodes accepting incoming connections; Knots advertises the service bit, but doesn't have the peering code. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] libsecp256k1 version 0.2.0 released
Hi, After not even 10 years of development, we'd like to announce the first tagged release of libsecp256k1, version 0.2.0: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.2.0 For a long time, libsecp256k1's development only had a master branch, creating unclarity about API compatibility and stability. Going forward, we will be creating tagged releases when relevant improvements are merged, following a semantic versioning scheme. This is not yet a version 1.0.0 as there are some important improvements we'd like to make before that point. We do reserve the ability to introduce API breaks, but promise clear documentation of such changes. We're skipping version 0.1.0 because this version number was set in our autotools build scripts for years, and does not uniquely identify a set of source files. We will not be creating binary releases, but will take expected ABI compatibility issues into account for release notes and versioning. The release tag is signed with my PGP key: https://bitcoin.sipa.be/sipa.asc Grab it while it's hot. We welcome suggestions for the release process going forward. Cheers, -- the libsecp256k1 maintainers ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case
Intro Currently there is a significant use case of 0-Conf acceptance of transactions. Merchants and service providers are fully aware of the risks related to 0-conf. Full RBF if it would be significantly enabled would most likely make 0-conf not possible and significantly limit this current use case. A primary motivation for full RBF is to enable an increase of fee of trxs and enable faster acceptance in Block should it be required. Motivation To enable full RBF adoption without this impeding the 0-conf use case. This can be done by enabling the primary use of case full RBF i.e increase the fee, while keeping the outputs of TRX1 to be included within TRX2. Method TRX1 is the trx first published and held in Mempool, TRX2 is the trx which comes to replace TRX1. In order for a TRX2 to replace TRX1 in the Mempool it will require the following - 1. Outputs (addresses and amounts) are the same TRX1 and TRX2 Or - 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional Outputs to TRX1 Both cases would require the addition of at least one Input in order to increase the fee. In such a case 0-conf acceptance of TRX1 will result in a harmless double spend since TRX1 will not be included in the valid UTXO set; however the address beneficiaries of TRX1 will still be credited by TRX2. This rule would enable the increasing of network fees post publication of trx without the loss of 0-conf use case. Drawbacks Does require access to another Input inorder to take advantage of Full RBF. Summary Access to OptinRBF and FullRBF(with above limitation) would give actors full access to increasing fees as an option. The 0-conf whose risks are very much understood in the market can continue to exist as is, with the 0-conf ongoing choices being continuing to be available to actors. Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote: > For further monitoring, I've set-up a mempoolfullrbf=1 node and are > logging replacement events with [0]. I filter the full-RBF replacements > and list the replaced and replacement transactions here: > https://fullrbf.mempool.observer/ I think it would be helpful to list (a) how long ago the replaced transaction was seen compared to the [full RBF event] timestamp, and (b) particularly for cases where the replaced tx was the one that was mined, how long after the [full RBF event] the block was received. Might be more hassle than it's worth, but you might consider grouping all related replacements together, so that you can see: 2b771b7949e62434bf3002ad0d38f383a29b362cf2dc31627a35a883d0de36c3 [2601.19 sat/vb] 9ce405ab14e8d68c7a43d190414e39564d90bbee21f23020f2ce45136927ce9b [2448.25 sat/vb] 1a5f239e7fc008f337605e0b405579234d0fecebaf6be966000dcfaf0bcb7beb [2295.31 sat/vb] 0500a3ca5e4998fb273be9b51a4c3a75780acf28b23409a54f4260e069441e32 [2142.37 sat/vb] 955623c789eb0a7ca0848ce964325d6b2c7d1731a686d573018f6348de6c00a1 [1989.42 sat/vb] 7838bc60405f9b38a79c94f4f045b8debaf41c0a5acfdeebc6a3904188b2bbc9 [1836.48 sat/vb] 2d5e6b84602d45c5c834e0cad4db4dd8a9142ba7eff6bacdb34a97e5cfacb418 [1683.54 sat/vb] 130851951a1d9270776852491bda3e17bb08b9309e5b76b206633f88a9341604 [1530.60 sat/vb] 3c9b2530c02a22c966fa9ef60ec0acf17bd23a8b0b4c5202589c190ee770c880 [1377,66 sat/vb] 49889043ec7dae7a4f1573c5feaca6a549d88e4fb306cf3b410155ba919da83d [1224.72 sat/vb] 861156e18ae0399cd458c6f7f7faed1a94142db45f1d879b9ae78cb11cd7e96c [1071.78 sat/vb] 961bf21f1fc35edacd4929e8db67b27a52c69a593d32aab5a024757503c0490b [ 918.84 sat/vb] 5cdb24e2ed30dfc55b23820676a9d47d158fec982e77dddadc648280f0b2c914 [ 765.90 sat/vb] 159494115af33b414df77d3965de5eb191b4a3af1c1219509f3175abc5dcd132 [ 612.95 sat/vb] dcf4c0e688ee76188e9ef829d03cc66ee7da404717b9d56d74bcd75708612271 [ 460.01 sat/vb] 1971d9122551a898bcbc5183d4ea79e273dea89aa4075d4e014f8f7dd4eb8321 [ 307.07 sat/vb] c43316d2e4bb12fbb408de01d64c4b480fd7d6875db4ebbf006fdc7579546d13 [ 154.13 sat/vb] 8bbf6a0f3dd8358c6d8a81f0811216d7980288b14daeac82ff2f672ea8e4851d [ 1.19 sat/vb] [mined in 767044] at a glance as a single block (ideally with timestamps). Arguably, that might be interesting to see in general (ie for bip-125 opt-in rbf txs as well), to see how common the "offer a low fee, and raise it over time" approach is in practice. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] bitcoin-inquistion 23.0: evaluating soft forks on signet
Hi *,
Bitcoin Inquisition 23.0 is tagged:
https://github.com/bitcoin-inquisition/bitcoin/releases/tag/inq-v23.0
It includes support for BIP 118 (ANYPREVOUT) and BIP 119
(CHECKTEMPLATEVERIFY) on regtest and signet.
As previously discussed, the hope is that this will allow more
experimentation and building a greater understanding of the risks,
benefits, and tradeoffs of proposals like BIP 118 and BIP 119.
For an initial trial period, we've switched to mining 100% of blocks on
the default global signet using this patchset. However should a problem
occur (eg the node software crashing, or some unintended hard fork being
triggered), the signet miners are configured to automatically fall back to
using bitcoin core nodes to ensure that signet continues to be available.
In order to more reliably relay transactions using the new soft forks,
you may wish to manually connect to a node that supports these features;
you can do so by specifying:
addnode=inquisition.bitcoin-signet.net
addnode=phfrpeh47vpjvoi2dgpngfk6ynl7vbnxwekwtcpg3zancixnnjvq.b32.i2p
If you are trying to do experiments with signet and would like a
larger budget than the various faucets will give you, please join the
#bitcoin-signet IRC channel on Libera, and let us know. That applies
whether or not you're making use of inquisition-y features!
If you wish to enable these soft forks on a custom signet, you should mine
a block with version 0x60007600 (BIP 118) and/or version 0x60007700 (BIP
119), then monitor activation using `bitcoin-cli getdeploymentinfo`. The
inquisition node software should also correctly validate/relay CTV
transactions on the existing ctv signet (ctvsignet.com).
As one simple bit of experimentation, block rewards are currently being
sent to the address
tb1pwzv7fv35yl7ypwj8w7al2t8apd6yf4568cs772qjwper74xqc99sk8x7tk
This is a taproot address with an ANYPREVOUT script path ("OP_1
OP_CHECKSIG"), which has an example spend splitting 1000 sBTC into 900
sBTC for Kalle's mining wallet and 100 sBTC into mine:
https://mempool.space/signet/tx/2ba88276dee53abdff23258b7f5b8d41005c69f03dc9a5bb9d5cb7b7f41f3e45
Because this transaction was signed with an ANYPREVOUTANYSCRIPT|ALL
signature, that signature can be replayed with other utxos of that pubkey,
eg in the following transaction:
https://mempool.space/signet/tx/ef8b3351def1163da97f51b8d2cba53c9671dfbd69ae4b1278506b9282bfbdea
That transaction was generated by setting up a watchonly wallet to
monitor that address:
$ bitcoin-cli -signet createwallet testapo true false '' false true true
$ bitcoin-cli -signet -rpcwallet=testapo importdescriptors
'[{"desc":"addr(tb1pwzv7fv35yl7ypwj8w7al2t8apd6yf4568cs772qjwper74xqc99sk8x7tk)#30t3uj6k",
"active":false, "timestamp":1670803200}]'
then manually putting together sufficient inputs to fund the required
signed outputs (with the excess going to fees, and hence back to the
original address since that's where mining payouts are being sent)
and adding the same witness data once for each input:
$ (X=20; printf "0201%02x" $X;
bitcoin-cli -signet -rpcwallet=testapo listunspent | jq -j '.[] | (.txid,
" ", .vout, "\n")' | head -n$X |
while read txid vout; do
rtxid=$(echo $txid | sed 's/../& /g' | tr ' ' '\n' | tac | tr -d '\n');
printf "%s%02x%06x00" "$rtxid" "$vout";
done;
printf
"0200046bf4140016001481113cad52683679a83e76f76f84a4cfe36f750100e40b5402001600141b94e6a88e7bfb3a552d6888b102c4f615dc2f56";
for a in `seq 1 $X`; do
printf
"034189d888393f0c46872fbd002b3523cf58dd474ab86014096bdf69e5248cc06cd6f4b5a223053eb97a708b47ed1d25ad26be7f197536af86ad3389cb1d53a0e643c10251ac21c0624aa2e3277b1f5d667c5acc0ec58eccad8c8be7c7815e122d2b65127f8b0e28";
done;
echo ""
) | sed 's/^/["/;s/$/"]/' | bitcoin-cli -stdin -signet testmempoolaccept
That should be something anyone running an inquisition client can
duplicate (err, if you can handle the awesomeness of my shell one-liners);
though doing more than just testmempoolaccept will be naturally rate
limited as it spends 20 blocks worth of reward. There shouldn't be any
way of turning it into a profit, or much of a denial-of-service attack,
but if you find one, that's probably new information about BIP 118! (One
thing you could do is use it as a way of creating an excessively high
CPFP feerate, though without package relay, and on signet, that's probably
not terribly useful)
Finally, yes this is based on Bitcoin Core version 23.0 when 24.0.1
has just been released. The plan in general is to keep inquisition
focussed on released versions of core to minimise rebasing, and more
concretely, to start forward porting the current patches to that now
that it has been released, and possibly consider including support for
additional BIPs (ideas so far include: defining annex interpretation and
package rbf). Discussion of those ideas welcome (on list, on the repo,
or #bitcoin-signet or #bitco
