Re: [bitcoin-dev] Bitcoin Core 24.1 released

[Sjors Provoost via bitcoin-dev]

There's a typo in the tracker subdomain: trakcer.bitcoin.sprovoost.nl 
 should be tracker.bitcoin.sprovoost.nl 
, but I'll just add that subdomain now.

- Sjors

> Op 19 mei 2023, om 12:56 heeft Michael Ford via bitcoin-dev 
>  het volgende geschreven:
> 
> Bitcoin Core version 24.1 is now available from:
> 
>  
> 
> Or through BitTorrent:
> 
>  
> magnet:?xt=urn:btih:ebb58d7495a8aaed2f20ec4ce3e5ae27aff69529=bitcoin-core-24.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftrakcer.bitcoin.sprovoost.nl%3A6969




signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot Fields for PSBT

[Sjors Provoost via bitcoin-dev]

Hi Andrew,

I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION
contain not just the derivation path for the xonlypubkey, but also the tapleaf 
merkle path.

First I thought it was perhaps necessary in order for a signer to guess which
script leaves it can sign with its own keys. But you can't really know that 
without
actually seeing the script. When a signer looks at a script, it presumably 
already
knows the leaf path.

- Sjors

> Op 22 jun. 2021, om 23:22 heeft Andrew Chow via bitcoin-dev 
>  het volgende geschreven:
> 
> Hi All,
> 
> I would like to propose a BIP which defines new fields for Taproot
> support in PSBT.
> 
> The full text is below, and the rendered file can be found at

Now at: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki 


> -
> | Taproot Key BIP 32 Derivation Path
> | PSBT_IN_TAP_BIP32_DERIVATION = 0x16
> | 
> | The 32 byte X-only public key
> |  * <32-bit uint> <32-bit uint>*
> | A compact size unsigned integer representing the number of leaf
> hashes, followed by a list of leaf hashes, followed by the master key
> fingerprint concatenated with the derivation path of the public key. The
> derivation path is represented as 32-bit little endian unsigned integer
> indexes concatenated with each other. Public keys are those needed to
> spend this output. The leaf hashes are of the leaves which involve this
> public key.

> |-
> | Taproot Key BIP 32 Derivation Path
> | PSBT_OUT_TAP_BIP32_DERIVATION = 0x07
> | 
> | The 32 byte X-only public key
> |  * <32-bit uint> <32-bit uint>*
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

[Sjors Provoost via bitcoin-dev]

Thanks for writing this up!

I think your modular BIP approach makes sense. (the abstract should mention 
this too)

Contents look good to me, modulo missing test vectors. I also suggest dropping 
combo(), see below.


Regarding the use of h vs ', especially since they result in a different 
checksum, and equality is more tedious to verify, should we just pick one and 
recommend that software normalises to that?

For bip-descriptors-segwit, regardless of what Bitcoin Core does, is any hex 
encoded script allowed for wsh()? If so is it mandatory and/or allowed to use 
raw() as a sub descriptor?

Conversely, its BIP says: "The raw(HEX) expression can only be used as 
a top level descriptor". That answers the above, but not the why.

In the backwards compatibility section it may be worth pointing out that 
descriptors are also used by:
* Specter since at least v1.2.2: 
https://github.com/cryptoadvance/specter-desktop/releases/tag/v1.2.2
* Coldcard since 2.0.1: 
https://github.com/Coldcard/firmware/commit/af00f8778947664f2d74f19879b98f7925feb327
* HWI since 1.0.3: https://github.com/bitcoin-core/HWI/releases/tag/1.0.3

None of these support the tr(), raw() and addr() descriptors afaik. HWI doesn't 
implement (sorted_)multi.

Does anyone actually use combo? It seems useless, because even with the help of 
BIP 88 there's no way to compress all three in a single descriptor, since BIP 
44/49/84 each have a different derivation. Afaik Bitcoin Core doesn't really 
use them either. And for future wallet migration, we might as well make 
separate descriptors for each key type.

One thing on my wish list - for this BIP, BIP 88 (Hierarchical Deterministic 
Path Templates) or yet another one - is to include a birth date (minimum block 
height). E.g. tr([m/86'/0'/0']xpub.../{0-1}/*)>709631

And then of course there's the gap limit. Perhaps we just need a "metadata" 
format to go along with descriptors to track the birth data, gap limit and 
anything else you need (nonce collection for musig2 setup?). E.g. a simple 
dictionary: tr([m/86'/0'/0']xpub.../{0-1}/*){dob:709631,gap:1000}

- Sjors


> Op 29 jun. 2021, om 23:14 heeft Andrew Chow via bitcoin-dev 
>  het volgende geschreven:
> 
> Hi All,
> 
> I've been working on formalizing the Output Script Descriptors that have
> been available in Bitcoin Core for a while into BIPs. Since descriptors
> are modular and have optional components, I've decided to split it into
> 7 BIPs, rather than a single one. The first describes descriptors in
> general and does not specify any particular descriptor. However it does
> describe the general operation, key expressions (including derivation
> paths and key origin info), and the descriptor checksum. The following 6
> BIPs specify the actual descriptors themselves. These are non-segwit
> descriptor (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig
> descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo
> descriptor, and opaque descriptors (raw, addr). This separation is so
> that implementors can choose to not implement some descriptors and still
> say which descriptors they support without being too difficult to
> understand.
> 
> The text of all of the documents are below, and they can also be found
> on github:https://github.com/achow101/bips/tree/descriptors/
> 
> Thanks,
> Andrew Chow
> 
> ---
> 
> 
>   BIP: bip-descriptors-general
>   Layer: Applications
>   Title: Output Script Descriptors General Operation
>   Author: Pieter Wuille 
>   Andrew Chow 
>   Comments-Summary: No comments yet.
>   Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-general
>   Status: Draft
>   Type: Informational
>   Created: 2021-06-27
>   License: BSD-2-Clause
> 
> 
> ==Abstract==
> 
> Output Script Descriptors are a simple language which can be used to
> describe collections ofoutput scripts.
> There can be many different descriptor fragments and functions.
> This document describes the general syntax for descriptors, descriptor
> checksums, and common expressions.
> 
> ==Copyright==
> 
> This BIP is licensed under the BSD 2-clause license.
> 
> ==Motivation==
> 
> Bitcoin wallets traditionally have stored a set of keys which are later
> serialized and mutated to produce the output scripts that the wallet
> watches and the addresses it provides to users.
> Typically backups have consisted of solely the private keys, nowadays
> primarily in the form of BIP 39 mnemonics.
> However this backup solution is insuffient, especially since the
> introduction of Segregated Witness which added new output types.
> Given just the private keys, it is not possible for restored wallets to
> know which kinds of output scripts and addresses to produce.
> This has lead to incompatibilities between wallets when restoring a
> backup or exporting data for a watch only wallet.
> 
> Further complicating matters are BIP 32 derivation paths.
> Although BIPs 44, 49, and 84 have specified standard BIP 32 derivation
> 

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Sjors Provoost via bitcoin-dev]

ACK for adding Kalle.

Recent drama aside, having a single editor is not ideal. There's currently 110 
open pull requests to the BIPs repo.

- Sjors

> Op 23 apr. 2021, om 04:09 heeft Luke Dashjr via bitcoin-dev 
>  het volgende geschreven:
> 
> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.
> 
> Since there is no explicit process to adding BIP editors, IMO it should be
> fine to use BIP 2's Process BIP progression:
> 
>> A process BIP may change status from Draft to Active when it achieves
>> rough consensus on the mailing list. Such a proposal is said to have
>> rough consensus if it has been open to discussion on the development
>> mailing list for at least one month, and no person maintains any
>> unaddressed substantiated objections to it.
> 
> A Process BIP could be opened for each new editor, but IMO that is
> unnecessary. If anyone feels there is a need for a new Process BIP, we can go
> that route, but there is prior precedent for BIP editors appointing new BIP
> editors, so I think this should be fine.
> 
> Please speak up soon if you disagree.
> 
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Sjors Provoost via bitcoin-dev]

Thanks for the detailed response. Just 1 thing I needed to clarify:

> To the list of concerns at the top of the BIP, I would add one: losing 
> multisig setup context. E.g. in the event of a fire where you only recover 
> your steel engraved mnemonic(s), but no longer have the wallet descriptors.
> 
> Good point.
> 
> 
> If you still have all devices and know (or guess) the threshold then BIP48 
> and sorted_multi descriptors will save you. But if you have a 2-of-3 setup 
> and lost 1 device then without the metadata your coins are lost. In a future 
> with musig(?) and miniscript increasingly the setup data is just as critical 
> as the seeds.
> 
> How so? Each signer device should ideally have a copy of the multisig 
> configuration. If you lose 1 device in a 2-of-3, you can still spend from the 
> wallet? Unless I'm missing something here.

I was thinking about a scenario where all devices are destroyed. All you have 
left are the mnemonics. But indeed if at least one of your devices is still 
intact AND it has the configuration, you're also good.

But there are plenty of devices out there that can't do this. Those devices can 
still be useful, even if they can't fully check everything.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Sjors Provoost via bitcoin-dev]

Hi all,

First of all thanks for your continued work on standardising multisig setup.

The use case I personally find most interesting is not a multi-party setup, but 
rather just combining a bunch of my own devices. Those might even be in the 
same room during the setup, only to be moved to my moon base later.

This means I've paid less attention to the encryption scheme, so I might set 
TOKEN=0, but nevertheless I am skeptical about it. The first step is for the 
Coordinator to generate a TOKEN, presumably using its own entropy. But IIUC 
anyone who intercepts that token can decrypt any future step in the setup 
process. This suggests a chicken-egg problem where you need some pre-existing 
secure communications channel.

To the list of concerns at the top of the BIP, I would add one: losing multisig 
setup context. E.g. in the event of a fire where you only recover your steel 
engraved mnemonic(s), but no longer have the wallet descriptors.

If you still have all devices and know (or guess) the threshold then BIP48 and 
sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 
1 device then without the metadata your coins are lost. In a future with 
musig(?) and miniscript increasingly the setup data is just as critical as the 
seeds.

A future standard (or extension of this one) should recommend an encryption 
convention for the descriptor data, ideally such that with *any* of the seeds 
you can decrypt a file that contains the full setup. That file could then just 
float redundantly around the internet and pieces of paper in various locations, 
without compromising privacy.

The proposed encryption system doesn't help with that though, because it's 
based on entropy from the Coordinator, rather than from the signers.


Smaller suggestions:
* link to this new mail thread in the BIP
* use magic bytes so .bsms so operating systems like Android / iOs can open the 
right app for them
* don't use separate file extensions for encrypted vs unencrypted content, just 
indicate somehow that a given field is encrypted
* although plain text files are handy for debugging, I think a binary format 
like PSBT is much powerful. Any device that can parse and write binary PSBT 
should be able to implement a similar parser / writer for a binary .bsms format.
* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scenario. 
The BIP uses both in the examples, but doesn't explictly endorse these 
derivations. It also contradicts them: "If the Signer chooses the path, it 
should try to avoid reusing XPUBs for different wallets.". Maybe this is out of 
scope.
   * one way to resolve xpub reuse would be to make the "BIP48" path a function 
of the co-signer fingerprints and wallet threshold, but this requires an extra 
communication round
* there should be a way for signers to communicate their capabilities, perhaps 
with a different xpub for each potential scheme. E.g. there's m/48' native 
SegWit now, MuSig and/or or Tapleaf based multisig in the future, or even 
generic Miniscript support.
* the idea of only storing the receive descriptor, not the change descriptor, 
is fine by me, though I'd prefer an extension to the descriptor format to deal 
with this

Sjors

> Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev 
>  het volgende geschreven:
> 
> Hi all,
> 
> Please find below the complete draft of the Bitcoin Secure Multisig Setup 
> (BSMS) BIP. The spec has gone through a number of important updates in the 
> last month or so. Thanks everyone who has participated in the review process.
> 
> As a PR: https://github.com/bitcoin/bips/pull/1097



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Sjors Provoost via bitcoin-dev]

Hey Pieter,

I think this is a reasonable collection of changes that make sense in 
combination. Some initial feedback and questions.

>From the BIP:
> If one or more of the spending conditions consist of just a single key (after 
> aggregation),
> he most likely one should be made the internal key. If no such condition 
> exists, it may
> be worthwhile adding one that consists of an aggregation of all keys 
> participating in all
> scripts combined; effectively adding an "everyone agrees" branch. If that is 
> inacceptable,
> pick as internal key a point with unknown discrete logarithm (TODO).

I assume Luke Dashjr referred to the above when saying:

> Is there any way to use the Taproot construct here while retaining external 
> script limitations that the involved party(ies) *cannot* agree to override? 
> For example, it is conceivable that one might wish to have an unconditional 
> CLTV enforced in all circumstances.


One reason why someone would want to avoid a "everone agrees" branch, is duress 
(or self-discipline, or limiting powers of a trustee). In particular with 
respect to time-locks.

Can this "unknown discrete logarithm" be made provably unknown, so all signers 
are assured of this property? Bonus points if the outside world can't tell. The 
exact mechanism could be outside the scope of the BIP, but knowing that it's 
possible is useful.

Perhaps Lightning devs have an opinion on "everyone agrees" with respect to 
hash pre-images. I suspect there is no benefit in guaranteeing that a pre-image 
must be revealed or a timeout must be waited for and there's no way around that 
condition.


Regarding usage of Schnorr: do I understand correctly that the "everyone 
agrees" internal key MUST use Schnorr, and that individual branches MAY use 
Schnorr, but only if they're marked as tapscript spend?

Why is tapscript not mandatory?


Misc details:

In the Design section under "Merkle branches" I suggest adding bullet points 
with short descriptions of "various known mechanisms for implementing this". In 
addition to "space savings" maybe also briefly mention a few other pros and 
cons, like implementation complexity and privacy. And then point out which one 
you picked.

In the Design section, explicitly point out you're no longer using the hash of 
a public key (can move some explanation up from rationale section). This is a 
significant change, even if you have good reason to believe it's perfectly safe.

Regarding the 64 byte SHA256(tag) || SHA256(tag) 64-byte long context-specific 
constant: maybe add that sha-2 block size is 512 bits

"Conceptually every Taproot output corresponds to" -> some of this conceptual 
stuff belongs in or before the Specification section. Try briefly explaining 
how tagged hashes and script validation (stack) interact, before specifying 
them in detail. The figure (without the pseudo-code) can be helpful for that. 

In the figure with the merkle tree, the description says there's "3 script 
leaves.". So what's going on in leaf D? If it's a way to indicate an unused 
leaf, why is E different (or is also TapLeaf)? Maybe emphasize that "TapLeaf" 
tag is there so prove to all signers there's no secret conditions (the 
CVE-2012-2459 protection you refer to).

Sjors


> Op 6 mei 2019, om 22:17 heeft Luke Dashjr via bitcoin-dev 
>  het volgende geschreven:
> 
> There are multiple references to "space savings", but no rationale for 
> treating "space" as something to save or even define. The costs are in CPU 
> time and I/O (which "space saving" doesn't necessarily reduce) and bandwidth 
> (which can often be reduced without "space saving" in commitments). The 
> proposal can apparently be made simpler by ignoring this irrelevant "space 
> saving" goal.
> 
> Tagged hashes put the tagging at the start of the hash input. This means 
> implementations can pre-cache SHA2 states, but it also means they can't reuse 
> states to produce data for different contexts. (I'm not sure if there is a 
> use for doing so... but maybe as part of further hiding MAST branches?)
> 
> Is there any way to use the Taproot construct here while retaining external 
> script limitations that the involved party(ies) *cannot* agree to override? 
> For example, it is conceivable that one might wish to have an unconditional 
> CLTV enforced in all circumstances.
> 
> It may be useful to have a way to add a salt to tap branches.
> 
> Some way to sign an additional script (not committed to by the witness 
> program) seems like it could be a trivial addition.
> 
> 
> On Monday 06 May 2019 17:57:57 Pieter Wuille via bitcoin-dev wrote:
>> Hello everyone,
>> 
>> Here are two BIP drafts that specify a proposal for a Taproot
>> softfork. A number of ideas are included:
>> 
>> * Taproot to make all outputs and cooperative spends indistinguishable
>> from eachother.
>> * Merkle branches to hide the unexecuted branches in scripts.
>> * Schnorr signatures enable wallet software to use key
>> aggregation/thresholds 

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Sjors Provoost via bitcoin-dev]

> (1) It has been well documented again and again that there is desire to 
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in 
> non-segwit scripts represents a rather significant vulnerability in Bitcoin 
> today, and (3) lots of effort has gone into attempting to find practical 
> use-cases for OP_CODESEPARATOR's specific construction, with no successes as 
> of yet. I strongly, strongly disagree that the highly-unlikely remote 
> possibility that someone created something before which could be rendered 
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
> 
>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases 
>> the transactions weight suitably as to temper the vulnerability caused by 
>> it.  Alternatively there could be some sort of limit (maybe 1) on the 
>> maximum number of OP_CODESEPARATORs allowed to be executed per script, but 
>> that would require an argument as to why exceeding that limit isn't 
>> reasonable.
> 
> You could equally argue, however, that any such limit could render some 
> moderately-large transaction unspendable, so I'm somewhat skeptical of this 
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined 
> is rather difficult in any case.

Although I'm not a fan of extra complicity, just to explore these two ideas a 
bit further.

What if such a transaction:

1. must have one input; and
2. must be smaller than 400 vbytes; and
3. must spend from a UTXO older than fork activation

Adding such a contextual check seems rather painful, perhaps comparable to 
nLockTime. Anything more specific than the above, e.g. counting the number of 
OP_CODESEPARATOR calls, seems like guess work.

Transaction weight currently doesn't consider OP codes, it only considers if 
bytes are part of the witness. Changing that to something more akin to 
Ethereums gas pricing sounds too complicated to even consider.


I would also like to believe that whoever went through the trouble of using 
OP_CODESEPARATOR reads this list.

Sjors

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

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

[Sjors Provoost via bitcoin-dev]

Can you elaborate a bit on what kind of reject messages your users are getting? 
I assume the users wallet connects directly to the Bitcoin p2p network?

What does the wallet do when a transaction is rejected? Does it forget about it 
(that seems unsafe) or compose another one (with overlapping inputs)?

Sjors

> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev 
>  het volgende geschreven:
> 
> Reject messages cannot be replaced for debugging user problems. At least
> unless you plan to make RPC or bitcoind logfiles available via the P2P
> protocol (both probably not a good idea).
> 
> The typical case is, I get mailed a wallet logfile with reject messages
> and that's all I have. I cannot access the bitcoind logfile(s) of the
> node(s) that generated the reject message in the first place. Nor can I
> access their RPC interface.
> 
> I strongly suggest re-enabling reject messages by default before 0.18.
> 
> 
> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
>> 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

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

Re: [bitcoin-dev] BIP proposal - addrv2 message

[Sjors Provoost via bitcoin-dev]

Concept ACK.

> ==Considerations==
> 
> (to be discussed)
> 
> * ''Client MAY store and gossip address formats that they do not know 
> about'': does it ever make sense to gossip addresses outside a certain 
> overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for 
> networks that have no exit nodes as there is no overlap with the globally 
> routed internet at all.

What exactly do you mean by "do not know about"? It could mean:

1. A new Network ID was recently introduced which an older node doesn't about.

In that case the node won't even know the address length, so it can't parse the 
entry.

In fact it can't parse the entire address message if a single address has an 
unknown format. Maybe require a single address type per ADDR2 message?

2. The Network ID doesn't match the network the node received this message on

The node should probably be agnostic about where it received this information 
from.

3. The node currently doesn't support a Network ID

But what does that mean? No connection? An explicitly disabled setting? A 
missing dependency? The operating system doesn't support it?

I think "MAY" is the correct choice for storing for (2).

For (3) I think it makes sense for nodes to store information even if they're 
disconnected, but not if they have a setting disabled or no driver. Though that 
implementation detail doesn't seem relevant to the standard.


I don't think it's a good idea to gossip information you can't at least in 
theory verify, but we already do that with Tor V2. It's useful to gossip 
information about other networks to help e.g. IPv4 nodes bootstrap Tor 
connections. On the other hand, that could also help an attacker link them. We 
could recommend that with addrv2 the node should make sure gossip messages were 
received on the correct interface, but that may not be practical.

> * Lower precision of time field? seconds precision seems 
> overkill, and can even be harmful, there have been attacks that exploited 
> high precision timestamps for mapping the current network topology.
> 
> ** (gmaxwell) If you care about space time field could be reduced to 16 bits 
> easily.  Turn it into a "time ago seen" quantized to 1 hour precision. (IIRC 
> we quantize times to 2hrs regardless).

That seems like a good idea.

> * (gmaxwell) Optional (per-service) data could be useful for various things:
> [...]
> ** If we want optional flags. I guess the best thing would just be a byte to 
> include the count of them, then a byte "type" for each one where the type 
> also encodes if the payload is 0/8/16/32 bits. (using the two MSB of the type 
> to encode the length).  And then bound the count of them so that the total is 
>  still reasonably sized.

Adding more information seems useful, though also creates more topology mapping 
opportunities.

- Sjors

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

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

[Sjors Provoost via bitcoin-dev]

> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev 
>  het volgende geschreven:
> 
> ==Motivation==
> 
> One of the most powerful heuristic's employed by those whose goal is to 
> undermine
> bitcoin's fungiblity has been to assume all inputs of a transaction are 
> signed by
> a single party. In the few cases this assumption does not hold, it is 
> generally
> readibly recognizable (e.g. traditional coinjoins have a very obvious 
> structure,
> or multisig outputs are most frequently validated onchain).

In addition to mixers, custodial wallets and exchanges also contribute to 
breaking this heuristic; even though there’s a single entity signing multiple 
inputs, that entity doesn’t represent a single owner of the funds. As with 
mixers, exchanges and custodial wallets can sometimes be spotted as well, but 
we don’t know what percentage is missed.

Breaking this heuristic at scale would be good, but do we know to what degree 
it’s already broken? Is there any empirical research measuring its accuracy and 
false positive rate?

> Should bustapay enjoy widespread adoption, a "v2" specification
> will be created with desired extensions.

I would not put future promises in a BIP. Rather, explain how extension might 
work.

> ==Specification==
> 
> A bustapay payment is made from a sender to a receiver.
> 
> Step 1. Sender creates a bitcoin transaction paying the receiver
> 
> This transaction must be fully valid, signed and all inputs must use segwit. 
> This transaction is known as the "template transaction”.

Using PSBT?

> This transaction must not be propagated on the bitcoin network.

This can’t be guaranteed, and even after step 5 a reorg could cause it to get 
confirmed. It’s useful to explain why this doesn’t matter.

> 
> Step 2. Sender gives the "template transaction" to the receiver
> 
> This would generally be done as an HTTP POST.
> The exact URL to submit it to could be specified with a bip21 encoded 
> address. Such as 
> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit
>   and the HTTP body should be the raw 
> transaction hex encoded as text.

This seems too detailed. If you want to specify the message protocol, maybe 
that can have it’s own section where you list each of the messages, the URL, 
parameters and encoding. Then you can keep this overview section shorter.

The use of HTTPS kind of forces sender and recipient to use a 3rd party 
service, even though this could done bilaterally. What if the payment request 
contained a (single-use) Onion URL an expiration date? The recipient would have 
to keep a hidden service up until the expiration date, though the sender could 
try again if there’s temporary reachability issue.

Adding a (onion) URL to the the payment request also makes gradual adoption 
easier, because recipients don’t need to worry if senders support this protocol.

> Step 3. Receiver processes the transaction and returns a partially signed 
> coinjoin
> 
> The receiver validates the transaction is valid, pays himself and is eligible 
> for propation. The receiver then adds one of his own inputs (known as the 
> "contributed input") and increase the output that pays himself by the 
> contributed input amount. Doing so will invalidate the "template 
> transaction"'s original input signatures, so the sender needs to return this 
> "partial transaction" back to the receiver to sign. This is returned as a 
> hex-encoded raw transaction a response to the original HTTP POST request.

> * Bustapay could be abused by a malicious party to query if you own a deposit 
> address or not. So never accept a bustapay transaction that pays an already 
> used deposit address


Indeed, once the recipient adds funds, they reveal more about themselves to the 
sender then they would otherwise. I think that needs more elaboration.

I assume the transaction in step (1) is some sort of collateral to insure 
they’re not just trying to extract private information from you? However if 
fees are low they could still double-spend it after the recipient revealed 
their address, especially because the recipient has no way of RBF’ing the 
original (though CPFP could help). Perhaps require that the original 
transaction pays a fee based on the expected size of the final transaction?

> 
> Notes for sending applications:
> 
> * The HTTP response must *not* be trusted. It should be fully validated that 
> no unexpected changes have been made to the transaction.

Not trusting anything is obvious. :-) It’s better to explicitly state what 
exactly needs to be verified (amounts, destinations, inputs, etc), and maybe 
list a few obvious shenanigans to watch out for.

A more general concern is that the sender can’t know for sure the recipient 
really supports this protocol, so it should assume that whatever information it 
pings to some API could be used maliciously. In what ways could it be abused?

Sjors


signature.asc
Description: 

Re: [bitcoin-dev] Schnorr signatures BIP

[Sjors Provoost via bitcoin-dev]

> Op 6 jul. 2018, om 20:08 heeft Pieter Wuille via bitcoin-dev 
>  het volgende geschreven:
> 
> Hello everyone,
> 
> Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> over the same curve as is currently used in ECDSA:
> https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki

The power of simplification at work, thanks Pieter!

Questions:

Regarding verification: why does bytes(P) use compressed key serialization 
rather than the implicit Y coordinate used for signing? I understand space 
savings don't matter since these values don't end up on the blockchain. Is it 
just easier to implement or is it faster?

Regarding rationale for choosing (e,s) vs. (R,s), you say that (e,s) "avoids 
the difficulty of encoding a point R in the signature". But since e = H(sG - eP 
|| m) also involves converting a point to some byte encoding in order to hash 
it, how much difficulty is actually avoided? Is that, like for previous 
question, because you could get away with compressed keys rather than implicit 
Y coordinates?

Regarding batch verification: "randomly generated independently for each batch 
of verifications" - by whom? I assume randomly picked by the verifier?

Regarding random number used for signing. The suggested (?) deterministic 
algorithm to derive secret key ''k'' from the private key ''d''  seems similar 
to RFC6979. Maybe it's useful to briefly explain the difference, as well as 
your rationale for not making it mandatory (presumably the same as why RFC6979 
isn't mandatory although most (?) wallets use it).

Nits:

* Motivation: "signatures ... These are standardized", but the "standardized" 
link points to the secp256k1 curve parameters, not to anything signature 
related afaik
* "message m: an array of 32 bytes", maybe add "typically the sha256 hash of 
the transaction components commited to by SIGHASH_TYPE”
* I left a few even smaller nits as a PR: https://github.com/sipa/bips/pull/10

Cheers,

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Sjors Provoost via bitcoin-dev]

> Op 22 feb. 2018, om 13:19 heeft Ryan Grant via bitcoin-dev 
>  het volgende geschreven:
> 
> On Fri, Feb 9, 2018 at 7:29 AM, Jeremy  wrote:
>> utility of this construction can be improved if we introduce functionality
>> that makes a script invalid after a certain time
> 
> Tagging this thread with "nExpiryTime".  Search archives for more.

Fill-or-kill transaction was the term used on the list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011042.html
 


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

Re: [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set

[Sjors Provoost via bitcoin-dev]

eMMC storage, which low end devices often use, come in 2x increments. Running a 
pruned full node on 8 GB is difficult if not impossible (the UTXO set peaked at 
3.5 GB in January, but a full node stores additional stuff).

However, 16 GB is only €10 more expensive and presumably standard by the time 
this would be rolled out.

On AWS every GB of SSD storage avoided saves $1 per year, not end of the world 
stuff, but not negligible either. Outbound traffic costs $0.10 / GB (ignoring 
free allowance), so when uploading 200 GB per year, the 5% would offset $1 of 
storage cost savings.

The above seems marginal, probably not worth it unless there’s really no 
downside.

What I find attractive about this proposal is the ability to squeeze more out 
of limited RAM (typically only 1 or 2 GB on these low end devices). I’d have to 
test Cory’s branch to see if that actually matters in practice.

It’s also useful to distinguish benefits during initial sync from ongoing 
operation. The former I’ve almost given up on for  low end devices (can take 
weeks), in favor of doing it on a faster computer and copying the result. The 
latter needs far less RAM, so perhaps this proposal doesn’t help much there, 
but that would be useful to measure.

Did you try the recent SHA256 optimizations on your branch?

Sjors

> Op 17 mei 2018, om 18:56 heeft Gregory Maxwell via bitcoin-dev 
>  het volgende geschreven:
> 
> On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev
>  wrote:
>> Tl;dr: Rather than storing all unspent outputs, store their hashes.
> 
> My initial thoughts are it's not _completely_ obvious to me that a 5%
> ongoing bandwidth increase is actually a win to get something like a
> 40% reduction in the size of a pruned node (and less than a 1%
> reduction in an archive node) primarily because I've not seen size of
> a pruned node cited as a usage limiting factor basically anywhere. I
> would assume it is a win but wouldn't be shocked to see a careful
> analysis that concluded it wasn't.
> 
> But perhaps more interestingly, I think the overhead is not really 5%,
> but it's 5% measured in the context of the phenomenally inefficient tx
> mechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).
> Napkin math on the size of a txn alone tells me it's more like a 25%
> increase if you just consider size of tx vs size of
> tx+scriptpubkeys,amounts.  If I'm not missing something there, I think
> that would get in into a very clear not-win range.
> 
> On the positive side is that it doesn't change the blockchain
> datastructure, so it's something implementations could do without
> marrying the network to it forever.
> 

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

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Sjors Provoost via bitcoin-dev]

I can see how merging after the fact could be more practical than appending 
existing transactions.

I think what Moral Agent suggested is the same as your original proposal, 
namely dropping rule 3. Only fee per weight unit increase from rule 4 would 
matter.

The minimum per WU increase could be far higher than the minimum relay fee. The 
few times I’ve used RBF in practice I increased the fee by at least 50%. Rule 4 
could be made more strict. I don’t know what number, if any, would address 
concerns about relay spam?

This wouldn’t be backward compatible. Does that matter as long as there’s 
enough nodes that follow the new rules? Is there a punishment for relaying 
transactions that violate rule 3? Could a recipient using the older rules be 
mislead (in a way that’s worse than the fact that RBF allows the sender to 
replace the transaction with anything they want anyway)?

Peter Todd wrote:
> You'd also be able to push others' txs out of the mempool.
Can you elaborate on this issue?

And wrote:
> payment service for instance where a large number of deposits are aggregated 
> into a smaller number of payments

So this would involve wallets (of users who deposit coins) cooperating with an 
exchange API to consolidate in-mempool transactions?

And wrote:

> In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.

Why would you need to consider the whole mempool? Let’s say a miner is 
considering to replace transaction A and B with transaction C, where C pays a 
higher fee per byte than both A and B. This creates space for ~ one additional 
transaction in the block. It seems to me the miner only needs to check that the 
lowest fee per weight transaction > min_fee(A,B). At least in first 
approximation.

Sjors

> Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev 
>  het volgende geschreven:
> 
> 
>> I'm confused, the mempool only sees 1 transaction at a time, first A, then 
>> later B. "the original transactions", plural, should not exist in the 
>> mempool.
>> 
>> B's fee and rate needs to be larger than A's, but B will be greater than or 
>> equal to A anyway. So, just increasing the fee rate will cause a larger fee 
>> anyway.
>> 
>> Am I missing something?
> 
> Kind of. The first case is that you do the "smarter" type of merging, where 
> you get an original transaction and then say add an additional output(s) to 
> it.
> 
> The issue with this, is from a practical perspective is _very_ complex. 
> Because you really need to do a lot of tracking to see which of the two 
> transactions actually confirm. And if you are promising fast payments, you 
> can be stuck in a weird limbo state where you're waiting for the original one 
> to "safely" confirm before it's safe to make a re-payment (even a 
> non-malicious will likely contain the replacement).
> 
> bip125 already supports this use-case, but I will suggest that the logic to 
> deploy this is sufficiently complex that no one is going to attempt any time 
> in the near future.
> 
> 
> But "retroactive transaction merging" is actually pretty approachable problem 
> for a service to implement. You just get N valid transactions you've made, 
> merge them into one. Strip extraneous inputs[1], and combine and alter the 
> change amount.
> 
> The reason this is so appealing to implement, is there is very little 
> complexity. If the "retroactive transaction merge" fails, or doesn't get 
> confirmed, it actually has no impact. If it does get confirmed, that's just 
> pure cost-savings.
> 
> However, the rules of bip125 currently make it (unnecessarily?) unappealing, 
> because I can never lower the absolute amount of fees I pay. Hence I think 
> it'd be pretty sweet if they could be relaxed to support this if it can be 
> done in a pretty risk free way.
> 
> 
> 
> [1] Need to be very careful with that, if you're ever merging a merged 
> transaction.
> 
> 
>> 
>> 
>> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev 
>>  wrote:
>>> On Tue, Jan 23, 2018 at 10:49:34PM +, Gregory Maxwell via bitcoin-dev 
>>> wrote:
 On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
  wrote:
> Interesting. I didn't think about this before, but it seems like bip125 is
> rather incentive incompatible right now? If we're assuming a competitive
> mempool, it really doesn't seem generally rational to accept a replacement
> transaction of a lower fee rate.
 
 BIP125 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Sjors Provoost via bitcoin-dev]

I don’t know about Electrum but many wallets validate the English words, which 
helps in catching typos.

Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even 
let you freely type characters; you have to select words from a list.

So although the standard technically allows what you say, if you use anything 
other than 12, 16 or 24 English words, you’ll have fewer wallets to choose from.

I think it’s better to come up with a new standard than trying to patch BIP-39 
at this point, which is why I brought it up.

Sjors

> Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanev...@gmail.com> het 
> volgende geschreven:
> 
> "Very few wallets support anything other than English"
> 
> By support do you mean allow recovery, validation or generation or all three? 
> For if you can freely type a phrase in (such as Electrum), or even word by 
> word, then the likely-hood is it is supported if they remembered to normalize.
> 
> Seed generation in BIP0039 requires no dictionary what-so-ever! So there is 
> no word list to lose in the first place. Your funds are accessible with just 
> the characters and the algorithm as described in BIP0039.
> 
> But your proposal is a million miles away from simply adding some standard 
> in-language names to some word lists feels like it's derailing the OP's 
> simple proposal. Maybe start own email chain about it.
> 
> Alan
> 
> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> I’m not a fan of language specific word lists within the current BIP-39 
> standard. Very few wallets support anything other than English, which can 
> lead to vendor lock-in and long term loss of funds if a rare non-English 
> wallet disappears.
> 
> However, because people can memorize things better in their native tongue, 
> supporting multiple languages seems quite useful.
> 
> I would prefer a new standard where words are mapped to integers rather than 
> to a literal string. For each language a mapping from words to integers would 
> be published. In addition to that, there would be a mapping from original 
> language words to matching (in terms of integer value, not meaning) English 
> words that people can print on an A4 paper. This would allow them to enter a 
> mnemonic into e.g. a hardware wallet that only support English. Such lists 
> are more likely to be around 100 years from now than some ancient piece of 
> software.
> 
> This would not work with the current BIP-39 (duress) password, but this 
> feature could be replaced by appending words (with or without a checksum for 
> that addition).
> 
> A replacement for BIP-39 would be a good opportunity to produce a better 
> English dictionary as Nic Johnson suggested a while ago:
> • all words are 4-8 characters
> • all 4-character prefixes are unique (very useful for hardware 
> wallets)
> • no two words have edit distance < 2
> 
> Wallets need to be able to distinguish between the old and new standard, so 
> un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the 
> same time, some new wallets may not wish to support BIP39. They shouldn't be 
> burdened with storing the old word list.
> 
> A solution is to sort the new word list such that reused words appear first. 
> When generating a mnemonic, at least one word unique to the new list must be 
> present. A wallet only needs to know the index of the last BIP39 overlapping 
> word. They reject a proposed mnemonic if none of the elements use a word with 
> a higher index.
> 
> For my above point and some related ideas, see: 
> https://github.com/satoshilabs/slips/issues/103
> 
> Sjors
> 
> > Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev 
> > <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> >
> > I propose and request as an enhancement that the BIP 39 wordlist set should 
> > specify canonical native language strings to identify each wordlist, as 
> > well as short ASCII language codes.  At present, the languages are 
> > identified only by their names in English.
> >
> > Strings properly vetted and recommended by native speakers should 
> > facilitate language identification in user interface options or menus.  
> > Specification of language identifier strings would also promote interface 
> > consistency between implementations; this may be important if a user 
> > creates a mnemonic in Implementation A, then restores a wallet using that 
> > mnemonic in Implementation B.
> >
> > As an independent implementer who does not know *all* these different 
> > languages, I monkey-pasted language-native strings 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Sjors Provoost via bitcoin-dev]

I’m not a fan of language specific word lists within the current BIP-39 
standard. Very few wallets support anything other than English, which can lead 
to vendor lock-in and long term loss of funds if a rare non-English wallet 
disappears.

However, because people can memorize things better in their native tongue, 
supporting multiple languages seems quite useful.

I would prefer a new standard where words are mapped to integers rather than to 
a literal string. For each language a mapping from words to integers would be 
published. In addition to that, there would be a mapping from original language 
words to matching (in terms of integer value, not meaning) English words that 
people can print on an A4 paper. This would allow them to enter a mnemonic into 
e.g. a hardware wallet that only support English. Such lists are more likely to 
be around 100 years from now than some ancient piece of software.

This would not work with the current BIP-39 (duress) password, but this feature 
could be replaced by appending words (with or without a checksum for that 
addition).

A replacement for BIP-39 would be a good opportunity to produce a better 
English dictionary as Nic Johnson suggested a while ago:
• all words are 4-8 characters
• all 4-character prefixes are unique (very useful for hardware wallets)
• no two words have edit distance < 2

Wallets need to be able to distinguish between the old and new standard, so 
un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the 
same time, some new wallets may not wish to support BIP39. They shouldn't be 
burdened with storing the old word list.

A solution is to sort the new word list such that reused words appear first. 
When generating a mnemonic, at least one word unique to the new list must be 
present. A wallet only needs to know the index of the last BIP39 overlapping 
word. They reject a proposed mnemonic if none of the elements use a word with a 
higher index.

For my above point and some related ideas, see: 
https://github.com/satoshilabs/slips/issues/103

Sjors

> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev 
>  het volgende geschreven:
> 
> I propose and request as an enhancement that the BIP 39 wordlist set should 
> specify canonical native language strings to identify each wordlist, as well 
> as short ASCII language codes.  At present, the languages are identified only 
> by their names in English.
> 
> Strings properly vetted and recommended by native speakers should facilitate 
> language identification in user interface options or menus.  Specification of 
> language identifier strings would also promote interface consistency between 
> implementations; this may be important if a user creates a mnemonic in 
> Implementation A, then restores a wallet using that mnemonic in 
> Implementation B.
> 
> As an independent implementer who does not know *all* these different 
> languages, I monkey-pasted language-native strings from a popular wiki site.  
> I cannot guarantee that they be all accurate, sensible, or even 
> non-embarrassing.
> 
> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
> ```
>   LANG(english,   u8"English","en",   ascii_space ),
>   LANG(chinese_simplified,u8"汉语", "zh-CN",ascii_space ),
>   LANG(chinese_traditional,   u8"漢語", "zh-TW",ascii_space ),
>   LANG(french,u8"Français",   "fr",   ascii_space ),
>   LANG(italian,   u8"Italiano",   "it",   ascii_space ),
>   LANG(japanese,  u8"日本語","ja",   u8"\u3000"  ),
>   LANG(korean,u8"한국어","ko",   ascii_space ),
>   LANG(spanish,   u8"Español","es",   ascii_space )
> ```
> 
> Per the comment at #L85 of the quoted file, I also know that for my short 
> identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar 
> as Hong Kong uses Traditional; and overseas Chinese may use either.  For 
> differentiating the two Chinese writing variants, are there any appropriate 
> standardized or customary short ASCII language IDs similar to ISO 3166-1 
> alpha-2 which are purely linguistic, and not fit to present-day political 
> boundaries?
> 
> My general suggestion is that the specification of appropriate strings in 
> bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for 
> accepting new wordlists.  My specific request is that such strings be 
> ascertained for the wordlists already existing, preferably from the persons 
> involved in the original pull requests therefor.
> 
> Should this proposal be “concept ACKed” by appropriate parties, then I may 
> open a pull request suggesting an appropriate format for specifying this 
> information in the repository.  However, I will must needs leave the vetting 
> of appropriate strings to native speakers or 

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Sjors Provoost via bitcoin-dev]

Just to clarify two points:

> The good part is that it does not have to be adopted by exchanges. If popular 
> exchanges do not adopt it, it is trivial to make an adapter service which 
> translate COX to whatever proprietary API of the exchange.

Be sure to elaborate on the difference in trust assumptions between a merchant 
running such an adapter on their own infrastructure vs. trusting a SAAS that 
sits in between the exchange and the merchants infrastructure.

In general adapters would create additional risks to think about, depending on 
how fine-tuned the API key permissions are. E.g. if API keys come with full 
permissions you don’t want to install an adaptor plugin if your shop is hosted 
on wordpress.com. PayPal and Stripe make sure their API keys can’t do too much 
damage in case the merchant shop hosting is compromised.

> > Can this be combined with an invoice mechanism similar to Lightning, e.g. 
> > where the exchange sends a pre-image to the users wallet (relayed via and 
> > retained by the web shop) upon receipt of the funds, which they can then 
> > present to the merchant in case something went wrong. Exchanges might be 
> > happy to support this protocol, but they don’t want the burden of dealing 
> > with user support requests, so having signed invoices could help with that.
> 
> This protocol can be expanded later for lightning trivially, where the call 
> to the address source uri also returns a lightning payment request. (BOLT11)

I didn’t mean adding Lightning support (though that would be cool), I mean 
adding an invoice system to your proposal that is similar to how Lightning 
invoices work. Right now if the customer pays and the merchant has a poorly 
functioning shopping cart system, which I’ve seen more often than not, the 
customer would have to email their transaction id to the merchant, who then 
needs to login to their exchange to check if that address indeed belongs to 
them. But a merchant shouldn’t give all their support staff such access, and 
support staff may not have the right training, or even permission, to assess 
whether a transaction is cleared (“computer says no").

So you’d want some sort of signed message as part of the protocol that says “if 
this transaction ID confirms, this order ID is paid for”.   Although this 
specific example wouldn’t play well with RBF. So maybe “if the confirmed 
balance of this address is >= X, this order ID is paid for”, but then the 
exchange can’t sweep it. So maybe instead you need a callback from the exchange 
to just tell you when it’s (expected to be) confirmed. BitPay offers merchants 
various risk settings for this, so that might be worth looking into.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Sjors Provoost via bitcoin-dev]

I think this could be quite useful, although I don’t know if it will get 
adopted. If any such small local exchanges want to weigh in on this proposal, 
that would help. Same goes for shopping cart integrators, e.g. the folks 
writing WooCommerce and Shopify plugins.

Consider adding some requirements around the use of SSL and certificate 
pinning. Can you refer to the kind of best practices Stripe and PayPal 
recommend? Should some additional shared-secret or cookie / macaroon based 
authentication be added?

Can you clarify if this integration can run in a browser, or due to security / 
privacy constraints must be server-to-server?

Though it’s important to remain future-proof by being flexible, leaving the 
above details to individual implementers is probably going to result in bad 
things.

What are your thoughts on rate limiting vs. privacy? Should a payment source 
never return the same address even if nothing is paid to it? Otherwise someone 
could just crawl webshops to create an inventory of payment addresses. A new 
address every page reload could be a DDOS vector. It also wouldn't be 
compatible with BIP44 because of its gap limit, although I don’t think that’s a 
huge problem for exchanges.

Can this be combined with an invoice mechanism similar to Lightning, e.g. where 
the exchange sends a pre-image to the users wallet (relayed via and retained by 
the web shop) upon receipt of the funds, which they can then present to the 
merchant in case something went wrong. Exchanges might be happy to support this 
protocol, but they don’t want the burden of dealing with user support requests, 
so having signed invoices could help with that.

I would consider a more specific name like Delegated UTXO or something. 
“Exchange” suggests is more like 0X or Bisq.

Speaking of Bisq, it would be neat if merchants can rely on random peer to peer 
counterparties to convert to fiat, so their customer information and revenue 
figures aren’t in the hands of a single counter party. Obviously that’s a can 
of worms today, but it would be nice if the protocol was able to support that 
if one day someone figures out the fraud, compliance and bookkeeping stuff.

Finally, why only exchanges? It could make sense fo shopping cart software to 
talk to a Bitcoin wallet that’s hosted somewhere else for similar reasons. 
Right now the best these plugins can do is hold on to an XPUB, and I’ve even 
seen solutions that just send the customers coins to their own backend wallet 
and then forward it.

Sjors

> Op 20 dec. 2017, om 07:28 heeft Nicolas Dorier via bitcoin-dev 
>  het volgende geschreven:
> 
> Hi everyone,
> 
> As some of you know, I am working on a complete open source replacement of 
> Bitpay for allowing merchant to accept cryptocurrency payments while having a 
> way to sell automatically.
> 
> A crucial, missing part, is fiat conversion. And I figured out a simple 
> protocol that exchanges (or adapters) can implement to allow any merchant to 
> cash out BTC in fiat while giving them the freedom to choose their own 
> payment processor solution.
> 
> This also have positive impact on scalability: Before, a merchant would 
> receive the bitcoin from the customer then would send to the exchange, 
> resulting in two transactions.
> With this specification, it would be one transaction.
> 
> Special thanks to anditto and kallewoof for reviewing. I am waiting for your 
> feedback:
> 
> Github link: 
> https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawiki 
> 
> 
> 
>   BIP: XXX
>   Layer: Applications
>   Title: Crypto Open Exchange Protocol (COX)
>   Author: Nicolas Dorier  >
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX 
> 
>   Status: Draft
>   Type: Standards Track
>   Created: 2017-12-20
>   License: BSD-3-Clause
>CC0-1.0
> 
> 
> ==Abstract==
> 
> A simple protocol for decoupling payment processor solutions from exchanges.
> 
> ==Motivation==
> 
> Cryptocurrency merchant adoption is mainly driven by availability, ease of 
> use and means of acceptance.
> We call such solutions `Payment Processors`.
> 
> Until now, payment processing solutions fall into one of the two following 
> categories:
> 
> # Self-hosted with the customer paying in cryptocurrency and the merchant 
> receiving it directly.
> # Centralized, coupled with an exchange feature, with the customer paying in 
> cryptocurrency to the merchant, and receiving fiat or cryptocurrency on his 
> exchange account.
> 
> The self-hosted solution has two issues:
> 
> # The merchant becomes vulnerable to the wild volatility of cryptocurrencies.
> # It is wasteful of blockchain space, if the merchant does not pay suppliers 
> in crypto, as they need a 

Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?

[Sjors Provoost via bitcoin-dev]

Have you thought about combining this with BIP-47? You could associate payment 
codes with email via DNS.

It would be nice if there was a way to get rid of the announcement transaction 
in BIP-47 and establish a shared secret out of bound. That would simplify 
things, at the cost of an additional burden of storing more than an HD seed to 
recover a wallet that received funds this way.

Perhaps the sender can email to the recipient the information they need to 
retrieve the funds. The (first) transaction could have a time locked refund in 
it, in case the payment code is stale.

Sjors

> Op 1 dec. 2017, om 04:08 heeft Douglas Roark via bitcoin-dev 
>  het volgende geschreven:
> 
> On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
>> I was wondering in terms of mass adoption, instead of long wallet
>> addresses, maybe there should be a DNS-like decentralized mapping
>> service to provide a user@crypto address?
> 
> A few years ago, I was part of an effort with Armory and Verisign to
> make something similar to what you're describing.
> https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
> find the one and only official draft. I worked on a follow-up with some
> changes and some nice appendices, explaining some nice tricks one could
> use to make payment management flexible. For various reasons, it never
> got published. I think it's an interesting draft that could be turned
> into something useful. Among other things, it was able to leverage BIP32
> and allow payment requests to be generated that automatically pointed
> payees to the correct branch. DNSSEC may have some issues but, AFAIK,
> it's as the easiest way to bootstrap identity to a common, reasonably
> secure standard.
> 
> --
> ---
> Douglas Roark
> Cryptocurrency, network security, travel, and art.
> https://onename.com/droark
> joro...@vt.edu
> PGP key ID: 26623924
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination

[Sjors Provoost via bitcoin-dev]

As much as I love SI standards, "trains users to understand SI prefixes, 
allowing them to
easily migrate from one prefix to the next" seems unrealistic. The metric 
system is about to
have its 220th birthday and people in the US still don't use it.

It makes sense to embrace terms that stick. "bits" as a formal-yet-informal 
alias for µBTC makes sense to me, unless someone can point to another term 
that's already commonly used.

I'm not too worried about the word bit having other meanings in common 
language. The word "bit coin" was introduced in the English language without a 
problem. A "bit" being 1 millionth of a "bit coin" doesn't seem too difficult. 
It will give a while new meaning to the expression "a bit expensive" :-)

Rather than nano-bitcoin, I would suggest milli bits.


It's rather unfortunate that 1 satoshi was defined as 10^-8 BTC instead of 
10^-9. We could redefine satoshi to 10^-9 BTC. Then we can use kilo-satoshi 
instead of bits. Then the next step can be satoshi, followed by millisatoshi 
(you never know).

The smallest amount that can be handled by bitcoin software under this 
redefinition would be 10 satoshi rather than 1; mostly a matter of changing 
some source code comments.

The only place where I've seen the unit "satoshi" used is fee estimators. I 
think it's still early enough that people aren't terribly attached to the 
numbers shown on those sites (most people express fees in fiat terms, 
especially when complaining). We could switch from vbytes to weight units at 
the same time.

Sjors

> Op 13 dec. 2017, om 22:36 heeft David A. Harding via bitcoin-dev 
>  het volgende geschreven:
> 
> On Wed, Dec 13, 2017 at 01:46:09PM -0600, Jimmy Song via bitcoin-dev wrote:
>> Hey all,
>> 
>> I am proposing an informational BIP to standardize the term "bits". The
>> term has been around a while, but having some formal informational standard
>> helps give structure to how the term is used.
>> 
>> https://github.com/jimmysong/bips/blob/unit-bias/bip-unit-bias.mediawiki
> 
> Wallets and other software is already using this term, so I think it's a
> good idea to ensure its usage is normalized.
> 
> That said, I think the term is unnecessary and confusing given that
> microbitcoins provides all of the same advantages and at least two
> additional advantages:
> 
> - Microbitcoins is not a homonym for any other word in English (and
>  probably not in any other language), whereas "bit" and "bits" have
>  more than a dozen homonyms in English---some of which are quite common
>  in general currency usage, Bitcoin currency usage, or Bitcoin
>  technical usage.
> 
> - Microbitcoins trains users to understand SI prefixes, allowing them to
>  easily migrate from one prefix to the next.  This will be important
>  when bitcoin prices rise to $10M USD[1] and the bits denomination has
>  the same problems the millibitcoin denomination has now, but it's also
>  useful in the short term when interacting with users who make very
>  large payments (bitcoin-scale) or very small payments
>  (nanobitcoin-scale).[2]  Maybe a table of scale can emphasize this
>  point:
> 
>  Wrong (IMO):Right (IMO):
>  --- --
>  BTC BTC
>  mBTCmBTC
>  bitsµBTC
>  nBTCnBTC
> 
> [1] A rise in price to $10M doesn't require huge levels of growth---it
> only requires time under the assumption that a percentage of bitcoins will
> be lost every year due to wallet mishaps, failure to inherit bitcoins,
> and other issues that remove bitcoins from circulation.  In other words,
> it's important to remember that Bitcoin is expected to become a
> deflationary currency and plan accordingly.
> 
> [2] Although Bitcoin does not currently support committed
> nanobitcoin-scale payments in the block chain, it can be supported in a
> variety of ways by offchain systems---including (it is hypothesized)
> trustless systems based on probabilistic payments.
> 
> Thanks,
> 
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sign / Verify message against SegWit P2SH addresses.

[Sjors Provoost via bitcoin-dev]

I would like to see this specifically for P2SH-PWPKH and/or native SegWit 
bech32 addresses.

Use cases I can think of are "I'm the whale in charge of these funds, listen to 
me" and some form of polling.

It's nice if funds aren't excluded from these type of functionalities just 
because they have a complicated redeem script. So something more generic like 
the Elements implementation / suggestion Greg Maxwell referred to in the Github 
thread would be nice too.

Is it also useful or possible to sign a message proving you are able to redeem 
some arbitrary branch in a MAST-like tree of scripts? What about being a 
minority part of a multisig?

All these features have privacy trade-offs, as well as perhaps security 
trade-offs, e.g. when you reveal a public key that was otherwise hidden behind 
a hash (i.e. if someone were to break secp256k1, they'd first organize a 
popular poll).

There's no BIP for the current message signing mechanism either afaik.

Sjors

> Op 8 dec. 2017, om 19:25 heeft Dan Bryant via bitcoin-dev 
>  het volgende geschreven:
> 
> I know there are posts, and an issue opened against it, but is there anyone 
> writing a BIP for Sign / Verify message against a SegWit address?
> 
> I realize it is not a feature in wide use, but I think it still serves an 
> important purpose, such as when proof of assets are requested.
> 
> ref: https://github.com/bitcoin/bitcoin/issues/10542 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

[Sjors Provoost via bitcoin-dev]

CryptAxe wrote:
> Perhaps instead of a flag that can be used to disable a specific operation, 
> there should be a "-ignoredflags=x,y,z" section of the URI that can be used 
> to ignore whatever BIP this might also be useful for in the future?

I don't think all BIPs lend themselves to this pattern. Can you think of 
another example? I also suspect each ignored flag requires carefully defined 
behavior, so it's probably better to spell that out in the BIP.

I also wouldn't be surprised if this BIP will get superseded in its entirety in 
the not too distant future; I believe there's some earlier discussion on this 
list about variations on BIP-71. So I don't think there will be many additional 
params in the future that warrant abstraction.


Luke Dashjr wrote:
>> P.S. I'd similarly suggest adding a bech32 param, but that's for another
>> discussion
> 
> Bech32 addresses are just normal addresses. What need is there for a param?
> 
> Luke

Most wallets consider bech32 addresses to be invalid. This would allow 
merchants to display a backwards compatible P2SH address and allow modern 
wallets to use bech32. In fact, this should be encouraged because it's slightly 
cheaper for the recipient to spend these funds (but not worth even a tiny 
increase in shopping cart abandonment).

Once the new format has sufficient adoption, merchants can simply drop support 
for old wallets and not use this parameter.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP-21 amendment proposal: -no125

[Sjors Provoost via bitcoin-dev]

One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125 [0]. It 
allows wallets to recommend lower fees, because if a transaction gets stuck due 
to underestimation, the fee can easily be bumped.

Bitcoin Core has had support for RBF for a while, and as of v0.15.0 recommends 
lower fees [1] when the user chooses to use RBF.

I recently submitted a pull request that would turn on RBF by default, which 
triggered some discussion [2]. To ease the transition for merchants who are 
reluctant to see their customers use RBF, Matt Corallo suggested that wallets 
honor a no125=1 flag.

So a BIP-21 URI would look like this: bitcoin:175t...45W?amount=20.3=1

When this flag is set, wallets should not use RBF, regardless of their default, 
unless the user explicitly overrides the merchant's preference.

Afaik adding this flag won't break existing BIP-21 support. It doesn't use the 
req- prefix, because it's optional. I'm also not aware of any ad hoc standards 
that use no125 in BIP-21-ish URIs.

- Sjors

P.S. I'd similarly suggest adding a bech32 param, but that's for another 
discussion

[0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
[1] https://bitcoincore.org/en/2017/09/01/release-0.15.0/#better-fee-estimates
[2] https://github.com/bitcoin/bitcoin/pull/11605
[3] https://github.com/bitcoin/bitcoin/issues/11828


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits, extendability

[Sjors Provoost via bitcoin-dev]

I came across the proposed Bitcoin Core implementation of BIP159 [0] in this PR 
[1]. The goal is to allow pruned nodes to "serve a limited number of historical 
blocks" (as opposed to none at all).

It contains a counter-measure for peer fingerprinting. I'm trying to understand 
how that impacts extendibility.

> Peers may have different prune depths (depending on the peers configuration,
> disk space, etc.) which can result in a fingerprinting weakness (finding the
> prune depth through getdata requests). NODE_NETWORK_LIMITED
> supporting peers SHOULD avoid leaking the prune depth and therefore
> not serve blocks deeper then the signaled NODE_NETWORK_LIMITED
> thresholds.

This means pruned nodes can only serve the last 288 blocks:

> If signaled, the peer MUST be capable of serving at least the last 288 blocks 
> (~2 day

As the blockchain keeps growing there will be ever more pruned nodes (perhaps 
offset by new nodes with more storage).  Although a strict improvement over 
todays situation, it seems a bit wasteful to have a node with 10-100 GB of 
storage only be able to share the most recent 288 blocks.

It would be nice if a future extension of this BIP allows more flexibility. To 
limit the ability to fingerprint nodes, we could limit the number of choices to 
e.g. 288 + 1000 * 2^n. That yields only 8 possibilities at the current chain 
size. A slightly better formula could take into account typical hard drive size 
increments, leaving enough space for the OS and other data. Node operators 
could opt-in to this if they think the increased fingerprint risk outweighs 
their desire to share archived blocks.

I can also imagine - but not implement :-) - a future scenario where nodes 
prune a random subset of their chain, meaning that even nodes with little 
storage can be of help during Initial Blockchain Download (IBD) of other nodes.


How would such extension be signaled for? Would we need a whole new version bit?

Would upgraded nodes need a new message type to communicate the chosen prune 
depth? Or can that information tag along some existing message?

Jonas Schnelli pointed out on the Github discussion that waiting for BIP150 
would be appropriate. Can you explain how this is related? Although I can see 
why whitelisted peers can be exempted from the anti-fingerprinting measure, I 
would not want to restrict it to just those.


Some minor suggestions for improving the BIP itself:
* add link to mailinglist discussion(s) in reference section
* explain that 288 is not just the minimum limit for Bitcoin Core, but also the 
bulk of traffic (as I understand from earlier discussion [2])

Cheers,

Sjors

[0] https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki
[1] https://github.com/bitcoin/bitcoin/pull/10387
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.html#14315


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard

[Sjors Provoost via bitcoin-dev]

Can you clarify what you mean by "whitelisting all blocks before the softfork 
block"?

The most conservative approach could be to leave the code in place until the 
very last non-segwit P2SH UTXO from before the soft fork block has been spent. 
But this would never happen if even a single private key is lost.

After making these transactions non-standard and removing the code, 
transactions containing these OP-codes could be considered valid (perhaps still 
checking the signature, etc). Some miners would still run the code and mine 
those transactions, but others wouldn't verify them. This is strictly less bad 
than losing those funds forever, but doesn't seem acceptable either.

Is there a variant of the above scenario where a miner puts up some very large 
deposit (e.g. 10x the size of the UTXO) if they mine such a legacy transaction, 
and can lose that if someone else runs the code and finds the transaction 
invalid?

Sjors

> Op 15 nov. 2017, om 20:54 heeft Mark Friedenbach via bitcoin-dev 
>  het volgende geschreven:
> 
> As good of an idea as it may or may not be to remove this feature from the 
> code base, actually doing so would be crossing a boundary that we have not 
> previously been willing to do except under extraordinary duress. The nature 
> of bitcoin is such that we do not know and cannot know what transactions 
> exist out there pre-signed and making use of these features.
> 
> It may be a good idea to make these features non standard to further 
> discourage their use, but I object to doing so with the justification of 
> eventually disabling them for all transactions. Taking that step has the 
> potential of destroying value and is something that we have only done in the 
> past either because we didn’t understand forks and best practices very well, 
> or because the features (now disabled) were fundamentally insecure and 
> resulted in other people’s coins being vulnerable. This latter concern does 
> not apply here as far as I’m aware.
> 
> On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev 
>  > wrote:
> 
>> In https://github.com/bitcoin/bitcoin/pull/11423 
>>  I propose to make 
>> OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard
>> 
>> I think FindAndDelete() is one of the most useless and complicated functions 
>> in the script language. It is omitted from segwit (BIP143), but we still 
>> need to support it in non-segwit scripts. Actually, FindAndDelete() would 
>> only be triggered in some weird edge cases like using out-of-range 
>> SIGHASH_SINGLE.
>> 
>> Non-segwit scripts also use a FindAndDelete()-like function to remove 
>> OP_CODESEPARATOR from scriptCode. Note that in BIP143, only executed 
>> OP_CODESEPARATOR are removed so it doesn’t have the FindAndDelete()-like 
>> function. OP_CODESEPARATOR in segwit scripts are useful for Tumblebit so it 
>> is not disabled in this proposal
>> 
>> By disabling both, it guarantees that scriptCode serialized inside 
>> SignatureHash() must be constant
>> 
>> If we use a softfork to remove FindAndDelete() and OP_CODESEPARATOR from 
>> non-segwit scripts, we could completely remove FindAndDelete() from the 
>> consensus code later by whitelisting all blocks before the softfork block. 
>> The first step is to make them non-standard in the next release.
>> 
>> 
>> 
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposal: allocate Github issue instead of wiki page to BIP discussion

[Sjors Provoost via bitcoin-dev]

I often find myself wanting to leave relatively small comments on BIP's that 
are IMO not worth bothering this list.

By default each BIP has a wiki page for discussion, e.g. 
https://github.com/bitcoin/bips/wiki/Comments:BIP-0150
This is linked to from the Comments-URI field in the BIP.

In order to leave a comment, you have to edit the wiki page. This process seems 
a bit clunky.

I think it would be better to use Github issues, with one Github issue for each 
BIP.

One concern might be that the ease of use of Github issues would move 
discussion away from this list. The issue could be temporarily locked to 
prevent that. The issue description could contain a standard text explaining 
what should be discussed there and what would be more appropriate to post on 
the mailinglist.

Another concern might be confusing between PR's which create and update a BIP, 
and the discussion issue.

If people think this a good idea, would the next step be to propose a change to 
the process here?
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments

Or would this be a new BIP?

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Version 1 witness programs (first draft)

[Sjors Provoost via bitcoin-dev]

Op 2 okt. 2017, om 03:56 heeft Luke Dashjr via bitcoin-dev 
 het volgende geschreven:
> 
> On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote:
>>> b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114
>>> but now I think it doesn’t interact well with signature aggregation, and
>>> I worry that it would have some other unexpected effects. c. Generalised
>>> NOP method: user has to provide the returned value, so even VERIFY-type
>>> code could do anything
>> 
>> I see no reason to do either. Gate new behavior based on script execution
>> flags, which are set based on the script version.  Script versions not
>> understood are treated as "return true" to begin with.  The interpreter
>> isn't even going to try to decode the script according to the old rules,
>> let alone try to execute it, so there's no reason for the old soft-fork
>> compatability tricks.
>> 
>> The new soft-fork trick is that you increment the script version number.
>> That is all.
> 
> This breaks parallel softfork deployments.

If unknown script versions are treated as "return true", there's no need for 
versions to be deployed in sequence, right? Maybe they should be called 
numbered script types, rather than script versions.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

[Sjors Provoost via bitcoin-dev]

> Op 30 sep. 2017, om 06:49 heeft Jonas Schnelli via bitcoin-dev 
>  het volgende geschreven:
> 
>> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
>> Paper wallets are a safety hazard, insecure, and generally not advisable.
>> 
> 
> I have to agree with Luke.
> And I would also extend those concerns to BIP39 plaintext paper backups.
> 
> IMO, private keys should be generated and used (signing) on a trusted, 
> minimal and offline hardware/os. They should never leave the device over the 
> channel used for the signing I/O. Users should have no way to view or export 
> the private keys (expect for the seed backup). Backups should be encrypted 
> (whoever finds the paper backup should need a second factor to decrypt) and 
> the restore process should be footgun-safe (especially the lost-passphrase 
> deadlock).

I believe BIP39 does an excellent job at reducing the amount of bitcoin 
permanently lost. Stolen funds can at least in theory be retrieved at some 
future date. There's a trade-off between having a backup process that is secure 
and one that people actually use. I don't know the right answer, and tend to 
agree it's better left to individual wallets to decide.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

[Sjors Provoost via bitcoin-dev]

A 12-24 word BIP39 mnemonic is easy to write down and has the benefit of not 
needing to trust a printer.

However without also supporting BIP43/44/49 this would probably cause 
confusion. Supporting these would be a larger project as well. Although widely 
used, the standards are still Proposed / Draft. There's  might be room for 
improvement [0].

Sjors

[0] https://github.com/satoshilabs/slips/issues/103

> Op 29 sep. 2017, om 20:07 heeft Andrew Johnson via bitcoin-dev 
>  het volgende geschreven:
> 
> One consideration of exposing this in QT is that it may encourage users to 
> generate paper wallets(which are generally used and recommended for cold 
> storage) from online machines, rendering them moreso lukewarm rather than 
> cold, since the keys weren't generated in an air-gapped environment.  When 
> using bitaddress.org  locally(we are all only using 
> it locally and not directly from the online webpage, right? ;) ) you've at 
> least made the effort to seek out the repo, clone it locally, and use it on 
> an offline machine and not retain any data from that session.
> 
> If we include this as a function in the reference implementation, how many 
> people are going to be making paper wallets with the intention of cold 
> storage on a machine that's potentially compromised?  As adoption(hopefully) 
> continues to increase the number of less than tech savvy people using bitcoin 
> will increase.
> 
> I'd suggest that any UI in QT include some sort of a modal dialog that 
> informs the user that this is not a secure cold storage address unless it was 
> created on an offline machine and printed on a non-networked printer, and the 
> prompt must be accepted and dismissed before the wallet will provide the 
> requested keys.
> 
> 
> On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev 
>  > wrote:
> Hi,
> 
> I'm writing to suggest and discuss the addition of paper wallet
> functionality in bitcoin-core software, starting with a single new RPC
> call: genExternalAddress [type].
> 
> -- rationale --
> 
> bitcoin-core is the most trusted and most secure bitcoin implementation.
> 
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org .  This requires placing trust in an 
> additional body of
> code from a less-trusted and less peer-reviewed source.  Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
> 
> In the case of a website generator, the code must be audited again each
> time it is downloaded.  I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
> 
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
> 
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
> 
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.
> 
> As such, I'm throwing out the following half-baked proposal as a
> starting point for discussion:
> 
> 
> -
> 
> genexternaladdress ( "type" )
> 
> Returns a new Bitcoin address and private key for receiving
> payments. This key/address is intended for external usage such as
> paper wallets and will not be used by internal wallet nor written to
> disk.
> 
> Arguments:
> 1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
> default: p2sh-p2wpkh
> 
> Result:
> {
> "privKey"(string) The private key in wif format.
> "address"(string) The address in p2pkh or p2sh-p2wpkh
>   format.
> }
> 
> 
> Examples:
> > bitcoin-cli genexternaladdress
> 
> 
> 
> 
> This API is simple to implement and use.  It provides enough
> functionality for any moderately skilled developer to create their own
> paper wallet creation script using any scripting language, or even for
> advanced users to perform using bitcoin-cli or debug console.
> 
> If consensus here is in favor of including such an API, I will be happy
> to take a crack at implementing it and submitting a pull request.
> 
> If anyone has reasons why it is a BAD IDEA to include such an RPC call
> in bitcoind, I'm curious to hear it.
> 
> Also, I welcome suggestions for a better name, or maybe there could be
> some improvements to the param(s), such as 

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Sjors Provoost via bitcoin-dev]

Op 29 sep. 2017, om 05:18 heeft Peter Todd <p...@petertodd.org> het volgende 
geschreven:
> 
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev 
> wrote:
>> Peter Todd wrote:
>> Perhaps outside the scope of BIP173, but what about baking it into the 
>> protocol? That way a transaction that's sent too late, simply won't get 
>> confirmed. This removes the need for refund logic or asking a customer to 
>> pay just a few extra cents. You could also disallow a second payment.
>> 
>> Two downsides I can think of:
>> * privacy, as differences in expiration policy would be visible on chain
>> * miners might be able to game it in their interaction with brokers
> 
> This has been discussed many times before; there are *severe* downsides to
> making it possible for transactions to become invalid after the fact.

I've heard of that general principe, but I'm having trouble finding a good 
resource that describes it more precisely.

Is it a peer to peer or mempool issue? E.g a transaction might be accepted into 
the mempool and relayed at one point in time and suddenly become invalid before 
they're committed to a block? Or that a node receives a transaction, thinks 
it's invalid because the address already expired, but then receives an older 
block later which contains that transaction?

Once in a block, I don't see how it would become invalid later. But as a miner 
tries to find a block and updates the timestamp, they would have toss the 
transaction out at some point.

Another objection I can think of, is that the soft fork introducing this change 
would have to use a transaction type that's non-standard at the moment. This 
would make it difficult for a non-upgraded node to broadcast such a 
transaction. The recipient would have to know if the sender has upgraded before 
communicating an address, which sounds impractical at best.

>>> Being just an expiration time, seconds-level resolution is unnecessary, and
>>> may give the wrong impression. I'd suggest either:
>>> 
>>> 1) Hour resolution - 2^24 hours = 1914 years
>>> 2) Month resolution - 2^16 months = 5458 years
>> 
>> So that's 4.8 characters for hours, or 3.2 for years, plus checksum space? 
>> The shorter the better. Perhaps one or two bits can be used to specify an 
>> exponent; a large range seems more useful than high precision. For instance 
>> a merchant doesn't care if the customer pays within 10:00:00 minutes or 
>> 10:00:01 minutes and you wouldn't care if your address is valid 50 years or 
>> 50 years and 3 minutes. This point may be mute if minute level resolution is 
>> not practical.
> 
> Note that "large range" is a requirement driven by the fact that expiry times
> will inevitably be specified absolutely, not relatively: when the range runs
> out you need to upgrade the standard. Better to use another character and use 
> a
> range that won't run out any time soon.
> 
> This wouldn't create a need for more checksum space.

You're right, relative time makes no sense. So it would take 5 characters to 
get roughly two minute resolution that lasts for 100 years.

Sjors



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Sjors Provoost via bitcoin-dev]

Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
> On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:
> 
>>> The payment request message is just as one-way as an address is. It is
>>> already being emailed and printed on an invoice, in fact it often acts
>>> as the invoice.
>> 
>> True and the more complicated fields, like a digital signature, are 
>> optional. Are you suggesting BIP-70 payment requests should be rendered with 
>> bech32? How long would those be if it's just the address and expiration date?
> 
> I've not yet progressed that far in segwit support, but I can't think of
> a reason why not. You can request coins to any script using the payment
> protocol.
> 
> Regarding size, I've had no problems putting (unsigned) payment request
> messages into QR codes. I doubt paying to a native segwit address will
> change much in size. Protobuf is very efficient.

Bech32 is just a replacement for Base58. It's not strictly SegWit related. If I 
understand correctly the only reason it won't be used for legacy addresses is 
to prevent confusion:

https://www.youtube.com/watch?v=NqiN9VFE4CU
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

Regarding size I'm mostly curious how big it is on a screen or a physical 
paper, as text, not as a QR code. This would involve deserializing the protobuf 
and rendering the result in bech32.

I does sound like there's overlap between BIP-70 and BIP-173 that should be 
resolved.

Perhaps any payment request can be rendered as bech32 and any bech32 address 
can converted to a payment request. Maybe only for a limited set of fields 
(address, expiration, amount). This would be a matter of agreeing how the 
protobuf should be serialized and deserialized. In that case the protobuf would 
not contain the literal bech32 address as a string, but instead it would 
contain the underlying data (public key / script hash, network, etc).

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Sjors Provoost via bitcoin-dev]

Op 28 sep. 2017, om 17:13 heeft Andreas Schildbach via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
> On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev wrote:
> 
>>> This feels redundant to me; the payment protocol already has an
>>> expiration time.
>> 
>> The BIP-70 payment protocol has significant overhead and most importantly 
>> requires back and forth. Emailing a bitcoin address or printing it on an 
>> invoice is much easier, so I would expect people to keep doing that.
> 
> The payment request message is just as one-way as an address is. It is
> already being emailed and printed on an invoice, in fact it often acts
> as the invoice.

True and the more complicated fields, like a digital signature, are optional. 
Are you suggesting BIP-70 payment requests should be rendered with bech32? How 
long would those be if it's just the address and expiration date?

> 
> Even more problematic, if you were to include an expiry date in a
> BIP-173 address and put that into a payment request, wallets wouldn't be
> allowed to parse that expiry date from the script without violating the
> BIP70 spec.

Do tools that generate BIP-70 payment requests generate addresses themselves or 
are those input manually by a user? In the former case, I assume it could avoid 
setting the optional expiration date?

Is it not allowed to scan the date even if it then sets the expires field to 
the same (redundant) value?

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Sjors Provoost via bitcoin-dev]

Peter Todd wrote:

> 
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen;

[...]
> 
> To help combat this problem, I suggest that we add a UI-level expiration time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time is
> reached.

[...]

Perhaps outside the scope of BIP173, but what about baking it into the 
protocol? That way a transaction that's sent too late, simply won't get 
confirmed. This removes the need for refund logic or asking a customer to pay 
just a few extra cents. You could also disallow a second payment.

Two downsides I can think of:
* privacy, as differences in expiration policy would be visible on chain
* miners might be able to game it in their interaction with brokers

> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
> 
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years

So that's 4.8 characters for hours, or 3.2 for years, plus checksum space? The 
shorter the better. Perhaps one or two bits can be used to specify an exponent; 
a large range seems more useful than high precision. For instance a merchant 
doesn't care if the customer pays within 10:00:00 minutes or 10:00:01 minutes 
and you wouldn't care if your address is valid 50 years or 50 years and 3 
minutes. This point may be mute if minute level resolution is not practical.

> Both options have the advantage of working well at the UI level regardless of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
> 
> Supporting hour-level (or just seconds) precision has the advantage of making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using at
> least hour-level ensures we don't have any year 2038 problems.

Greg Maxwell wrote:

> One thing to keep in mind is that address format linked fields are
> most efficient if they're multiples of 5 bits.  Perhaps use 1 bit to
> indicate an embedded amount and 19 bits of 1 day precision, resulting
> in a 1435 year span.

Is this because 5 bits are one bech32 character (2^5=32) or there is another 
reason? And does that include the space needed for the checksum?


Hopefully one day addresses can be abstracted away, because they really aren't 
what people intuitively think they are, but I don't see that happen on short 
notice. Until then they shouldn't exhibit "surprising" behavior.

Embedding amounts in an address could confuse people when they reuse it. 
Wallets would e.g. have to ignore the amount value if they previously sent 
money, but without changing the address string displayed in the UI.


> Keep in mind that high precision of the expiration times is asking the
> sender to have a higher precision of idea of the time, date only is
> kinda nice.  I think shorter expiration times are unlikely to be
> useful due to clock skew-- you can't assume a signer has any access to
> the Bitcoin network at all.

Many merchant services and exchanges use 10-15 minute expiration though. At the 
wallet level, all sender and recipient need to agree on is their relative time. 
Fallback behavior for a signer with no access to time could be to ignore the 
deadline.

Andreas Schildbach wrote:
> 
> This feels redundant to me; the payment protocol already has an
> expiration time.

The BIP-70 payment protocol has significant overhead and most importantly 
requires back and forth. Emailing a bitcoin address or printing it on an 
invoice is much easier, so I would expect people to keep doing that.

Sjors



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revising BIP 2 to expand editorial authority

[Sjors Provoost via bitcoin-dev]

Op 27 sep. 2017, om 22:01 heeft Bryan Bishop via bitcoin-dev 
 het volgende geschreven:
> 
> On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev 
>  > wrote:
> What do people think about modifying BIP 2 to allow editors to merge these
> kinds of changes without involving the Authors? Strictly speaking, BIP 2
> shouldn't be changed now that it is Active, but for such a minor revision, I
> think an exception is reasonable.
> 
> Even minor revisions can not change the meaning of text. Changing a single 
> word can often have a strange impact on the meaning of the text. There should 
> be some amount of care exercised here. Maybe it would be okay as long as 
> edits are mentioned in the changelog at the bottom of each document, or 
> mention that the primary authors have not reviewed suggested changes, or 
> something as much; otherwise the reader might not be aware to check revision 
> history to see what's going on.

Perhaps it's enough to @mention authors in the PR and give them a week to 
object before merging?

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev