Re: [bitcoin-dev] [bitcoin-core-dev] Bitcoin Core 0.18.0 released

[Marco Falke via bitcoin-dev]

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] Adding xpub field to PSBT to make multisig more secure

[Andrew Chow via bitcoin-dev]

Hi Stepan,

I think that this would be a good extension.

Just for clairty, by xpub, do you mean the extended serialization format 
defined in BIP 32 or the Base58 check encoded string of that serialization?

Andrew

On 4/26/19 11:21 AM, Stepan Snigirev via bitcoin-dev wrote:
> Hi list,
>
> I was looking at the bip174 PSBT specs, in particular for 
> multisignature setup, and I think with current spec there is a way to 
> steal user funds in M of N setup with M ≤ N/2.
>
> I made a small write-up on this: 
> https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md
>
> To compress:
>
> Currently in PSBT there is no way to reliably say if the output uses 
> the keys derived from the same root keys as the inputs aside from the 
> key owned by the signer => there is no way to verify that the output 
> is a change output in multisig setup.
>
> Therefore an attacker can replace half of the keys in the change 
> address by his own keys and still get the transaction signed.
>
> I suggest to add an xpub field to the inputs and outputs metadata, 
> then signers can verify that the same xpubs are used for public keys 
> in inputs and outputs => output is indeed a change.
>
> Normally change and receiving addresses are derived from the same xpub 
> with non-hardened derivation pathes, so providing xpub after the last 
> hardened index should be enough to see that public keys of inputs and 
> change output are derived from the same xpub.
>
> I suggest to add the following key-value pairs to PSBT:
>
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
> - Key: derivation path for xpub
>   `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
>   `{xpub}`
>
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
> - Key: derivation path for xpub
>   `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
>   `{xpub}`
>
> Derivation paths are in the key of the key-value pair as they are used 
> for lookup, and xpub itself is the actual value being looked up.
>
> I also want to mention that Trezor for example doesn't suffer from 
> this problem as they use xpubs to verify change outputs. So it may 
> make sense to go through the communication protocols of existing 
> hardware / multisignature wallets and see if there is something else 
> we are missing.
>
> If everyone is happy about the proposal I would prepare a pull request 
> to the bip.
>
> Best regards,
> Stepan Snigirev.
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.18.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.18.0 is now available from:

  

or through bittorrent:


magnet:?xt=urn:btih:a25c86ffa7a512b6d074287f74762b77f91cef4c=bitcoin-core-0.18.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new major version release, including new features, various bug
fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has
completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
`/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on
Linux).

The first time you run version 0.15.0 or newer, your chainstate database
will be converted to a new format, which will take anywhere from a few
minutes to half an hour, depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and
there is no automatic upgrade code from before version 0.8 to version
0.15.0 or later. Upgrading directly from 0.7.x and earlier without
redownloading the blockchain is not supported.  However, as usual, old
wallet versions are still supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
recommended to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

- From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

In addition to previously-supported CPU platforms, this release's
pre-compiled distribution also provides binaries for the RISC-V
platform.

If you are using the `systemd` unit configuration file located at
`contrib/init/bitcoind.service`, it has been changed to use
`/var/lib/bitcoind` as the data directory instead of
`~bitcoin/.bitcoin`. When switching over to the new configuration file,
please make sure that the filesystem on which `/var/lib/bitcoind` will
exist has enough space (check using `df -h /var/lib/bitcoind`), and
optionally copy over your existing data directory. See the [systemd init
file section](#systemd-init-file) for more details.

Known issues


Wallet GUI
- --

For advanced users who have both (1) enabled coin control features, and
(2) are using multiple wallets loaded at the same time: The coin control
input selection dialog can erroneously retain wrong-wallet state when
switching wallets using the dropdown menu. For now, it is recommended
not to use coin control features with multiple wallets loaded.

Notable changes
===

Mining
- --

- - Calls to `getblocktemplate` will fail if the segwit rule is not
  specified.  Calling `getblocktemplate` without segwit specified is
  almost certainly a misconfiguration since doing so results in lower
  rewards for the miner.  Failed calls will produce an error message
  describing how to enable the segwit rule.

Configuration option changes
- 

- - A warning is printed if an unrecognized section name is used in the
  configuration file.  Recognized sections are `[test]`, `[main]`, and
  `[regtest]`.

- - Four new options are available for configuring the maximum number of
  messages that ZMQ will queue in memory (the "high water mark") before
  dropping additional messages.  The default value is 1,000, the same as
  was used for previous releases.  See the [ZMQ
  
documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md#usage)
  for details.

- - The `rpcallowip` option can no longer be used to automatically listen
  on all network interfaces.  Instead, the `rpcbind` parameter must be
  used to specify the IP addresses to listen on.  Listening for RPC
  commands over a public network connection is insecure and should be
  disabled, so a warning is now printed if a user selects such a
  configuration.  If you need to expose RPC in order to use a tool like
  Docker, ensure you only bind RPC to your localhost, e.g. `docker run
  [...] -p 127.0.0.1:8332:8332` (this is an extra `:8332` over the
  normal Docker port specification).

- - The `rpcpassword` option now causes a startup error if the password
  set in the configuration 

Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via bitcoin-dev]

Thanks for the answer, indeed for the redeem script and someone
attempting a 0/1 of 3, good example

So to summarize everything is standard as long as it matches P2PKH,
P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in
op_return

Still the case of bch is unclear (it's related since based on bitcoin
code unless they changed the policy), was the story that nodes would not
propagate the fix or that people did not want to take the risk to
propagate it? And why a non segwit old bitcoin node would not accept it
either?

Le 02/05/2019 à 02:10, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte  
> wrote:
>
>> I must badly explain my point (or just wondering things that do not
>> exist finally), the question is indeed whether nodes will relay non
>> usual transactions or not and how to know what they will accept or not:
>>
>> -   my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
>> script, the redeem script still matches scriptpubkey and scriptsig will
>> execute succesfully, that's a normal legacy P2SH or segwit P2WSH
>>
>> -   bch segwit recovery: it's a p2sh transaction without any signature
>> verification, as far as I remember there was a story that it could not
>> propagate in the network (even taking the risk to be stolen) and that
>> people had to contact a (honest) miner
>>
>> -   sha bounties: same as above, p2sh transactions without signatures
>>
>> etc
>>
>> Will all of those transactions propagate normally? And then the rule is
>> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
>> whatever scripts you put inside?
> P2PKH and P2WPKH cannot have custom script.
> However, yes, any custom script can be wrapped in P2SH and P2WSH and it will 
> be propagated.
> The P2SH/P2WSH hides the details of your custom script so cannot be filtered 
> based on your custom script.
> Do realize that once a claim on your modified x-of-3 is propagated your 
> `redeemScript` is known and someone can attempt to RBF (or coordinate with a 
> miner) with a modified `witness` stack or `scriptSig` to claim your UTXO.
> (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of your 
> signatories could make it a 1-of-3 and bribe a miner to get it claimed)
>
> I cannot answer for BCH; arguably that is off-topic here.
>
> The old SHA bounty transactions were propagated in the days before 
> `isStandard` I think.
> Either that or they were put in by miners.
> An SHA bounty can still be propagated today if they are wrapped in a P2SH or 
> P2WSH, but you have to publish the `redeemScript` yourself in some other 
> method.
> Or bribe a miner if the transaction is not time-sensitive (for an SHA bounty, 
> unlikely to be time-sensitive).
>
> Regards,
> ZmnSCPxj

-- 
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Marco Falke via bitcoin-dev]

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

Re: [bitcoin-dev] IsStandard

[Luke Dashjr via bitcoin-dev]

On Saturday 27 April 2019 10:37:29 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

The name is confusing. It has little to do with standards, really.
IsStandard is just one of the functions which implement the node's policy.
It allows many things for which there is no standard (eg, data carrier / 
OP_RETURN outputs), and can vary freely from node to node (either by 
configurable parameters, or by different/modified software) without breaking 
consensus.

As it is a node-specific criteria, it is not itself even a possible *subject* 
for standards.

Additionally, it should not be given much (if any) attention when defining new 
standards. Just do what makes sense for the standard, and node policies can 
be adapted around that.

So, overall, there's limited use case for documenting this beyond the code.
It makes far more sense to document actual standards instead.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[ZmnSCPxj via bitcoin-dev]

Good morning Aymeric,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte  
wrote:

> I must badly explain my point (or just wondering things that do not
> exist finally), the question is indeed whether nodes will relay non
> usual transactions or not and how to know what they will accept or not:
>
> -   my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
> script, the redeem script still matches scriptpubkey and scriptsig will
> execute succesfully, that's a normal legacy P2SH or segwit P2WSH
>
> -   bch segwit recovery: it's a p2sh transaction without any signature
> verification, as far as I remember there was a story that it could not
> propagate in the network (even taking the risk to be stolen) and that
> people had to contact a (honest) miner
>
> -   sha bounties: same as above, p2sh transactions without signatures
>
> etc
>
> Will all of those transactions propagate normally? And then the rule is
> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
> whatever scripts you put inside?

P2PKH and P2WPKH cannot have custom script.
However, yes, any custom script can be wrapped in P2SH and P2WSH and it will be 
propagated.
The P2SH/P2WSH hides the details of your custom script so cannot be filtered 
based on your custom script.
Do realize that once a claim on your modified x-of-3 is propagated your 
`redeemScript` is known and someone can attempt to RBF (or coordinate with a 
miner) with a modified `witness` stack or `scriptSig` to claim your UTXO.
(I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of your 
signatories could make it a 1-of-3 and bribe a miner to get it claimed)

I cannot answer for BCH; arguably that is off-topic here.

The old SHA bounty transactions were propagated in the days before `isStandard` 
I think.
Either that or they were put in by miners.
An SHA bounty can still be propagated today if they are wrapped in a P2SH or 
P2WSH, but you have to publish the `redeemScript` yourself in some other method.
Or bribe a miner if the transaction is not time-sensitive (for an SHA bounty, 
unlikely to be time-sensitive).

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via bitcoin-dev]

I must badly explain my point (or just wondering things that do not
exist finally), the question is indeed whether nodes will relay non
usual transactions or not and how to know what they will accept or not:

- my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
script, the redeem script still matches scriptpubkey and scriptsig will
execute succesfully, that's a normal legacy P2SH or segwit P2WSH

- bch segwit recovery: it's a p2sh transaction without any signature
verification, as far as I remember there was a story that it could not
propagate in the network (even taking the risk to be stolen) and that
people had to contact a (honest) miner

- sha bounties: same as above, p2sh transactions without signatures

etc

Will all of those transactions propagate normally? And then the rule is
just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
whatever scripts you put inside?

Le 30/04/2019 à 06:29, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, April 29, 2019 5:30 PM, Aymeric Vitte  
> wrote:
>
>> ZmnSCPxj, OK, but you can put whatever you like in the different
>> standard output script you mention (my example below whether legacy or
>> segwit)
>>
> I am uncertain what you mean by this.
>
> For P2PKH and P2WPKH, you must present a hash of a public key.
> You cannot present a hash of anything else.
>
> The P2PKH template can be interpreted as a script, but is actually recognized 
> as a template by most current nodes (in a way that is consistent with 
> interpreting it as a script).
>
> For P2SH and P2WSH, you must present a hash of a script.
>
> It is more helpful to consider that *today* nodes recognize particular 
> patterns (P2PKH, P2WPKH, P2SH, P2WSH) as templates and not as scripts to be 
> executed.
>
> In any case, if you want to make anything more complicated than "single 
> signer" you should use P2SH or P2WSH regardless, and give your script.
> If you want to assure somebody that a particular P2SH or P2WSH commits to a 
> particular policy, just expose the policy script to them and have them (i.e. 
> their client software) verify that the policy is what the user wants and that 
> when hashed it matches the P2SH/P2WSH.
>
> As Luke said, nodes can have any policy for propagating transactions.
> However it is generally expected that P2PKH, P2WPKH, P2SH, and P2WSH will be 
> propagated by a majority of nodes, if only because those are reliably 
> "passed" by `isStandard` in the default latest Bitcoin Core and most people 
> will not modify the Core code.
>
> Generally, anything that isn't P2PKH, P2WPKH, P2SH, or P2WSH will not likely 
> be propagated by the network.
> You *could* still coordinate with one or more miners to get it mined: you can 
> put anything in the block, it is simply that most nodes will not inform 
> miners about transactions that do not pay out to P2PKH, P2WPKH, P2SH, or 
> P2WSH.
>
> Regards,
> ZmnSCPxj

-- 
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[ZmnSCPxj via bitcoin-dev]

Good morning Aymeric,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, April 29, 2019 5:30 PM, Aymeric Vitte  wrote:

> ZmnSCPxj, OK, but you can put whatever you like in the different
> standard output script you mention (my example below whether legacy or
> segwit)
>

I am uncertain what you mean by this.

For P2PKH and P2WPKH, you must present a hash of a public key.
You cannot present a hash of anything else.

The P2PKH template can be interpreted as a script, but is actually recognized 
as a template by most current nodes (in a way that is consistent with 
interpreting it as a script).

For P2SH and P2WSH, you must present a hash of a script.

It is more helpful to consider that *today* nodes recognize particular patterns 
(P2PKH, P2WPKH, P2SH, P2WSH) as templates and not as scripts to be executed.

In any case, if you want to make anything more complicated than "single signer" 
you should use P2SH or P2WSH regardless, and give your script.
If you want to assure somebody that a particular P2SH or P2WSH commits to a 
particular policy, just expose the policy script to them and have them (i.e. 
their client software) verify that the policy is what the user wants and that 
when hashed it matches the P2SH/P2WSH.

As Luke said, nodes can have any policy for propagating transactions.
However it is generally expected that P2PKH, P2WPKH, P2SH, and P2WSH will be 
propagated by a majority of nodes, if only because those are reliably "passed" 
by `isStandard` in the default latest Bitcoin Core and most people will not 
modify the Core code.

Generally, anything that isn't P2PKH, P2WPKH, P2SH, or P2WSH will not likely be 
propagated by the network.
You *could* still coordinate with one or more miners to get it mined: you can 
put anything in the block, it is simply that most nodes will not inform miners 
about transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] IsStandard

[ZmnSCPxj via bitcoin-dev]

Good morning Aymeric,

Different versions may consider different output scripts standard.

Your rule of thumb, post-SegWit, should be:

* If not P2PKH or P2WPKH, then wrap it in a P2SH or P2WSH.

There are more standard outputs accepted, but you can be reasonably sure that 
P2PKH, P2WPKH, P2SH, and P2WSH are the only standard output scripts that are 
likely to remain supported in the mid-future (5->10 years from 2019).

Lightning uses P2WSH for its scripts.

Any m-of-n signing scheme in Bitcoin is P2SH (usually) or P2WSH (if you are 
cool).


Regards,
ZmnSCPxj




Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, April 27, 2019 6:37 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

Re: [bitcoin-dev] IsStandard

[Aymeric Vitte via bitcoin-dev]

ZmnSCPxj, OK, but you can put whatever you like in the different
standard output script you mention (my example below whether legacy or
segwit)

Luke, I am still confused or missing something, from your answer I
understand that everything is accepted, so if we take the past example
of bch coins wrongly sent to a segwit address, why was the recovery
solution where scriptsig included the matching segwit address/program
not a standard transaction?

Le 29/04/2019 à 05:01, Luke Dashjr a écrit :
> On Saturday 27 April 2019 10:37:29 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
> The name is confusing. It has little to do with standards, really.
> IsStandard is just one of the functions which implement the node's policy.
> It allows many things for which there is no standard (eg, data carrier / 
> OP_RETURN outputs), and can vary freely from node to node (either by 
> configurable parameters, or by different/modified software) without breaking 
> consensus.
>
> As it is a node-specific criteria, it is not itself even a possible *subject* 
> for standards.
>
> Additionally, it should not be given much (if any) attention when defining 
> new 
> standards. Just do what makes sense for the standard, and node policies can 
> be adapted around that.
>
> So, overall, there's limited use case for documenting this beyond the code.
> It makes far more sense to document actual standards instead.
>
> Luke

s

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-core-dev] Bitcoin Core 0.18.0 released

[Marco Falke via bitcoin-core-dev]

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-core-dev mailing list
bitcoin-core-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev