<unnamed>

Public Key

npub1qspcss06rhl7lwrhzrnv5k7w7er32htkgds2d50802eguajx4p5sp9jjz5

Profile Code

nprofile1qqsqgqugg8apmll0hpm3pek2t080v3c4t4myxc9x68nh4v5wwer2s6gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dstksm3y

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 18:17:50 UTC

- reply

📅 Original date posted:2019-04-29
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> 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 <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKMULTISIG
>
> scriptPubKey:
> OP_HASH160 hash160(<pubkey1><pubkey2><pubkey3> OP_3
> OP_CHECKMULTISIG) OP_EQUAL
>
> Is this standard? Are lightning txs standards ? etc
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:16:34 UTC

- reply

📅 Original date posted:2019-03-05
📝 Original message: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=<category>`) to a stream (`-printtoconsole`) or to a file
(`-debuglogfile=<debug.log>`).
* 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

2023-06-07 17:53:58 UTC

- reply

📅 Original date posted:2016-10-15
📝 Original message:On Sat, Oct 15, 2016 at 1:00 PM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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

2023-06-07 17:53:57 UTC

- reply

📅 Original date posted:2016-10-15
📝 Original message:On Sat, Sep 24, 2016 at 11:41 AM, Tom via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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

2023-06-07 17:47:55 UTC

- reply

📅 Original date posted:2016-01-25
📝 Original message: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=<N>.
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
<bitcoin-dev at lists.linuxfoundation.org>:
> 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=<N> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>