Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
I also like the "bitcoin invoice address" term by Chris. Invoice is a common term and easily translatable into other languages. Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [bitcoin-core-dev] Bitcoin Core 0.18.0 released
Two addenda from me:
* Beginning with Bitcoin Core 0.18.0, Windows builds for 32-bit
Windows will no longer be provided. Please let us know if and why you
can not use the 64-bit build.
* There is an experimental Bitcoin Core snap package in the snap
store. There should be a "track" for the latest release and a track
for each major version branch that is not yet EOL. While the snap
package uses the signed release binaries, I am not aware of a way to
generate the hash of binaries in an installed snap that works on any
Linux distribution. (On some distributions, a call to `sha256sum
/var/lib/snapd/snap/bitcoin-core/current/{bin/*,snap/snapcraft.yaml}`
generates the hashes that you can then compare to the signed ones as
usual)
Marco
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] IsStandard
There is not a single document that describes what is standard and what is not. Transaction relay policy (including minimum relay fees) may change over time, across different implementations or different versions of the same implementation. Generally you can assume that commonly used scripts that are standard today remain standard. To test if a script is standard and accepted by current relay policy of a Bitcoin Core node, you can create a tx that spends from it on mainnet or on testnet and see if it is accepted to the mempool of your local node. Make sure to disable -acceptnonstdtxn=0 on testnet. Should the standardness-rules of a script type ever change, it will be announced and discussed on this mailing list. And of course, lightning transactions are standard as they otherwise wouldn't propagate. Best, Marco On Sun, Apr 28, 2019 at 9:06 PM Aymeric Vitte via bitcoin-dev wrote: > > Maybe trivial question but asking here because I can't find anything > clear (or updated) about it: is somewhere explained in details what txs > are considered standard and non standard today without having to read > the core code? > > For example, modification of multisig 2 of 3: > > scriptSig: > OP_0 > OP_PUSHDATA sign1 > OP_PUSHDATA sign2 > OP_2 > OP_PUSHDATA OP_3 OP_CHECKMULTISIG > > scriptPubKey: > OP_HASH160 hash160( OP_3 > OP_CHECKMULTISIG) OP_EQUAL > > Is this standard? Are lightning txs standards ? etc > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
Bitcoin Core may send "reject" messages as response to "tx", "block" or
"version" messages from a network peer when the message could not be accepted.
This feature is toggled by the `-enablebip61` command line option and has been
disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
time of writing). Nodes on the network can not generally be trusted to send
valid ("reject") messages, so this should only ever be used when connected to a
trusted node. At this time, I am not aware of any software that requires this
feature, and I would like to remove if from Bitcoin Core to make the codebase
slimmer, easier to understand and maintain. Let us know if your application
relies on this feature and you can not use any of the recommended alternatives:
* Testing or debugging of implementations of the Bitcoin P2P network protocol
should be done by inspecting the log messages that are produced by a recent
version of Bitcoin Core. Bitcoin Core logs debug messages
(`-debug=`) to a stream (`-printtoconsole`) or to a file
(`-debuglogfile=`).
* Testing the validity of a block can be achieved by specific RPCs:
- `submitblock`
- `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
potentially invalid POW
* Testing the validity of a transaction can be achieved by specific RPCs:
- `sendrawtransaction`
- `testmempoolaccept`
* Wallets should not use the absence of "reject" messages to indicate a
transaction has propagated the network, nor should wallets use "reject"
messages to set transaction fees. Wallets should rather use fee estimation
to determine transaction fees and set replace-by-fee if desired. Thus, they
could wait until the transaction has confirmed (taking into account the fee
target they set (compare the RPC `estimatesmartfee`)) or listen for the
transaction announcement by other network peers to check for propagation.
I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
valid concerns about its removal.
Marco
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Contribution
This mailing list is for the development of the Bitcoin protocol (see https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev). Code changes to Bitcoin Core can be discussed on https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev or preferably be submitted to https://github.com/bitcoin/bitcoin/ directly. -- Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] v0.16.1 test_bitcoin fails on Deian 9
Hi, and thanks for the detailed issue report. This was a known issue in test code that is only compiled when debugging. It will be fixed in the upcoming 0.16.2 and 0.17.0 releases. If you see any further issues, note that we track technical issues related to the Bitcoin Core code base on our issue tracker: https://github.com/bitcoin/bitcoin/issues/new Marco On Sat, Jul 14, 2018 at 9:48 AM, Shigeya Suzuki via bitcoin-dev wrote: > Hi, > > I observed strange result when running src/test/test_bitcoin on Debian 9. > > I tested with the following platforms: > > 1) OS X High Sierra 10.13.6 with >./configiure --enable-debug > > 2) Debian 9 (with latest packages) with >./configure --enable-debug --disable-wallet --without-gui > > 3) Ubuntu 16.04 with: >./configure --with-debug --disable-wallet > > strangely, configuration 2 cause core dump but others not: > > Running 264 test cases... > unknown location(0): fatal error: in > "validation_block_tests/processnewblock_signals_ordering": memory access > violation at address: 0x: no mapping at fault address > zsh: segmentation fault ./test_bitcoin > > I guess it is due to toolchain differences. > > Any thoughts? > > Shigeya Suzuki > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments
> They also do not require software coordination. Therefore, why should there be > BIPs at all? Seems to me that we should instead add these documents to > https://github.com/bitcoin-core/docs Consensus is not trivial. I think documentation is important, even if it seems simple to some. Personally, I don't care too much where to place the documentation, but the BIPs repo seems a good place, since it also hosts other informational documents. To prevent "two BIPs for every protocol change", related buried deployments could be bundled. E.g. the ISM BIP 90 change. On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil wrote: > On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote: >> I define a buried deployment as a consensus rule change that affects >> validity of blocks that are buried by a sufficiently large number of >> blocks in the current valid most-work chain, > > Sufficient for what, specifically? Sufficiently large to prevent potential bike-shedding. The expected number of blocks in two weeks could be considered a lower bound. Then multiply that by 10 or 20. > >> but the current block (and all its parents) remain valid. > > Remain valid in the case where the depth assumption is "sufficient" to > ensure that a chain split is not possible? > > If this was true (which it is not), it would imply that there is no > reason to validate any block deeper than the most recent 25,000. > Presumably this means that people may continuously rely on some > authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000. > Note that a checkpoint *freezes* the chain completely at a given height. Buried deployments are *not* checkpoints. Also note that buried deployments only make sense after a protocol upgrade has happened (i.e. a soft fork or hard fork). If a miner has the resources to cause a chain split, they could trivially do that even in the complete absence of buried deployments. Buried deployments are *not* a solution to 50% attacks. >> BIP 123 suggests that BIPs in the consensus layer should be assigned a >> label "soft fork" or "hard fork". However, I think the differentiation >> into soft fork or hard fork should not be made for BIPs that document >> buried deployments. In contrast to soft forks and hard forks, buried >> deployments do not require community and miner coordination for a safe >> deployment. > > They can only avoid this requirement based on the assumption that the > hard fork cannot result in a chain split. This is not the case. > >> For a chain fork to happen due to a buried deployment, a massive chain >> reorganization must be produced off of a block in the very past. > > In other words a "buried deployment" is a hard fork that is not likely > to cause a chain split. This is a subjective subcategory of hard fork, > not an independent category - unless maybe you can show that there is > the 25,000 blocks number is an objective threshold. Please note that a buried deployment can very well be a soft fork. I think this makes it even clearer, that such a label makes no sense for buried deployments. >> In the extremely unlikely event of such a large chain reorganization, >> Bitcoin's general security assumptions would be violated regardless of >> the presence of a buried deployment. > > This is untrue. The "security assumptions" of Bitcoin do not preclude > deep reorganizations. > e > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Amend the BIP 123 process to include buried deployments
I define a buried deployment as a consensus rule change that affects validity of blocks that are buried by a sufficiently large number of blocks in the current valid most-work chain, but the current block (and all its parents) remain valid. BIP 123 suggests that BIPs in the consensus layer should be assigned a label "soft fork" or "hard fork". However, I think the differentiation into soft fork or hard fork should not be made for BIPs that document buried deployments. In contrast to soft forks and hard forks, buried deployments do not require community and miner coordination for a safe deployment. For a chain fork to happen due to a buried deployment, a massive chain reorganization must be produced off of a block in the very past. In the extremely unlikely event of such a large chain reorganization, Bitcoin's general security assumptions would be violated regardless of the presence of a buried deployment. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence)
> In 0.13.1 the error is > > > Running test/bitcoin-util-test.py... > Traceback (most recent call last): > File "./test/bitcoin-util-test.py", line 12, in > "bitcoin-util-test.json",buildenv) > File "/builddir/build/BUILD/bitcoin-0.13.1/src/test/bctest.py", line 54, > in bctester > bctest(testDir, testObj, buildenv.exeext) > File "/builddir/build/BUILD/bitcoin-0.13.1/src/test/bctest.py", line 26, > in bctest > outputData = open(testDir + "/" + outputFn).read() > FileNotFoundError: [Errno 2] No such file or directory: > './test/data/blanktx.json' This was a known problem on the *master* branch. If you still encounter any issues on the current 0.13.2 release candidate, please let us know in https://github.com/bitcoin/bitcoin/issues/9394. (Make sure to include the version of centos you are running) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 2 revival and rework
On Sat, Oct 15, 2016 at 4:21 PM, Tom Zander via bitcoin-dev wrote: >> > My suggestion (sorry for not explaining it better) was that for BIPS to >> > be a public domain (aka CC0) and a CC-BY option and nothing else. >> >> Indeed, we agree that BIPs should be licensed as permissive as >> possible. Still, I wonder why you chose otherwise with BIP 134. >> (Currently OPL and CC-BY-SA) > > OPL was the only allowed option apart from CC0. I think you are misunderstanding what is allowed and what is required... BIP1: "Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License" So BIP1 *requires* PD or OPL but does not forbid other licenses. For example, you are free to multi license OPL (and additionally: BSD, MIT, CC0, ...) BIP2: "Each new BIP must identify at least one acceptable license in its preamble." So BIP2 *requires* an acceptable license but does not forbid other choices. For example, you are free to choose: BSD (and additionally: PD, CC-BY-SA, WTFPL, BEER, ...) >> BIP 2 does not forbid you to release your work under PD in >> legislations where this is possible > > It does, actually. Huh, I can't find it in the text I read. The text mentions "not acceptable", but I don't read that as "forbidden". > >> One >> of the goals of BIP 2 is to no longer allow PD as the only copyright >> option. > > That's odd as PD was never the only copyright option. Right. Though, up to now the majority of the BIP authors chose PD as the only option. Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 2 revival and rework
On Sat, Oct 15, 2016 at 1:00 PM, Tom Zander via bitcoin-dev wrote: > My suggestion (sorry for not explaining it better) was that for BIPS to be a > public domain (aka CC0) and a CC-BY option and nothing else. Indeed, we agree that BIPs should be licensed as permissive as possible. Still, I wonder why you chose otherwise with BIP 134. (Currently OPL and CC-BY-SA) > I like you agree with that part, but I see you added two licenses. > Do you have a good reason to add MIT/BSD to that list? Otherwise I think we > agree. Licenses that only require attribution are generally compatible with each other. I don't think we should pick one and only promote/endorse this one. Let's just leave the decision to the BIP author. > Well, it has this sentence; > >> This BIP is dual-licensed under the Open Publication License and >> BSD 2-clause license. > > Which is a bit odd in light of the initial email from Luke that suggested we > drop the Open Publication License and we use the CC ones instead in addition > to the public domain one. I am pretty sure this is required to host the current text of BIP 2 in the repo, as currently BIP 1 still applies and still requires for all BIPs either OPL or PD, which is one of the reasons I think we should move forward with BIP 2 or amending BIP 1. > Marco: >> looks good and addressed the feedback which was >> accumulated last year. If there are no objections I'd suggest to move >> forward with BIP 2 in the next couple of days/weeks. > > Thats odd, you just stated you like the public domain (aka CC0) license, yet > you encourage the BIP2 that states we can no longer use public domain for > BIPs... Did you read it? > It says; > «Public domain is not universally recognised as a legitimate action, thus > it is inadvisable.» [1] BIP 2 does not forbid you to release your work under PD in legislations where this is possible. None of the licenses mentioned in BIP 2 is exclusive, so you can choose as many options as you like. One of the goals of BIP 2 is to no longer allow PD as the only copyright option. > > Also; > This list has not seen a lot of traffic, if you want to make sure people keep > using the BIP process, I think you need to reach out to the rest of the > community and make sure this has been heard and discussed. > Moving forward the way it is now will likely deminish the importance of the > BIP process. > > I strongly suggest people make very clear any and all changes that are > proposed and defend each of them with reasons why you want to change things. > > > 1) if you write as a rationale "In some jurisdictions, public domain is not > recognised as a legitimate legal action" then you can at least name those > jurisdictions and explain how they *do* support things like GPL. Burden of > proof is on the man who wants to change things. > It looks fishy when lawyers disagree. See the CC wikipedia page; > "public domain: cc0 Freeing content globally without restrictions" Luke is the BIP champion of BIP 2, so please cc him if you have suggestions on how to improve the process of gathering community consensus. Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 2 revival and rework
On Sat, Sep 24, 2016 at 11:41 AM, Tom via bitcoin-dev wrote: > I'd suggest saying that "Share alike" is required and "Attribution" is > optional. Please note there is no CC license that requires SA and at the same time has BY as an option. Generally, I think CC0 is best suited as license for BIPs. If authors are scared that they won't get proper attribution, they can choose MIT/BSD or CC-BY. Other than that I don't think that more restrictive licenses are suitable for BIPs. The BIP repo seems like the wrong place to promote Open Access (e.g. by choosing a CC-BY-SA license). BIP 2 allows such licenses, but does not recommend them, which is fine. I think that BIP 2 in its current form ( https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki @6e47447b ) looks good and addressed the feedback which was accumulated last year. If there are no objections I'd suggest to move forward with BIP 2 in the next couple of days/weeks. Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] consensus rule change for TX fee safety
2016-03-03 16:28 GMT+01:00 Peter Todd via bitcoin-dev : > Bitcoin Core already implements this safety limit with the "absurd fee" > limit of 1 * the minimum relay fee. This limit is active in both the > wallet and the sendrawtransaction RPC call. Additionally for the wallet > there is a user configurable -maxtxfee option to limit fees set by the > wallet which currently defaults to 0.1 BTC. It is planned for Bitcoin Core 0.13 to use -maxtxfee for both, the wallet and the RPC interface (sendrawtransaction). (c.f. https://github.com/bitcoin/bitcoin/pull/7084) In regard to the issue, I agree with Jonas. Such large transaction fees were historically caused by no or insufficient warnings from the wallet software. And it's the responsibility of the operators to make the wallet user friendly. Apart from that, there are legit use cases where one would want to "pay" a large transaction fee: It may be convenient for the miner to just collect the fees instead of sending back the change on their own transactions. Of course making sure to mine the high-fee tx themself. Moreover, it could increase privacy if another party decides to "wash" their bitcoins by letting the miner claim the "fee" and then have the miner send back a fraction of the fee to a fresh address. Though, this probably works best if a lot of participants are doing this. Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
All of this is already implemented in the bitcoind and bitcoin gui. The theoretic minimum for the prune target would be 0 (just the header of the current best block) as Bitcoin Core already stores the chainstate (about 2 GiB) regardless of what you set for -prune=. In practice, the minimum is 510, so reorgs and small rescans (may not be implemented in 0.12) are still possible. The clients won't let you set it below that target: "Prune configured below the minimum of 550 MiB. Please use a higher number." Also, keep in mind Bitcoin Core comes with a help message explaining -prune and other command line options --Marco 2016-01-25 13:27 GMT+01:00 xor--- via bitcoin-dev : > On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote: >> > If yes, I would highly recommend advertising it in the new release notes - >> > as said, the disk space reduction is a big deal. >> >> Good idea, has been added by Marco Falke in commit fa31133, > > Thanks. The RC2 changelog now says: > >> To enable block pruning set prune= on the command line or in >> bitcoin.conf, where N is the number of MiB to allot for raw block & undo >> data. > > From having read the Bitcoin whitepaper quite a few months ago ago, I have the > very very basic understanding that pruning is meant to: > - delete old transaction data which merely "moves coins around" > - instead only store the "origin" (= block where coins were mined) and > "current location" of the coins, i.e. the unspent transactions. Notably, I > understood it as "this is as secure as storing everything, since we know where > the coins were created, and where they are". > > So from that point of view, I would assume that there is a "natural" amount of > megabytes which a fully pruned blockchain consists of: It would be defined by > the final amount of unspent coins. > I thereby am confused why it is possible to configure a number of megabytes > "to allot for raw block & undo data". I would rather expect pruning just to be > a boolean on/off flag, and the number of megabytes to be an automatically > computed result from the natural size of the dataset. > And especially, I fear that I could set N too low, and as a result, it would > delete "too much". I mean could this result in even security relevant > transaction data being deleted? > > Thus, it would be nice if you could yet once more edit the release notes to: > - explain why a N must be given > - what a "safe" value of N is. I.e. how large must N be at least to not delete > security-relevant stuff? > - maybe mention if there is a "auto" setting for N to ensure that it choses a > safe value on its own? > > Sorry if my descriptions are from a layman's point of view. I intentionally > did *not* re-read the Bitcoin whitepaper to have a better understanding: > I think having a layman's understanding is a good usability test for such > stuff. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
This is an interesting approach but I don't see how this is a soft fork. (Just because something is not a hard fork, doesn't make it a soft fork by definition) Softforks don't require any nodes to upgrade. [1] Nonetheless, as I understand your approach, it requires nodes to upgrade. Otherwise they are missing all transactions but the coinbase transactions. Thus, they cannot update their utxoset and are easily susceptible to double spends... Am I missing something obvious? -- Marco [1] https://en.bitcoin.it/wiki/Softfork#Implications ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
