Note: this proposal needs to be slighltly modified since the storage limit for OP_RETURN is 80B and does not work for all cases, but the principles will remain the same and other storage solutions exist, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021398.html
Then for now some transactions mentionned in that proposal are not standard (ie not relayed by the nodes) but valid (ie a miner can include them into a block)
So, after discussion with the bictoin community, see Allow several OP_RETURN in one tx and no limited size
In case this change, which looks to be admitted by the majority, is trivial and not even a soft fork, is not implemented then please see the different workarounds at the end of this proposal
Before we begin: this post describes a very limited protocol idea. It's possible that what we describe here is a start towards, or a component of, something genuinely useful, but in itself it's really more of a toy, albeit it's fun.
Since the 90s, there was a dream that cash could be sent online just like email. We've basically been experimenting with tradeoffs against this pure vision ever since. Sometimes the tradeoff is: there's a central party we have to trust (either with our privacy or our money or the management or inflation or..), but otherwise we get the goal. Often the tradeoff includes: we have to interact with the receiver. In pretty much every case there's an online-ness requirement: we have to exchange messages with a p2p network of active nodes (bitcoin) or a central server and our counterparty, or at least, directly with our counterparty (e.g. Lightning) in the payment transaction.
September 2022:
This has spread to a far wider audience than I had anticipated - probably my fault for using a title that is in hindsight catnip for link aggregators. I wrote this back in 2021 just as a bunch of personal thoughts of my experiences using Rust over the years (not always well thought through), and don't intend on trying to push them further, outside of personal experiments and projects.
Managing a living language is challenging and difficult work, and I am grateful for all the hard work that the Rust community and contributors put in given the difficult constraints they work within. Many of the things I listed below are not new, and there's been plenty of difficult discussions about many of them over the years, and some are being worked on or postponed, or rejected for various good reasons. For more thoughts, please see my comment below.
Hi there,
I'm writing to propose a set of mempool policy changes to enable package validation (in preparation for package relay) in Bitcoin Core. These would not be consensus or P2P protocol changes. However, since mempool policy significantly affects transaction propagation, I believe this is relevant for the mailing list.
My proposal enables packages consisting of multiple parents and 1 child. If you develop software that relies on specific transaction relay assumptions and/or are interested in using package relay in the future, I'm very interested to hear your feedback on the utility or restrictiveness of these package policies for your use cases.
A draft implementation of this proposal can be found in [Bitcoin Core PR#22290][1].
Please see latest draft and conversation in the bips repository PR #1378
| { | |
| // The following are sample configurations for common case scenarios of debugging | |
| // Rust in Visual Studio Code | |
| // | |
| // For syntax, visit: https://go.microsoft.com/fwlink/?linkid=830387 | |
| // | |
| "version": "0.2.0", | |
| "configurations": [ | |
| { | |
| "name": "Launch an application", |
| WARNING: Logging before flag parsing goes to stderr. | |
| W0730 21:03:55.281007 139779186857856 deprecation_wrapper.py:119] From /content/drive/My Drive/ml/2019-07-30/gpt-2-elisp-untab/src/model.py:147: The name tf.AUTO_REUSE is deprecated. Please use tf.compat.v1.AUTO_REUSE instead. | |
| W0730 21:03:57.490804 139779186857856 deprecation_wrapper.py:119] From /content/drive/My Drive/ml/2019-07-30/gpt-2-elisp-untab/src/memory_saving_gradients.py:13: The name tf.GraphKeys is deprecated. Please use tf.compat.v1.GraphKeys instead. | |
| W0730 21:04:02.302061 139779186857856 deprecation_wrapper.py:119] From ./train.py:87: The name tf.ConfigProto is deprecated. Please use tf.compat.v1.ConfigProto instead. | |
| W0730 21:04:02.302422 139779186857856 deprecation_wrapper.py:119] From ./train.py:90: The name tf.Session is deprecated. Please use tf.compat.v1.Session instead. | |
| 2019-07-30 21:04:02.319198: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency: 2200000000 Hz |
git log --graph --oneline --decorate ( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )This will show you all the commits at the tips of your commit graph which are no longer referenced from any branch or tag – every lost commit, including every stash commit you’ve ever created, will be somewhere in that graph.