Re: [bitcoin-dev] Compressed Bitcoin Transactions

[Jonas Schnelli via bitcoin-dev]

One point to add here is that, while V1 non-encrypted p2p traffic could be 
compressed on a different OSI layer in theory, v2 encrypted traffic – due to 
its pseudorandom nature – will likely have no size savings and thus need to be 
compressed on the application layer with a proposal like this.

Would be nice to see size comparison of this compression proposal vs LZO/gzip 
compression of legacy transaction encoding.

A possible advantage of this proposal is that it could save more space with 
less CPU impact, which might be important for block propagation.

Previous discussion about compressing blocks before sending them:
https://github.com/bitcoin/bitcoin/pull/6973

/jonas

> Am 16.01.2024 um 18:08 schrieb Tom Briar via bitcoin-dev 
> :
> 
> Hi,
> 
> In addition to the use cases listed in the schema, such as steganography, 
> satellite, and radio broadcast, an application can be made for Peer-to-peer 
> communication between Bitcoin nodes. Except when compressing the Txid/Vout, 
> which is optional, Transactions can gain up to 30% size savings while still 
> being completely reversible. Furthermore, in a BIP-324 world, these savings 
> are nontrivial.
> 
> BIP-324: https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki
> Compressed Transaction Schema: compressed_transactions.md
> 
> Thanks-
> Tom.
> ___
> 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] Compressed Bitcoin Transactions

[Jonas Schnelli via bitcoin-dev]

Hi Tom

> I've been working on a way to compress bitcoin transactions for transmission 
> through steganography, satellite broadcasting, 

Interesting. Some size numbers (vs plain, vs gzip) would be nice.

Maybe add a definition to your BIP that makes clear when NOT to use 
height/index due to risk of reorgs (similar to BIP136).

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

Re: [bitcoin-dev] Refreshed BIP324

[Jonas Schnelli via bitcoin-dev]

> From what I understand we'll have about 35 message types on the network with 
> the addition of BIP324. 256 possible IDs sounds like plenty room to grow, but 
> perhaps we can be a bit more conservative:
> 
> We could use the first bit to signal a 2-byte message ID. That allows us to 
> express 128 IDs with 1 byte, but if we need more, we get a total of 2^15 IDs 
> across 2 bytes.

Could make sense.

There would be an alternative to preserve more 1 byte IDs on the cost of a 
(much) smaller 2 byte ID space:
Reserve the short ID 0xFF as an indication for a 2 bytes short ID (additional 
256 short IDs with 2 bytes).
That could be done later outside BIP324.
The 0xFF approach would lead to approx. 207 unused 1 byte short IDs (while 
Murchs approach would give us approx. 79 unused 1 byte short IDs).
The signal bit two byte approach would however lead to ~32k more two byte 
message IDs.

The main (and only?) benefit of short IDs is bandwidth.
Short ID 1-12 are reserved for string based IDs and thus, new and rarely sent 
message types must not always use a short ID.

Maybe the BIP should state that only frequent sent messages should reserve a 
short ID, though, the BIP itself assigns short IDs to all(?) message types 
(including low frequent messages like SENDHEADERS).

Maybe exclude message types that expected to be only sent once from assigning a 
short ID?

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

Re: [bitcoin-dev] I want to rebuild the GUI in JavaScript

[Jonas Schnelli via bitcoin-dev]

Hi

This is probably the wrong place to discuss that (OT).

> I’d like to try to rebuild Bitcoin Core GUI using the JavaScript Electron 
> framework. My goal is to get a real world understanding of the pros and cons 
> of moving from Qt to Electron.

There is a relatively new Bitcoin Core Github issue that covers that topic [1].
AFAIK many Bitcoin Core contributors (and users?) don’t like the idea of having 
a Browser and JavaScript to achieve a UI with relatively simple user-stories.

I think if you want to do this, try to work on a third party project and let 
your Electron UI connect to Bitcoin Core over RPC.
To avoid pulling, eventually use ZMQ or help getting long polling into Bitcoin 
Core [2].

Adding a Electron/JavaScript UI to the Bitcoin Core repository is very unlikely 
to happen.

[1] https://github.com/bitcoin/bitcoin/issues/17395
[2] https://github.com/bitcoin/bitcoin/pull/7949


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] Block Batch Filters for Light Clients

[Jonas Schnelli via bitcoin-dev]

Hi Aleksey

> BIP 157 unlike BIP 37 not allow apply filters to mempool and check zero 
> confirmation transactions.
> Light client that refused to use BIP 37 due to privacy leaks can process 
> unconfirmed transactions only one way and this is loading the entire mempool 
> transaction flow.
> 
> https://github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-filters.mediawiki
>  
> 

Instead of using a per tx filter, would it be possible to allow retrieving a 
complete compact filter of the whole mempool (similar to BIP35)? Maybe using a 
maximum size of the filter (ordered by feerate).
In general, I guess the concerns are DOS and fingerprinting.

Maybe DOS could be mitigated via a dynamic filter construction (append elements 
during the time between blocks, though unsure if possible).
The update-interval of a such filter could also be timebases rather than on 
every new tx in the mempool.

Unsure about fingerprinting defence measures.

I would expect the following process:
* peer generates mempool filter
* [timespan A (say 3 seconds)]
* light client connects to peer
* light client requests mempool-filter
* peers sends mempool filter
* light client processes filter for relevant txns
* eventually, light client sends getdata of relevant txns

a) after the initial retrieve...
* light client inspects all new txns (inv/getdata) received from peers from 
this point on (filterless unconfirmed tx detection)

Of if a) is to bandwidth expansive, request the mempool filter again after a 
timeout

/jonas

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

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Jonas Schnelli via bitcoin-dev]

> 1) It causes way too much traffic for mobile users, and likely even too
> much traffic for fixed lines in not so developed parts of the world.

Yes. It causes more traffic than BIP37.
Basic block filters for current last ~7 days (1008 blocks) are about 19MB (just 
the filters).
On top, you will probably fetch a handful of irrelevant blocks due to the FPs 
and due to true relevant txns.
A over-the-thumb estimation: ~25MB per week of catch-up.
If you where offline for a month: ~108MB

Thats certainly more then BIP37 BF (measured 1.6MB total traffic with android 
schildbach wallet restore blockchain for 8 week [7 weeks headers, 1week 
merkleblocks]).

But lets look at it like this: for an additional, say 25MB per week (maybe a 
bit more), you get the ability to filter blocks without depending on serving 
peers who may compromise your financial privacy.
Also, if you keep the filters, further rescans do consume the same or less 
bandwidth than BF BIP37.
In other words: you have the chance to potentially increase privacy by 
consuming bandwidth in the range of a single audio podcast per week.

I would say the job of protocol developers is protect users privacy where it’s 
possible (as a default).
It’s probably a debatable point wether 25MB per week of traffic is worth a 
potential increase in privacy, though I absolutely think 25MB/week is an 
acceptable tradeoff.
Saving traffic is possible by using BIP37 or stratum/electrum… but developers 
should make sure users are __warned about the consequences__!

Additionally, it looks like, peer operators are not endless being willing to 
serve – for free – a CPU/disk intense service with no benefits for the network. 
I would question wether a decentralised form of BIP37 is sustainable in the 
long run (if SPV wallet provider bootstrap a net range of NODE_BLOOM peers to 
make it more reliable on the network would be snake-oil).


> 
> 2) It filters blocks only. It doesn't address unconfirmed transactions.

Well, unconfirmed transaction are uncertain for various reasons.

BIP158 won't allow you to filter the mempool.
But as soon as you are connected to the network, you may fetch tx with 
inv/getdata and pick out the relevant ones (causes also traffic).
Unclear and probably impossible with the current BIP158 specs to fetch 
transactions that are not in active relay and are not in a block (mempool txns, 
at least this is true with the current observed relay tactics).


> 3) Afaik, it enforces/encourages address re-use. This stems from the
> fact that the server decides on the filter and in particular on the
> false positive rate. On wallets with many addresses, a hardcoded filter
> will be too blurry and thus each block will be matched. So wallets that
> follow the "one address per incoming payment" pattern (e.g. HD wallets)
> at some point will be forced to wrap their key chains back to the
> beginning. If I'm wrong on this one please let me know.

I’m probably the wrong guy to ask (haven’t made the numbers) but last time I 
rescanned a Core wallet (in my dev branch) with block filters (and a Core 
wallet has >2000 addresses by default) it fetched a low and acceptable amount 
of false positive blocks.
(Maybe someone who made the numbers step in here.)

Though, large wallets – AFAIK – also operate badly with BIP37.

> 
> 4) The filters are not yet committed to the blockchain. Until that
> happens we'd have to trust a server to provide correct filters.

I wouldn’t say so. It’s on a similar level than BIP37.
BIP37 is not – and can not – be committed to the blockchain.
You fully trust the peer that it won’t…
a) create fake unconfirmed transactions (would be the same if a BIP158 wallet 
would show you unconfirmed transaction)
b) lies by omission (you will miss relevant transactions, eventually swipe your 
wallet and loose coins)

IMO, the point b) is true for BIP37 and BIP158 (as long as not commited).
In both cases, you can reduce the trust by comparing between peers / 
filter-providers.

b) is conceptually solvable with a soft-fork (commitment) in BIP158 (not with 
BIP37).

Additionally, block-filters will, very likely, be useful for other features 
(load/rescan an [old] wallet on a prune peer that has the filters constructed).



There is probably no clear answer like „X is better than Y“.

Personally I would like to see developers being more honest/transparent to 
users about the implications of the used filtering,... and giving them choices.
Imagine a user can choose between „Electrum / BIP37 / BIP158“ depending on his 
needs for privacy and availability of bandwidth. Eventually also taking the 
future usage of this wallet (will he load old private keys, will he receive 
money daily, etc.) into account.

Plus, full node hardware appliances that run at home (or in a trusted 
environment) are solving many of these issues plus adding a bunch of great 
features – if done right.

/jonas


signature.asc
Description: Message signed with OpenPGP

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Jonas Schnelli via bitcoin-dev]

Hi Andreas

>> well-known DoS vectors
> 
> I asked many people, even some "core developers" at meetings, but nobody
> ever was able to explain the DoS vector. I think this is just a myth.

No. They are not a myth [1] [2] [3].

> Yes, you can set an overly blurry filter and thus cause useless traffic,
> but it never exceeds just drinking from the full firehose (which this
> change doesn't prohibit). So where is the point? An attacker will just
> switch filtering off, or in fact has never used it.

I guess it’s not about traffic DoS. It’s about asking a peer for extensive CPU 
and disk work. The NODE_BLOOM peers do provide this service for free while it’s 
not directly beneficial for the Bitcoin Network (pure consumed CPU/disk time).

> 
>> It is not anticipated that
>> this will result in a significant lack of availability of
>> NODE_BLOOM-enabled nodes in the coming years
> 
> Why don't you anticipate that? People almost never change defaults,
> especially if it's not for their own immediate benefit. At the same
> time, release notes in general recommend updating to the latest version.
> I *do* anticipate this will reduce the number of nodes usable by a large
> enough amount so that the feature will become unstable.

I guess this is speculation.
A quick lookup in my crawler databases shows me that there are more than 8’000 
„good“ peers supporting NODE_BLOOM right now.
I don’t expect that this number drops rapidly, but maybe in the long run ("in 
years“, but again: speculation).

We eventually can’t expect - in the long run - that nodes provide disk/CPU 
intense services for free to clients not contributing back to the network.
However, sadly, due to the privacy leaks in BIP37, I expect that there will 
always be a wide range of peers offering NODE_BLOOM in return of collecting 
valuable data.

> 
>> clients
>> which rely on the availability of NODE_BLOOM-supporting nodes on the
>> P2P network should consider the process of migrating
>> to a more modern (and less trustful and privacy-violating) alternative
>> over the coming years.
> 
> There is no such alternative.
> 
> I strongly recommend postponing this change until an alternative exists
> and then give developers enough time to implement, test and roll out.

NODE_BLOOM was added in Core 0.12 [4].
BIP111 is from 2015 [2].
One who follows the protocol development should have known that defaulting 
NODE_BLOOM to off was something anticipated by most developers.

I would say that there are possible alternatives, like BIP158 (though BIP157 is 
not widely available on the network yet).
Client side filtering works also by collecting the filter form a centralised 
service by the wallet provider(s) or a CDN.
You may miss transactions by a dishonest filter-packet, so may you by talking 
to a dishonest NODE_BLOOM peer.
Of course BIP158 is still young and – who knows – eventually once committed to 
consensus layer (coinbase).


> I also think as long as we don't have an alternative, we should improve
> the current filtering for segwit. E.g. testing the scripts themselves
> and each scriptPubKey spent by any input against the filter would do,
> and it also fixes the main privacy issue with server-side filtering
> (wallets have to add two items per address to the filter).

I think the consensus among protocol developers is (please speak up), that 
BIP37 (public server based tx filtering) – in general – was a conceptual 
mistake.
Maybe extending it further is the wrong step, especially when promising 
alternatives like BIP158 (neutrino) are around.
The fact that nobody cared about extending it for SW may also underline that 
BIP37 is seen as a conceptual mistake and/or "low interest in further 
extensions“.


/jonas

[1] https://github.com/petertodd/bloom-io-attack 

[2] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki 

[3] https://github.com/bitcoin/bitcoin/pull/9238 

[4] 
https://github.com/bitcoin/bitcoin/blob/47d981e8273804a040d71665a4cb16038d6717e1/doc/release-notes/release-notes-0.12.0.md#node_bloom-service-bit



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] New BIP - v2 peer-to-peer message transport protocol

[Jonas Schnelli via bitcoin-dev]

Hi Elichai

> About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb later 
> calls xchacha)
> 
> You suggest that we use the "message sequence number" as the nonce for 
> Chacha20, Is this number randomly generate or is this a counter?
> And could it be reseted without rekeying?

The in BIP324 (v2 message transport protocol) proposed AEAD, 
ChaCha20Poly1305@Bitcoin [1], uses a „message sequence number“. There is no 
such thing as random nonce described in the BIP (hence the term „sequence 
number“). The message sequence number starts with 0 and the max traffic before 
a rekey must occur is 1GB. A nonce/key reuse is conceptually impossible (of 
course implementations could screw up at this point).

Using XChaCha20 with the possibility of a random nonce could be done, but I 
don’t see a reason to use it in our case since the usage of a sequence number 
as nonce seems perfectly save.

[1] 
https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#chacha20-poly1305bitcoin-cipher-suite


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] assumeutxo and UTXO snapshots

[Jonas Schnelli via bitcoin-dev]

Thanks James for the post.

I proposed a similar idea [1] back in 2016 with the difference of signing the 
UTXO-set hash in a gitian-ish way.

While the idea of UTXO-set-syncs are attractive, there are probably still 
significant downsides in usability (compared to models with less security), 
mainly:
* Assume the UTXO set is 6 weeks old (which seems a reasonable age for 
providing enough security) a peer using that snapshot would still require to 
download and verify ~6048 blocks (~7.9GB at 1.3MB blocks,… probably CPU-days on 
a phone)
* Do we semi-trust the peer that servers the UTXO set (compared to a block or 
tx which we can validate)? What channel to we use to serve the snapshot?

If the goal is to run a full node on a consumer device that is also been used 
for other CPU intense operations (like a phone, etc.), I’m not sure if this 
proposal will lead to a satisfactory user experience.

The longer I think around this problem, the more I lean towards accepting the 
fact that one need to use dedicated hardware in his own environment to perform 
a painless full validation.

/jonas

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html

> Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev 
> :
> 
> Hi,
> 
> I'd like to discuss assumeutxo, which is an appealing and simple
> optimization in the spirit of assumevalid[0].
> 
> # Motivation
> 
> To start a fully validating bitcoin client from scratch, that client currently
> needs to perform an initial block download. To the surprise of no one, IBD
> takes a linear amount time based on the length of the chain's history. For
> clients running on modest hardware under limited bandwidth constraints,
> say a mobile device, completing IBD takes a considerable amount of time
> and thus poses serious usability challenges.
> 
> As a result, having fully validating clients run on such hardware is rare and
> basically unrealistic. Clients with even moderate resource constraints
> are encouraged to rely on the SPV trust model. Though we have promising
> improvements to existing SPV modes pending deployment[1], it's worth
> thinking about a mechanism that would allow such clients to use trust
> models closer to full validation.
> 
> The subject of this mail is a proposal for a complementary alternative to SPV
> modes, and which is in the spirit of an existing default, `assumevalid`. It 
> may
> help modest clients transact under a security model that closely resembles
> full validation within minutes instead of hours or days.
> 
> # assumeutxo
> 
> The basic idea is to allow nodes to initialize using a serialized version of 
> the
> UTXO set rendered by another node at some predetermined height. The
> initializing node syncs the headers chain from the network, then obtains and
> loads one of these UTXO snapshots (i.e. a serialized version of the UTXO set
> bundled with the block header indicating its "base" and some other metadata).
> 
> Based upon the snapshot, the node is able to quickly reconstruct its 
> chainstate,
> and compares a hash of the resulting UTXO set to a preordained hash hard-coded
> in the software a la assumevalid. This all takes ~23 minutes, not accounting 
> for
> download of the 3.2GB snapshot[2].
> 
> The node then syncs to the network tip and afterwards begins a simultaneous
> background validation (i.e., a conventional IBD) up to the base height of the
> snapshot in order to achieve full validation. Crucially, even while the
> background validation is happening the node can validate incoming blocks and
> transact with the benefit of the full (assumed-valid) UTXO set.
> 
> Snapshots could be obtained from multiple separate peers in the same manner as
> block download, but I haven't put much thought into this. In concept it 
> doesn't
> matter too much where the snapshots come from since their validity is
> determined via content hash.
> 
> # Security
> 
> Obviously there are some security implications due consideration. While this
> proposal is in the spirit of assumevalid, practical attacks may become easier.
> Under assumevalid, a user can be tricked into transacting under a false 
> history
> if an attacker convinces them to start bitcoind with a malicious 
> `-assumevalid`
> parameter, sybils their node, and then feeds them a bogus chain encompassing
> all of the hard-coded checkpoints[3].
> 
> The same attack is made easier in assumeutxo because, unlike in assumevalid,
> the attacker need not construct a valid PoW chain to get the victim's node 
> into
> a false state; they simply need to get the user to accept a bad `-assumeutxo`
> parameter and then supply them an easily made UTXO snapshot containing, say, a
> false coin assignment.
> 
> For this reason, I recommend that if we were to implement assumeutxo, we not
> allow its specification via commandline argument[4].
> 
> Beyond this risk, I can't think of material differences in security relative 
> to
> assumevalid, though I appeal to the list

Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)

[Jonas Schnelli via bitcoin-dev]

Hi Dave

Thanks for the review...

>>  Short Command ID 
>> 
>> To save valuable bandwidth, the v2 message format supports message command
>> short IDs for message types with high frequency. The ID/string mapping is a
>> peer to peer arrangement and MAY be negotiated between the initiating and
>> responding peer.
> 
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
> There's only 26 different types at present[1], so it seems better to
> simply make this a one-byte fixed-length field than it is to deal with
> variable size, mapping negotiation, per-peer mapping in general, and
> (once the network is fully v2) the dual-logic of being able to process
> messages either from a short ID or a full command name.

One thing I was trying to avoid is some sort of central planing.

Strings as message command identifier do usually bring some sort of collision 
resistance when competitive implementations work on different features.
An example are the service bits where we AFAIK had an (almost) collision.
This is the main reason why I think we should avoid setting the short IDs 
mandatory (naturally by not giving all commands a short ID).

Short IDs do probably make most sense for messages with high frequency.
By only giving frequent messages a short ID, we may avoid ID collisions in 
future.

Short IDs can be altered with the message protocol version (not the transport 
protocol, the message protocol like 70015, etc.) and new/different negation 
should be straight forward.

I just ran some random stats (non representative) and inv makes about 66% of 
all messages (pruned peer, not helping IBDing others) followed by tx and 
getdata.
Those three probably deserve a short ID.

I have no big objection against adding short IDs for other commands as long as 
we don’t make short IDs mandatory.
Though, there are little benefits for commands like VERSION, FILTERxx, 
SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.

/jonas



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] New BIP - v2 peer-to-peer message transport protocol (former BIP151)

[Jonas Schnelli via bitcoin-dev]

Hi

The overhauled version of the former BIP151 has fundamental differences and 
deserves (requires?) a new BIP.
Calling it „v2 peer-to-peer message transport protocol“ is more accurate since 
it is no longer only about encryption.

The formatted draft proposal can be found here: 
https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52

Significant changes compared to the current available BIP151
* A optimised AEAD construct is now proposed (ChaCha20Poly1305@Bitcoin), 
reducing the required ChaCha20 rounds (compared to the openSSH version).
* introduce NODE_P2P_V2
* 32bytes-per-side „pseudorandom" key exchange
* the multi message envelope has been removed
* the length of a packet uses now a 3-byte integer with 23 available bits
* introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result 
in
 some v2 messages require less bandwidth then v1
* the key derivation and what communication direction uses what key is now more
 specific

First benchmarks of the used primitives
https://github.com/bitcoin/bitcoin/pull/15519#issuecomment-469705289 


Benchmark of the AEAD compared to the HASH (double SHA256)
(Indicates that v2 messages may be more performant):
https://github.com/bitcoin/bitcoin/pull/15649#issuecomment-475782376 



Proposal:


  BIP: ???
  Layer: Peer Services
  Title: Version 2 Peer-to-Peer Message Transport Protocol
  Author: Jonas Schnelli 
  Status: Draft
  Type: Standards Track
  Created: 2019-03-08
  License: PD


== Abstract ==

This BIP describes a new Bitcoin peer to peer transport protocol with
opportunistic encryption.

== Motivation ==

The current peer-to-peer protocol is partially inefficient and in plaintext.

With the current unencrypted message transport, BGP hijack, block delay attacks
and message tempering are inexpensive and can be executed in a covert way
(undetectable MITM)[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
Zohar, L.Vanbever].

Adding opportunistic encryption introduces a high risk for attackers of being
detected. Peer operators can compare encryption session IDs or use other form
of authentication schemes [https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
BIP150] to identify an attack.

Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256
checksum truncated to 4 bytes. Roughly the same amount of computation power
would be required for encrypting and authenticating a peer-to-peer message with
ChaCha20 & Poly1305.

Additionally, this BIP describes a way how data manipulation (blocking or
tempering commands by an intercepting TCP/IP node) would be identifiable by the
communicating peers.

Encrypting traffic between peers is already possible with VPN, tor, stunnel,
curveCP or any other encryption mechanism on a deeper OSI level, however, most
of those solutions require significant knowhow in how to setup such a secure
channel and are therefore not widely deployed.

== Specification ==


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119[https://tools.ietf.org/html/rfc2119
RFC 2119].


A peer that supports the message transport protocol as defined in this proposal
MUST accept encryption requests from all peers.

Both communication direction share the same shared-secret but have different
symmetric cipher keys.

The encryption handshake MUST happen before sending any other messages to the
responding peer.

If the responding peer closes the connection after sending the handshake
request, the initiating peer MAY try to connect again with the v1 peer-to-peer
transport protocol. Such reconnects allow an attacker to "downgrade" the
encryption to plaintext communication and thus, accepting v1 connections MUST
not be done when the Bitcoin peer-to-peer network uses almost only v2
communication.


=== NODE_P2P_V2 ===

Peers supporting the transport protocol after this proposal MUST signal
NODE_P2P_V2

NODE_P2P_V2 = (1 << 11)


A peer usually learns an address along with the expected service flags which
MAY be used to filter possible outbound peers.

A peer signaling NODE_P2P_V2 MUST accept encrypted communication
specified in this proposal.

Peers MAY only make outbound connections to peers supporting
NODE_P2P_V2.

=== Handshake ===


 

 | Initiator Responder  
|
 |  
|
 | x, X := SECP256k1_KEYGEN()   
|
 | CLIENT_HDATA := X 

Re: [bitcoin-dev] Overhauled BIP151

[Jonas Schnelli via bitcoin-dev]

Hi Tim

Thanks for the feedback.

I agree with all of Gregs answers.

> key. Together with the encrypted packet lengths, the entire data stream looks 
> like random then,
> which is pretty useful against censorship resistance for example. (The only 
> exception is that the
> stream will never start with the magic bytes.)

All-or-none censorship attacks are out of scope for BIP151.
We won’t achieve DPI robustness in this proposal and I think it should not be 
part of the p2p protocol.

I think all-or-one censorship situations require an additional layer like TOR 
with OBFS4 (where AFAIK Eligator is used).
Eventually Core does directly support non-tor routed pluggable transports (it's 
partially already possible via SOCK proxy, but not on a gossip and 
plugin-launch level).

This does not exclude that we should obfuscate the key exchange as good as we 
can without blowing up the implementation too much.

The proposed encryption adds a robustness to the thread model with very little 
costs and low risks.

>   "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should 
> just avoid this issue.

This is a good point and I’d like to see more concrete examples how this (the 
non dynamic salt) could be exploited.

> Re-keying
> =
> The problem with signalling re-keying in the length field is that the length 
> field is not covered
> by the MAC. So the attacker can flip the signalling bit. The resulting 
> protocol is probably still
> secure but the malleability is certainly not desirable.

In ChaCha20Poly1305@openssh, the length field is AAD, encrypted with a 
different key and part of the MAC.

> 
> Deterministic rekeying rules may be better. Otherwise there will be 
> implementations that rekey
> every 10 seconds and implementations that just don't rekey at all (rendering 
> the 10 s rekeying
> interval in the opposite direction useless). Different policies also make it 
> possible to
> fingerprint implementations. Another problem is that people will set their 
> policies arbitrarily.
> What's better: 5 min or 30 min? I don't know, but both are reasonable 
> choices. (Thats's very much
> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? 
> I don't know, but
> again both are reasonable choices.)

The Rekey cost is two times a double-SHA256,… the costs of a rekey is similar 
to one or two v1 INV message creations.

> 
> Symmetric crypto
> 
> You call it chacha20-poly1305@bitcoin but what's the difference to the 
> openssh then? Is the
> idea to save a call to chacha here as you mentioned?
> 
> I didn't think about this in detail: maybe there are a few meaningful cases 
> where padding could
> hide the message length without too much overhead. (I'm not convinced, just a 
> random thought.)

I think a new message type that could contain message + pad would be trivial.
Would this again be to obfuscate traffic patterns? Anti DPI is not the scope of 
BIP151.

> 
> Misc
> 
> "The ID/string mapping is a peer to peer arrangement and MAY be negotiated 
> between the
> requesting and responding peer." I think that's overly complicated. I suggest 
> it should just be
> written in stone, again to avoid complexity and to avoid fingerprinting. New 
> implementations are
> necessary anyway, so maybe just use IDs for anything? ASCII is nice if you 
> want to debug your code
> or some random network failure but that's hard anyway when encryption is used.

I wanted to avoid too much central planing here and only cover the ones where 
it's most efficient (small messages that are used often).
The ASCII commands are in itself somehow pseude-robust against collision.
For a 1MB block message, using a 1-byte short ID (rather then a 6-byte ASCII 
command) would reduce the bandwidth requirement insignificant (99.99952%).

If we would always have used short IDs in the past, there could have been a 
collision between XTIN, compact, sendheaders or so.

> 
> In general, the entire thing is a little bit underspecified. (I'm aware it's 
> just a draft.)
> A few examples:
> - What should a peer do if the MAC verification fails?
> - What should a peer do if it receives an even key?
> - "Processing the message before the authentication succeeds (MAC verified) 
> MUST not be done."
> That should also apply to the ciphertext. (Or: What is a "message"?). It may 
> be a good idea to
> to refer to the openssh document or steal from it; it does a pretty good job.
> - "Both peers MUST keep track of the message sequence number (uint32) of sent 
> and received
> messages for building a 64-bit symmetric cipher IV." I think you mean nonce 
> when you say IV?
> - What is the initial value of the sequence number?

Good points. Will make them more clear in the BIP.
I was under the false impression that it is obvious to disconnect in those 
cases.

> - How is a 64-bit nonce formed from one (two?) uint32?

That’s specified in ChaCha20Poly1305@openssh ("a nonce consisting of the packet 
sequence n

[bitcoin-dev] Overhauled BIP151

[Jonas Schnelli via bitcoin-dev]

Hi

During work on the implementation of BIP151 [1] I figured out that the current
published proposal could be further optimized.

I wrote an overhauled BIP151 specification with some – partially radical –
changes.

Now it’s unclear to me if this should be published under a new BIP nr. or if it
is acceptable to change the existing 151 proposal.
If a new BIP number would be required, I think withdrawing BIP151 should be
done (which somehow indicates we should alter 151).

The only BIP151 implementation I’m aware of is the one from Armory [2].
BCoins implementation has been removed [3].

The new proposal draft is available here:
https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52

Major changes
=
- the encryption handshake no longer requires the v1 protocol, it’s a pure
  32bytes-per-side „pseudorandom" key exchange that happens before anything 
else.
- the multi message envelope has been removed.
- a new NODE_ENCRYPTED service bit
- the key derivation and what communication direction uses what key is now more
  specific
- the length of a packet uses now a 3-byte integer with 23 available bits
- introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result 
in
  some v2 messages require less bandwidth then v1
- rekeying doesn’t require a message and can be signaled in the most
  significant bit in the packet-size field


Points that are in discussion and may be added to the BIP (or to a new one):

Hybrid NewHope key exchange
===
The current ECDH key exchange is vulnerable to Shor’s algorithm and is thus not
considered quantum-safe.
Following TORs approach [4] by adding a NewHope [5] key-exchange the handshake
protocol would very likely make the encryption PQ safe with little costs.
There is also a straight forward implementation [6] from the NewHope team that
has been submitted to NIST PQC project.

Inefficiency of ChaCha20Poly1305@openssh

The proposed AEAD could eventually be further optimized.
ChaCha20Poly1305@openssh uses at least three rounds of ChaCha20 which
eventually can be reduced to two (messages below <=64 bytes [inv, ping,
pong,...] only require one round of ChaCha20, but two for the Poly1305 key and
the message length encryption where the Poly1305 key chacha round „throws away“
32 bytes).


I would suggest that we don’t rehash discussions about the general
concept of encrypting the traffic. This has already been discussed [7][8].

I hope we can limit this thread to discuss further ideas for optimisation as 
well as
technical details of the published proposal or its implementation.


[1] https://github.com/bitcoin/bitcoin/pull/14032
[2] https://github.com/goatpig/BitcoinArmory/pull/510
[3] 
https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd439300708e662
[4] 
https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope
[5] https://eprint.iacr.org/2015/1092
[6] https://github.com/newhopecrypto/newhope

[7] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013565.html
[8] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html


Thanks


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] Building a Bitcoin API and query system.

[Jonas Schnelli via bitcoin-dev]

> The API implementation is not what is centralizing, nor is full indexation 
> non-scalable. The centralization is in not running the API from a node under 
> your own control. This is of course implied by the comment, “without the need 
> for syncing”. In other words it is the deployment cost of the node that is 
> centralizing.

IMO an API that serves non verifiable data is supporting centralised 
validation. The „API" which supports one of the most important properties in 
Bitcoin – the ability to self-validate – is the data available via the p2p 
network.

> 
> Yet if people relied only on bitcoind and never centralized services there 
> would be *no* block explorers (and no secure light wallets), because it does 
> not provide remote query and does not fully index.
> 
> Block explorers and light wallets are pretty useful, so presumably some API 
> must provide these features (ideally with reduced deployment cost). That will 
> either be centralized or decentralized services. As such it seems wise to 
> encourage the latter, as opposed to questioning whether there is any valid 
> block explorer use case.

Bitcoin-Core has all required features to partially „index“ data (called the 
wallet) and provides them via the RPC API. If you don’t need to serve thousands 
of wallets (which smells after centralised validation), selective indexing 
(wallets) are the right choice. Also, if you have a proper light client 
architecture, you can use Bitcoin Core in pruned mode (<10GB of data) to serve 
an endless amount of wallets (client/server mode, I guess that is what you are 
referring to with "light clients").

I fail to see the use-cases where a fully index blockchain makes sense (the 
only one I can come up with is instant backup recovery where the transaction 
history needs to be preserved rather then recovering the UTXOs only).

Also, the p2p protocol has built in light client support with BIP37 (bloom 
filters) and soon BIP158 will be available on the network which does allow 
privacy-preserving "light clients" in a way where no trusted layer is required 
(client <-> p2p network rather then client <-> API provider <-> p2p network).

I don’t want to advocate against a full-index blockexplorer-like API. I just 
think its important to define the use case and be aware of the consequences and 
downsides.

/jonas


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] Building a Bitcoin API and query system.

[Jonas Schnelli via bitcoin-dev]

Hi

To give a critical viewpoint on a such API:

Such APIs usually result in central validation, meaning that users trust API 
services rather the validating their own data. It break some of the fundamental 
properties of Bitcoin (avoid trusted third parties).
Systems or applications depending on a full indexed blockchain (a thus such 
API) do usually scale pretty bad.

I’d like to hear some concrete use-cases for a such block explorer(ish) API.

Thanks
—
Jonas

> Am 26.08.2018 um 21:58 schrieb Blockchain Group via bitcoin-dev 
> :
> 
> Hello everyone,
> 
> I am C++ & Node.js developer. I want to propose making a new Bitcoin API that 
> supports fast quering of Bitcoin blocks and transactions without the need for 
> syncing with all previous nodes.
> 
> In a typical case where I want to build a full fleged Bitcoin explorer cum 
> wallet system on my end with external APIs, I need to sync my node and then 
> query for the information I need to show separately. I am proposing a unified 
> method of finding/quering the blockchain data with a standardized template 
> containing minimal information about the actual mined block or transaction 
> yet satify the need of what I want to query.
> 
> I am working on making a template and a support mechanism on Node.js. I want 
> to propose it as an improvement (BIP). It will be a great help to future web 
> developers who want to make something similar.
> 
> Thanks
> Sumit Lahiri.
> ___
> 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 174 thoughts

[Jonas Schnelli via bitcoin-dev]

Hi
> As was partially brought up by William, shouldn't we consider using
> bech32? It doesn't break on double-click and it is a dependency for
> native Segwit addresses anyway, so wallets might already support it or
> they will at some point. But we should probably run some numbers on this
> first, since bech32 will obviously be larger than base64.
I don’t think bech32 is a fit here.
Bech32 is a BCH where the error detecting properties are optimised for 1023 
chars max and in the special case of the Bech32 BCH, error detection of 4 chars 
are guaranteed with a max length of 90 chars.

/jonas


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 174 thoughts

[Jonas Schnelli via bitcoin-dev]

I agree with matejcik’s point 1 to 3 and especially with point 4.
The mandatory flag (or optional-flag) makes much sense to me.

> ---
> 
> In general, the standard is trying to be very space-conservative,
> however is that really necessary? We would argue for clarity and ease of
> use over space constraints. We think more straightforward approach is
> desired, although more space demanding. What are the arguments to make
> this as small as possible? If we understand correctly, this format is
> not intended for blockchain nor for persistent storage, so size doesn’t
> matter nearly as much.

I don’t see any reasons why space would be an issue.

HWWs probably can’t handle PBST natively since it is not optimised for
presenting various informations in a signing-verification.

A single stream-in of a PSBT through USB (or similar channel) will not work in
many cases since HWW come often with very restrictive RAM constraints.

Furthermore, I forget to mention in my last mail, that registering (or defining)
a mime-type for PSBT would probably a great usability feature.
(Send PSBT by email/messanger and with dbl-click to open feature, etc.)


/jonas


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 174 thoughts

[Jonas Schnelli via bitcoin-dev]

> * Key-value map model or set model.
> * Ability for Combiners to verify two PSBT are for the same transaction
> * Optional signing
> * Derivation from xpub or fingerprint
> * Generic key offset derivation
> * Hex encoding?

I think all of Pieters points are valid and reasonable thought, though I’m 
unsure if it would be worth changing the existing-implementation-breaking 
things like the k/v set model.
AFAIK things like non-hex-encoding or generic key offset derivation are 
extensions and would not break existing implementations.

Further thoughts on BIP174 from my side.

Key derivation in multisig:
From my understanding, the signers and the creator must have agreed – in 
advance to the PSBT use case – on a key derivation scheme.
BIP32 derivation is assumed, but may not always be the case.
Sharing xpubs (the chaincode) may be a concern in non-trust-relationships 
between signer(s) and the creator (regarding Pieters xpub/fingerprint concerns).
Providing the type 0x03, the bip32 derivation path is one form of a support to 
faster (or computational possible) derivation of the required keys for signing 
a particular input.
From my point of view, it is a support of additional metadata shared between 
creator and signer and provided from the creator to the signer for faster (or 
computation possible) key deviation.

I think it could be more flexible (generic) in BIP174.
It could be just a single child key {32-bit int}, or just a keypath ({32-bit 
int}]{32-bit int}…) which is very likely sufficient for a HWW to derive the 
relevant key without the creation of a lookup-window or other „maps".
It could even be an enciphered payload which was shared during 
address/redeem-script generation and „loops“ back during a signing request.

Maybe I’m overcomplicating things, but for practical multisig with HWWs, a 
simple BIP32-child-key-index or BIP32-keypath derivation support field should 
be sufficient.
A generic „derivation support field“, provided from the signer to the creator 
during address-generation that just „loops“ back during the PSBT use-cases is 
probably a overkill.


Thanks
—
/jonas



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] New serialization/encoding format for key material

[Jonas Schnelli via bitcoin-dev]

> I have some concerns about the use of Bech32. It is designed for
> detecting 3 errors up to length 1023 (but is then picked specifically
> to support 4 errors up to length 89). However, for error correction
> this translates to just being able to efficiently correct 1 error
> (3/2, rounded down) up to length 1023. You can of course always try
> all combinations of up to N changes to the input (for any N), testing
> the checksum, and comparing the results against the UTXO set or other
> wallet information that may have been recovered. However, the checksum
> at best gives you a small constant speedup here, not a fundamentally
> improved way for recovery.

Thanks Peter

I removed the part in the proposals that made false claims about the error
correction or cpu-intense key recovery.

I wrote some test code and figured out that my Core i7 machine can
do 31’775 operations per seconds of a addr-derivation-comparison
(bech32 decode, bip32 ckd, hash160, Base58check).
This is non-optimized code running non-parallelized.

Just in case someone wants to do more math here.

Without knowing to much about BCHs, ideally there would be a code that
includes the fact that computational costs for error correction can be very
high during a disaster recovery and that we can probably assume that the
user can provide a derivation element like a used address or pubkey.

Deriving one million child keys and comparing them against an address
table will take less than a minute on consumer systems.

> * correct 7 errors = 26 checksum characters (~ length * 1.25)
> 
> So it really boils down to a trade-off between length of the code, and
> recovery properties.

I think 5% error correction (7 errors at 555bits) with a 26 char checksum is
probably an acceptable tradeoff.

Resulting string with 26 checksum chars (mockup):
xp1qq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgnvv4zgnvv4zgnvv4zgngn
(140 chars)

Versus the bech32 (6 char checksum):
xp1qq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgn
(120 chars)

Versus an xpriv:
xprv9wHokC2KXdTSpEepFcu53hMDUHYfAtTaLEJEMyxBPAMf78hJg17WhL5FyeDUQH5KWmGjGgEb2j74gsZqgupWpPbZgP6uFmP8MYEy5BNbyET
(111 chars)

Not sure if the additional 20 characters make the UX worse.
Typing in +20 chars in a disaster recovery is probably acceptable.

> If there is interest, I can construct a code + implementation for any
> of these in a few days probably, once the requirements are clear.


Yes. Please.
Lets first wait for more feedback about the error robustness though.

Thanks
-
Jonas


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] New serialization/encoding format for key material

[Jonas Schnelli via bitcoin-dev]

Hi

The BIP proposal is now available here:
https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719

Reference C code is available here:
https://github.com/jonasschnelli/bech32_keys

Feedback, criticism, etc. welcome!

Thanks
—
Jonas


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] New serialization/encoding format for key material

[Jonas Schnelli via bitcoin-dev]

Hi

> - Visually Comparing two keys to find if they are same (Important)
> - Different wallet software could set different birthday/gap limit. creating 
> different xpub/xprv for the same set of mathematically derived individual 
> keys. This removes the decoupling between key and wallet metadata

What would be the downside of encoding the same key with different metadata 
(resulting in different "visual strings“)?
If you import it into the same software, it would be trivial to detect it. If 
you import it into another software, it probably doesn’t matter.

Visual comparing is eventually a broken concept (agree with Greg) and I doubt 
that this property is important, and IMHO basic metadata seems more important 
then this - very likely irrelevant - visual property.

Also, I think a recovery based on a sole xpriv (or + limited amount of 
meta-data as described in this proposal) is a disaster recovery (or forensic 
recovery).

Long term, I would wish, if wallet-metadata including transaction based user 
metadata would be backed up - after encrypted with a key that can be derived 
from the seed - in a way, where you need the seed to recover that backup thus 
it can be stored in cheap, insecure spaces.

> 
> In fact, same could be argued to add birthday to WIF private key format to 
> let wallet discover funds faster.
> 

The proposal I made can be seen as a replacement for WIF (it can replace WIF 
and xpriv/xpub) since it can encode a single private key into 275bits (still 
pretty short Bech32 string).

/jonas


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] New serialization/encoding format for key material

[Jonas Schnelli via bitcoin-dev]

Hi

Extended public and private keys are defined in BIP32 [1].

Encoded extended private keys should not be confused with a wallet „seed“
(proposals like BIP39) while they can also partially serve the purpose to
„seed“ a wallet (there may be an overlap in the use-case).

Recovering a wallet by its extended private master key (xpriv; may or may not
be at depth 0) is a complex task with risks of failing to recover all available
funds.

It may be reasonable to consider that recovering a wallet purely based on the
existence of an extended private master key is a forensic funds recovery
process and should probably be the last resort in case of a backup-recovery
situation. A simple example here is, that it was/is possible to have used an
xpriv (referring to extended private master key) in production that is/was used
to derive BIP45 based P2SH multisig addresses (1of1, used by Bitpays BWS for
while), later used for bare BIP45ish multisig 1of1 as well as for P2PKH after
BIP44 & vanilla BIP32 P2WPKH (m/0’/k’).
I’m not aware of any wallet that would recover 100% of those funds, leading to
the risk that forwarding the unspents and destroying the extended master key
may result in coins forever lost.

The case above may be an edge case, but I’m generally under the assumption that
recovering funds based on the sole existence of an xpriv (or seed) without 
further
metadata is a fragile concept.

Second, the missing birthday-metadata tend to lead to non-optimal blockchain
scans (eventually increased p2p traffic). Recovering funds can take hours.

Additionally, the BIP44 gap limit seems to be a weak construct. The current gap
limit in BIP44 is set to 20 [2] which basically means, handing out more then 20
incoming payment requests (addresses) results in taking the risks that funds
may be destroyed (or at least not detected) during a recovery.
The Gap limit value may also depend on the use case, but the current proposals
do not allow to set an arbitrary value. High load merchants very likely need a
different gap limit value then individuals create a transaction once a year.

During creation time of an xpriv/xpub, it is impossible to know if the created
xpriv will be used for an unforeseen derivation scheme. Future proposals may
want to limit an extended key to a single derivation scheme.


This is an early draft in order to allow discussion that may lead to a possible
proposal.
This proposals could also make BIP 178 obsolete since it can be replace the
WIF[3] standard.


Thanks for feedback
/jonas





Titel
##
Bech32 encoded key material including metadata

Abstract

An error tolerant encoding format for key material up to 520bits with a minimal
amount of metadata.

Motivation
##
(See above; intro text)


Specification
#

## Serialization format

1 bit version bit
15 bits (bit 1 to 16) key-birthday (0-32767)
(12 bit gap limit)
3 or 5 bits script type
256 or 512 or 520 bits key material
= Total 275, 545, 553 bits

The initial version bit allows extending the serialization-format in future.
The encoding format must hint the total length and thus allow to calculate the
length of the key material.

The total length for 256 or 512 bit key material is optimised for Bech32 (power
of 5).

### Key material
If the key material length is 520 bits, it must contain an extended public key
If the key material length is 512 bits, it must contain an extended private key
Key material length other then 256, 512, 520 bits and invalid.

If 520 bits are present, first 256 bits are the BIP32 chain code, to second 264
bits (33 bytes) define the public key (according to BIP32)

If 512 bits are present, first 256 bits are the BIP32 chain code, to second 256
bits define the private key

If 256 bits are present, those bits represent a pure private key (or seed)

### Key birthday
A 15 bit timestamp expressed in days since genesis (valid up to ~2098). The
birthday must be set to the first possible derivation of the according extended
key, if unknown, the used seed birthday must be used. If both unknown, 0
(16x0bit) must be used.

### Gap limit delta
12 bits, results in a possible range from 0 to 4095.

If the total decoded serialization length is 275 bits (decode) or if the key
material is 256 bits (encode), the gap limit must not be present.

The base gap limit value is 20 (to disallow insane gap limits). The final gap
limit is the base value + the gap limit delta stored in those 12 bits.
Key derivation gap limit must not be exceeded when deriving child keys and must
be respected during transaction rescans.
Child key derivation must not be possible if gap limit is hit.

### Script type restriction
3 or 5 bits (range 0-7 / 0-31)
0 no restriction
1 P2PKH compressed
2 P2PKH | P2SH
3 P2WPKH P2WSH nested in P2SH
4 P2WPKH | P2WSH

If the total decoded serialization length is 275 bits (decode) or if the key
material is 256 bits (encode), 3 bits are used for the script type. 5 bits are
used fo

Re: [bitcoin-dev] Moving away from BIP37, unsetting NODE_BLOOM

[Jonas Schnelli via bitcoin-dev]

Hi Caius

Thanks for brining this up.
As far as it looks, one of the major SPV library does not yet respect the 
NODE_BLOOM service flag [1]. Unsure sure about others.

It think disabling NODE_BLOOM services by default in full node implementations 
makes sense as soon as BIP158 [2] (compact block filters) has been implemented 
and therefore NODE_COMPACT_FILTERS is signalled broadly. Unsure if it would 
make sense to even wait for block filter commitment softfork (probably no).

Then, the question is, if there are alternatives for mempool filtering (display 
unconfirmed transactions) or if the protocol recommendation are to disable that 
by default or recommend to use centralised filtering technique via wallet 
provider infrastructure (privacy?!).

I guess everyone here agrees that there are major privacy and load-distribution 
issues with BIP37, and, that it should be disabled in the long run.
But, due to the lack of alternatives, there is the risk of breaking existing 
SPV client models and thus pushing users to complete centralised 
validation-solutions (and even towards centralised key-storage), which, may 
result in making privacy and security even more worse.

I personally miss a long term concept how to keep non expert users (or say 
light clients) close to the p2p protocol in a decentralized fashion. Unclear 
how decentralized fee estimations and „incoming transactions“ (which is 
something users want even if it's a broken concept) are handled in the future.

—
/jonas

[1] https://github.com/bitcoinj/bitcoinj/pull/1212
[2] https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki

> Am 16.05.2018 um 23:22 schrieb Caius Cosades via bitcoin-dev 
> :
> 
> As previously discussed[0][1][2] on the mailing list, github issue 
> commentary, and IRC channels, there's substantial reason to disable BIP37 in 
> network nodes which are getting stronger as the size of the chain increases. 
> BIP37 has significant denial of service issues which are unsolvable in the 
> design, it introduces undue load on the bitcoin network  by default, and 
> doesn't provide an acceptable amount of security and reliability to 
> "lightweight wallets" as originally intended.
> 
> BIP37 allows "lightweight wallets" to connect to nodes in the network, and 
> request that they load, deseralize, and expensively apply an arbitrary bloom 
> filter to their block files and mempool. This should never have been the role 
> of nodes in the network, rather it should have been opt-in, or performed by a 
> different piece of software entirely. The inability of the nodes to cache the 
> responses or meaningfully rate limit them makes it detrimental to serve these 
> requests.
> 
> BIP37 was intended to have stronger privacy than it does in reality[3][4], 
> where effectively any node that can capture `filterload` and `filteradd` 
> responses can trivially de-anonymize an entire wallet that has connected 
> irrespective of the amount of noise they add to their filters. The connected 
> node lying by omission is undetectable by any wallet software, where they 
> will be lead to believe that there are no matching responses; this is 
> counter-able by further destroying privacy and loading down the network by 
> having multiple peers simultaneously return filter results and hoping that at 
> least one isn't lying.
> 
> NODE_BLOOM has been implemented already which allows nodes to signal in their 
> service message that they do, or do not support filtering. I suggest that in 
> the next major release this is defaulted to 0, and any software relying on 
> BIP37 move to using other filtering options, or another piece of dedicated 
> software to serve the requests. Future releases of the reference software 
> should remove BIP37 commands entirely.
> 
> 
> [0]: 
> https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu9xntf/?context=3
> [1]: https://github.com/bitcoin/bitcoin/issues/6578
> [2]: 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010535.html
> [3]: https://jonasnick.github.io/slides/2016-zurich-meetup.pdf
> [4]: https://eprint.iacr.org/2014/763.pdf
> ___
> 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] BloomFilter issue with segwit addresses

[Jonas Schnelli via bitcoin-dev]

Hi Andreas

Thanks for bringing this up and this seems indeed to be suboptimal.

> I wonder if Bitcoin Core would be willing to extend the BIP37 matching
> rules such that data elements in the witness are also matched against?

Bitcoin Core is not an identity that can be „willing to extend“ (or reject) a 
feature.
Someone needs to come up with a proposal (pull request).

Maybe an extension for BIP37 would make sense (*meh*).
Just inserting the witness data into the bloom filter seems to be an easy 
solution (CBloomFilter::IsRelevantAndUpdate())

/jonas


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] Electrum Personal Server alpha release

[Jonas Schnelli via bitcoin-dev]

Thanks Chris for sharing!

I’m following a similar approach where I’d like to share a more detailed 
specification soon.
Since Chris brought this up here, I’d like to shed some lights on that, very 
similar approach.

The idea is to have a Bitcoin Core instance running either with internal (Core) 
support for the proposed interface or via an external script (python bridge) 
while the later is probably preferable (hardened HTTPd, less impact on Core).

The idea is, that the interface can create new wallets (needs dynamic 
loading/unloading of wallets in Core), add addresses to a wallet (== add 
watch-only addresses).

Addresses on the client are only visible once they could be added via the 
interface to the Core wallet as watch only (avoid missing transactions, 
addresses can be pre-added by the client and used later)

New transactions can be created through the interface (which will use 
fundrawtransaction with watch-only-addresses in the background).
Coin selection, fee calculation, etc. would happened on the Core node.

Signing of transactions happens on the client (maybe BIP174).
Optionally, a 2of2 (or 2of3 with a backup key) could be achieved where the node 
would also hold a key to have some sort of „2FA“ if the node and the client 
environment are owned by the same person.

This would work with pruned nodes and can serve – depending on the used 
hardware – up to a couple of hundred wallets.

Backup restores (xpriv sweeps) are also possible via the UTXO set and take less 
then a minute and don’t require the full transaction history (or any kind of 
index).

Additional, the interface could also act as central, personal multisig bridge 
where n clients could use the same endpoint to participate in multisig wallets.

Overall, this wold allow a slick and secure (personal or group) (multi-)wallet 
service that works perfectly fine on pruned nodes by simply adding a 
bridge-script.


Thanks
—
Jonas


> Am 09.02.2018 um 03:51 schrieb Chris Belcher via bitcoin-dev 
> :
> 
> Electrum is a popular bitcoin wallet, but it is not a full node wallet
> as it synchronizes itself using third-party Electrum servers. The
> servers must be trusted to verify the rules of bitcoin, they can trick
> Electrum wallets into accepting fake bitcoin transactions which, for
> example, print infinite money. Bitcoin's security model requires that
> most economic activity is backed by full nodes. The Electrum servers
> must also be trusted with the user's privacy, as wallets send all their
> bitcoin addresses to the server. Spying on wallets is not much more
> complicated than simply grepping the server logs. Electrum wallets by
> default also connect to servers using their own IP address, linking it
> further to their revealed bitcoin addresses.
> 
> A way to avoid these problems is for users to run their own Electrum
> server and connect their wallets only to it. But this requires
> significant resource usage: the full unpruned blockchain, transaction
> index and an extra address index, as well as more RAM and CPU usage
> compared to just a full node. Servers are not well suited to being shut
> down and started up again, they are typically always online.
> 
> Electrum servers store a database of every bitcoin address ever used,
> which is inherently not scalable. This is resource-intensive and
> therefore pushes users towards centralized solutions. An alternative way
> would be to store only your own addresses and transactions.
> 
> Introducing Electrum Personal Server; an implementation of the Electrum
> server protocol which fulfills the specific need of using the Electrum
> UI with full node verification and privacy, but without the heavyweight
> server backend, for a single user. It allows the user to benefit from
> all of Bitcoin Core's resource-saving features like pruning, blocksonly
> and disabled txindex. All of Electrum's feature-richness like hardware
> wallet integration, multisignature wallets, offline signing, mnemonic
> recovery phrases and so on can still be used, but backed by the user's
> own full node.
> 
> An alpha version of Electrum Personal Server can be found on the
> repository: https://github.com/chris-belcher/electrum-personal-server
> 
> Before using, the wallet user must configure Electrum Personal Server
> with their master public key and those addresses are imported into
> Bitcoin Core as watch-only. If the wallet contains historical
> transactions then it must be rescanned. One of Electrum's motivating
> features is "instant on", which is therefore traded away when using
> Electrum Personal Server in return for full node verification and
> privacy. Although if a brand new empty wallet is created there is no
> need to rescan. A script like Electrum Personal Server is also well
> suited to use private transaction broadcasting tech like dandelion or
> broadcasting through tor.
> 
> Using Electrum with Electrum Personal Server is probably the most
> resource-efficient way right now to use a hardware wall

Re: [bitcoin-dev] Block compression

[Jonas Schnelli via bitcoin-dev]

Hi Jeff

There where previous discussions about similar approaches [1] [2].

I’m not sure if compression should be built into the protocol.
My humble understanding of it, is, that it should be built into different 
layers.

If bandwidth is a concern, then on the fly gzip compression like apaches 
mod_deflate could be something. But I expect fast propagation is often more 
important then a ~30% bandwidth reduction.
Bandwidth may be a concern for historical blocks transmission. If you continue 
the proposal, I think you should focus on historical blocks.

If disk space is a concern, then the database layer should handle the 
compression.

Thanks
—



[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011692.html
 

[2] https://github.com/bitcoin/bitcoin/pull/6973 




> Am 26.11.2017 um 16:11 schrieb Jeff Johnson via bitcoin-dev 
> :
> 
> I'm new to this mailing list and apologize if this has been suggested before. 
> I was directed from the Bitcoin core github to this mailing list for 
> suggestions.
> 
> I'd just like to post a possible solution that increases the amount of data 
> in a block without actually increasing the size on disk or the size in memory 
> or the size transmitted over the Internet. Simply applying various 
> compression algorithms, I was able to achieve about a 50% compression ratio. 
> Here are my findings on a recent Bitcoin block using max compression for all 
> methods:
> 
> Raw block
> 998,198 bytes
> 
> Gzip
> 521,212 bytes (52% ratio)
> (needs 2MB to decompress).
> 
> LZMA
> 415,308 bytes (41% ratio)
> (1MB dictionary, needs 3MB to decompress)
> 
> - ZStandard: 469,179 bytes (47% ratio)
> (1MB memory to decompress)
> 
> - LZ4: 641,063 bytes (64% ratio)
> (32-64K to decompress)
> 
> The compression time on my modest laptop (2 years old) was "instant". I ran 
> all from the command line and did not notice any lag as I pressed enter to do 
> the compression, so easily less than a second. But compression time doesn't 
> matter, decompression time is what matters as blocks will be decompressed 
> billions of times more than they will be compressed. Decompression speed for 
> LZ4 is the fastest of the above methods, at 3.3GB / second, slightly less 
> than half the speed of memcpy, see char at (https://github.com/lz4/lz4 
> ).
> 
> If decompression speed, CPU and memory usage is a concern, LZ4 is a no 
> brainer. You basically get a 33% larger block size for "free". But ZStandard, 
> in my opinion, makes the most sense as it offers greater than 50% compression 
> ratio with a very good decompression ratio of 900MB / second.
> 
> If this were implemented in the Bitcoin protocol, there would need to be a 
> place to specify the compression type in a set of bits somewhere, so that 
> future compression algorithms could potentially be added.
> 
> Miners could do nothing and keep sending blocks as is, and these blocks would 
> have "no compression" as the type of compression, just as today. Or they 
> could opt in to compress blocks and choose how many transactions they want to 
> stuff into the block, keeping the compressed size under the limit.
> 
> The bitcoin client code would also need to be able to handle the appropriate 
> compression bits, and limits of signature data, etc. modified to deal with 
> the compression.
> 
> I understand schnorr signatures are on the roadmap as a 25% compression gain 
> which is great, I suspect that schnorr signatures would compress even further 
> when compressed with the above compression methods.
> 
> Here is a link to the block that I compressed: 
> https://mega.nz/#!YPIF2KTa!4FxxLvqzjqIftrkhXwSC2h4G4Dolk8dLteNUolEtq98 
> 
> 
> Thanks for reading, best wishes to all.
> 
> -- Jeff Johnson
> ___
> 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] BIP159 - NODE_NETWORK_LIMITED service bits, extendability

[Jonas Schnelli via bitcoin-dev]

Hi Sjors

Thanks for picking this up.

There where some previous discussions about this [1] [2].
Initially, the idea was to have two service bits to signal (up to three) states.
But, since it is not clear what use-cases the bits signalling >288 blocks would 
fulfil, I have limited BIP159 to a single 288blocks-available signalling.

Therefore, BIP159 aims to improve the block relay state around the tip (24h) 
which seems to be the most significant request peak (peers out of IBD).
Also, it takes an acceptable transition for pruned node operators into account. 
Once BIP159 gets active on the network, pruned peer operators may see an 
increase in CPU and bandwidth usage.

SPV peers may also connect to BIP159 nodes, scan the mempool and wait for 
unconfirmed transactions (they don’t do this now because pruned nodes don't 
signal any service).

Future extensions are possible. Maybe a p2p command that could tell more infos 
about the pruning state would be useful.

BIP159 also recommends to fix the fingerprinting weakness by fix limiting it to 
288 blocks, making it impossible for an attacker to fingerprint your peer by 
scanning how deep the peer can serve blocks. This may be a reduction for 
possible use cases with todays pruned peers and an idea would be to relax this 
limit for whitelisted peers (or peers connecting via BIP150 [not implemented], 
and this is the only connection between BIP150 and BIP159).

However, I think the scope of BIP159 should be kept as it is. More flexibility 
can be added later when we have gathered more information during BIP159 
deployment.
Also, the implementations is an advanced stage [3][4]

—


[1] https://botbot.me/freenode/bitcoin-core-dev/2017-04-27/?msg=84827228&page=3
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.html#14314
[3] https://github.com/bitcoin/bitcoin/pull/10387
[4] https://github.com/bitcoin/bitcoin/pull/11740


> Am 21.11.2017 um 04:03 schrieb 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
> 

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

[Jonas Schnelli via bitcoin-dev]

> 
> uhh do you apply this logic to the bitcoin-core wallet itself?
> because clearly it generates keys and is intended to be used for signing
> in online environments.  Lots of real-world use-cases depend on that today.

The current Bitcoin Core wallet setup is not as ideal as it could be.
An good example is, that the wallet and the full node (the p2p logic on 8333) 
do share the same process (same memory space).
AFAIK a lot of users use Core in watch-only mode and do the signing offline 
(offline / through HWWs).
Although, Core has currently no direct support for offline signing (expect the 
rawtx API which are pretty expert-ish).

The Core development process goes into that direction but it takes time due to 
the strict and extremely important code quality insurance.

> 
> So if existing bitcoin-core wallet behavior is "ok" in any context then
> how is it any worse for it to generate a key/address that will not be
> stored in the internal wallet, and the user may do with it as they wish?
> That is all my proposed RPC call does and unlike the existing RPC calls
> it never even stores the key or address to disk.  It is also useful when
> run on an offline hardware device, such as a laptop connected to an
> non-networked printer.

IMO we should make it better not worse.
Paper wallets delude to do address reuse, the spending-procedure is unclear, 
and very likely insecure.
A quick photo-snapshot by an attack may result in a full compromised key.
Printer buffers, etc. are also something to worry here.

> Further, you mention the word trust.  That's the crux of the matter.  As
> a full node operator, I've already placed my trust in the bitcoin-core
> developers and dev/release practices.  Why exactly should I trust the
> software in this minimal offline hardware/os you mention if it is NOT
> bitcoin core?  And even if open source software, does that not at least
> double my workload/expense to audit theat software in addition to
> bitcoin-core?

I think Bitcoin Core does a great job there. But not sure about other security 
layers are outside of Core.
Especially your operating system.
The reason why we see a growing demand in hardware wallets is probably because 
people no longer trust in current available operating systems as well as 
current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).

> 
>> Users should have no way to view or export the private keys (expect for
>> the seed backup).
> 
> I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
> be removed from bitcoin-core to fit this paradigm?

Yes. That actually something we are considering (especially if we would allow 
BIP44 or other HD public key derivation forms).
Also, we heard of "support sessions“ on IRC where attackers told victims they 
must enter „dumpprivkey“ in the Console and give them the output in order „to 
fix the problem“.

> (Personally I actively avoid wallet software that takes this view and
> treat users like children, preventing individuals direct access to the
> keys for their own funds, which disempowers and sometimes results in a
> form of lockin)

I dislike that as well – in general. But I guess most users like 
self-protection. Also, the user layer is attackable. If _you_ can access the 
private-keys, an attacker can do also. What most users want is a key-safe that 
only signs transactions which they could verify beforehand in a safe 
environment, and not a way to export private keys or something else that can 
touch the keys.


>> 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).
> 
> Is there really nothing existing yet to address all of this?

The answer is probably: No (for now). But working towards this should be the 
focus.


---
/jonas



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

[Jonas Schnelli via bitcoin-dev]

> 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].
> 

AFAIK, client implementations such as your proposal are off-topic for this ML.
Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such 
proposals.


> 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).


/jonas


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: Extended serialization format for BIP-32 wallets

[Jonas Schnelli via bitcoin-dev]

Thanks for the proposal.

Three points it could see as possible improvements:

1.
From what I know, the exact birthday in seconds doesn’t matter that much 
therefore it may be possible to just use 13 or 16bits to create a 
representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 
years.
Always round down to the beginning of the week when the key was created.
But not sure if it’s worth to save ~two bytes for that.
Also not sure if the key-birthday in seconds could have a security or privacy 
implication (week maybe better).

2.
Would it make sense to have special depth bytes that directly implies it’s a 
BIP44 master key (and therefore avoid the bip32 path serialisation)? I know 
some „centralised“ table need to be available for that which may be not a good 
idea. But maybe the BIP could reserve a couple of depth-bytes (maybe 0xF0 to 
0xFF) for predefined paths.

3.
Would adding a version bit make sense to allow future extensions?


/jonas


> Am 06.09.2017 um 15:29 schrieb Pavol Rusnak via bitcoin-dev 
> :
> 
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
> 
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
> 
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
> 
> Feel free to comment.
> 
> --
> Best Regards / S pozdravom,
> 
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> ___
> 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] Would anyone object to adding a dlopen message hook system?

[Jonas Schnelli via bitcoin-dev]

Hi Erik

Thanks for your proposal.
In general, modularisation is a good thing, though proposing core to add 
modules wie dlopen() seems the wrong direction.
Core already has the problem of running to many things in the same process. The 
consensus logic, p2p system as well as the wallet AND the GUI do all share the 
same process (!).

A module approach like you describe would be a security nightmare (and Core is 
currently in the process of separating out the wallet and the GUI into its own 
process).

What does speak against using the existing IPC interfaces like RPC/ZMQ?
RPC can be bidirectional using long poll.

/jonas

> I was thinking about something like this that could add the ability for 
> module extensions in the core client.
> 
> When messages are received, modules hooks are called with the message data.
> 
> They can then handle, mark the peer invalid, push a message to the peer or 
> pass through an alternate command.  Also, modules could have their own 
> private commands prefixed by "x:" or something like that.
> 
> The idea is that the base P2P layer is left undisturbed, but there is now a 
> way to create "enhanced features" that some peers support.
> 
> My end goal is to support using lightning network micropayments to allow 
> people to pay for better node access - creating a market for node services.
> 
> But I don't think this should be "baked in" to core.   Nor do I think it 
> should be a "patch".   It should be a linked-in module, optionally compiled 
> and added to bitcoin conf, then loaded via dlopen().Modules should be 
> slightly robust to Bitcoin versions changing out from under them, but not if 
> the network layer is changed.   This can be ensured by a) keeping a module 
> version number, and b) treating module responses as if they were just 
> received from the network.   Any module incompatibility should throw an 
> exception...ensuring broken peers don't stay online.



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] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options

[Jonas Schnelli via bitcoin-dev]

Hi Colin

> In case the server goes rogue and starts refusing to sign, the user can use 
> their userRecoveryPrivKey to send the funds anywhere they choose. Because if 
> this, the userRecoveryPrivKey is best suited to cold wallet storage.

Would you then assume that userWalletPubKey is a hot key (stored on the users 
computer eventually in a browser based local storage container)?
In case of an attack on the server responsible for serverWalletPubKey (where 
also the personal information of the user are stored [including the xpub == 
amount of funds hold by the user)), wound’t this increase the users risk of 
being an possible target (False sense of multisig security, comparing to cold 
storage / HWW keys)?

> In the more likely event that the user forgets their password and/or looses 
> access to their userWalletPrivKey as well as loses their recovery key, they 
> rely on the serverRecoveryPrivKey.
> 
> When the user first sets up their wallet, they answer some basic identity 
> information, set up a recovery password, and/or set up recovery questions and 
> answers. This information is explicitly NOT sent to serve with the exception 
> of recovery questions (although the answers remain with the user, never 
> seeing the server). What is sent to the server is it's 256 bit hash used to 
> identify the recovery wallet. The server then creates a 1025 bit nonce, 
> encrypts it, stores it, and transmits it to the user's client.

I guess this will result in protecting the funds stored in this transaction 
entirely on the users identity information and eventually the optional recovery 
password, though I guess you are adding additional security by protecting via 
the server nonce from brute-forcing.

Why 1025bit for the nonce?
Why SHA512 instead of SHA256 (I guess you need 256bit symmetric key material 
for the key encryption)?
Considered using a (H)KDF for deriving the symmetric key (even if the server 
based nonce reduces the possibility of brute-forcing)?

Your modal has probably the TORS (trust on recovery setup) weakness (compared 
to a HWW where you [should] be protected on compromised systems during private 
key creation).




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] A Segwit2x BIP

[Jonas Schnelli via bitcoin-dev]

> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.

Tested? Where?
However, the hardfork part may be out there for a long time but  _is still 
broken_.

/jonas


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: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

>> 
>> I think many users would be willing ...
>> a) … to trade higher privacy (using client side filtering) for not having
>> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
>> all inved transactions
> 
> You seem to misunderstand the usecase.
> If you send me a transaction, both of use are using our phones, then I need
> to be able to have immediate feedback on the transaction being broadcast on
> the network.
> This is not about zero-conf, this is simple seeing what is happening while
> it is happening.
> 
> Additionally, when the transaction that is meant for my wallet is broadcast,
> I want my SPV wallet to parse and check the actual transaction.
> It is not just to see that *something* was actually send, but also to be
> able to see how much is being paid to me. Maybe If the transaction is marked
> as RBF-able, etc.
> 
> Really basic usability: provide information to your users when you can,
> should they want to, and by default on.

I see this use case.
But I did receive bank wire transfers for the last decades without 
_immediately_ knowing that someone sent funds to me.
I personally would ALWAYS trade the higher bandwidth consumption (300MB mempool 
filtering) or slower notification time (maybe ~1h) for preserving privacy.
I agree, there are use cases where you want immediate notification, those use 
cases could probably be solved by not trowing away privacy („parsing“ all 
transactions and running in the background).

/jonas


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: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

> 
> On the other hand, I remember only 1 (one) inquiry about the privacy
> problems of BIP37 (or privacy at all).

IMO privacy its something developers should make sure users have it.
Also, I think, todays SPV wallets should make users more aware of the possible 
privacy implications.

Do users know, if they pay for a good in a shop while consuming the shops WIFI, 
that the shop-owner as well as the ISP can use that data to combine it with the 
user profile (and ~ALL FUTURE purchases you do with the same wallet IN ANY 
LOCATION online or in-person)?

Do users know, that ISPs (cellular; including Google) can completely link the 
used Bitcoin wallet (again: all purchase including future ones) with the to the 
ISP well known user profile including credit-card data and may sell the Bitcoin 
data to any other data mining company?

If you use BIP37, you basically give your transaction history (_ALL 
TRANSACTIONS_ including transactions in future) to everyone.


> 
> From a regular user's point of view, privacy is non-issue. Sure,
> everyone would take it for free, but certainly not if it a) delays
> incoming payments or b) quickly eats up your traffic quota.

This may be true because they are not aware of the ramification and I don’t 
think client side filtering is a drop-in replacement for todays, smartphone 
SPV-model.


/jonas


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: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

> Just to give you a number: based on the statistics of the Bitcoin Wallet
> app there are at least 2 million wallets depending on BIP37. Not all
> would need instant notification but based on the daily support enquiries
> instant notificaton is the most asked property of Bitcoin.

Yes. Users probably like this feature and client side filtering is not a 
drop-in replacement for BIP37.

We should also consider:
BIP37 works, because node-operators are willing to offer that service for free 
(which maybe change over time).
BIP37 consumes plenty of horsepower (disk/cpu) from nodes. Filtering a couple 
of days of blocks (assume 1000+) eats lots of resources for something, that has 
no direct long-term value for Bitcoin (the filters data is unique and will be 
"thrown away“ [can’t be used by other peers]). Same applies for mempool 
(filtering mempool of a couple of hundred of mb each time the HD gap limit has 
been exceeded or the app gets sent to the foreground again).

Purely relying on the availability of BIP37 seems fragile to me and start to 
explore other ways is very reasonable.

/jonas


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: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

Hi

> On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
>> It's been debated if [filtering of] unconfirmed transactions are
>> necessary,
> 
> Why would it not be needed? Any SPV client (when used as a payment-receiver)
> requires this from a simple usability point of view.


I think many users would be willing ...
a) … to trade higher privacy (using client side filtering) for not having the 
„incoming transaction“ feature
b) – if they want 0-conf – to fetch all inved transactions
/jonas


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] Bitcoin pointers

[Jonas Schnelli via bitcoin-dev]

Hi José

> a) Canonical Pointers
> The basic proposal.They look like this example: btc@170.1/179-631-520
> Here is a link to the Google Docs document ->  
> https://docs.google.com/document/d/1PBN4wKFYtgvDxV4DrWUdNe9Xqmb8GVxoIGDKRkY9Xr4/edit?usp=sharing
>  
> 
A similar/related proposal got posted last month : 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014396.html 

The Bech32 encoded transaction position reference allows to solve similar use 
cases (tx pointers) with a strong error-detection/correction using just 14 
chars (encoded state, including error correction / unencoded 40bits).

/jonas


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: NODE_NETWORK_LIMITED service bits

[Jonas Schnelli via bitcoin-dev]

> Is 49 days particularly useful? Would it be a problem to instead leave both-
> bits undefined? I'm thinking this might be better as a way to indicate "7
> days, plus a deterministically chosen set of historical blocks"…

I though two service bits allow three states and we should define all three 
combinations.
But I guess an adequate „definition“ would be to reserve it for future 
„definitions“.
Or use Gregory's proposal of min 2016*2 blocks & keep it „undefined“ for now.

49 days was chosen to allow SPV peers to be „offline“ for a month and still be 
capable to catch-up with a peer pruned to a datadir of ~10GB.

> 
> This is technically true right now, but as soon as segwit activates, it will
> no longer be... Therefore, I suggest striking it from the BIP, expounding on
> it in greater detail, or making it true for the longer term.

AFAIK Core does also guaranteed the 288 blocks post segwit activation:
https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204
But maybe I’m confused.

> 
>> Peers following this BIP SHOULD connect a limited amount of their available
>> outbound connections to peers signaling one or both of the
>> NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks
>> than the signaled number.
> 
> This isn't entirely clear whether it refers to peers downloading blocks, or
> peers serving them. (I assume the former, but it should be clarified.)

Indeed. I’ll try to make that more clear.

> 
>> Light clients (and such) who are not checking the nServiceFlags (service
>> bits) from a relayed addr-message may unwillingly connect to a pruned peer
>> and ask for (filtered) blocks at a depth below their pruned depth.
> 
> Wouldn't this already be a problem, without the BIP?

AFAIK, Core does currently only relay NODE_NETWORK addresses.
But yes, It may be a problem already.





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 proposal: NODE_NETWORK_LIMITED service bits

[Jonas Schnelli via bitcoin-dev]

Hi

Currently, pruned peers have no way how to signal their (valuable) service.
A BIP proposal to improve this (draft):
https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT 


Feedback is highly welcome.




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] Small Nodes: A Better Alternative to Pruned Nodes

[Jonas Schnelli via bitcoin-dev]

Hi Dave

> A node that stores the full blockchain (I will use the term archival node) 
> requires over 100GB of disk space, which I believe is one of the most 
> significant barriers to more people running full nodes. And I believe the 
> ecosystem would benefit substantially if more users were running full nodes.


Thanks for your proposal.

I agree that 100GB of data may be cumbersome for some systems, especially if 
you target end user systems (Laptops/Desktops). Though, in my opinion, for 
those systems, CPU consumption is the biggest UX blocker.
Bootstrapping a full node on a decent consumer system with default parameters 
takes days, and, during this period, you probably run at full CPU capacity and 
you will be disturbed by constant fan noise. Standard tasks may be impossible 
because your system will be slowed down to a point where even word processing 
may get difficult.
This is because Core (with its default settings) is made to sync as fast as 
possible.

Once you have verified the chain and you reach the chain tip, indeed, it will 
be much better (until you shutdown for a couple of days/hours and have to 
re-sync/catch-up).

1. I agree that we need to have a way for pruned nodes to partially serve 
historical blocks.
My personal measurements told me that around ~80% of historical block serving 
are between tip and -1’000 blocks.
Currently, Core nodes have only two modes of operations, „server all historical 
blocks“ or „none“.
This makes little sense especially if you prune to a target size of, lets say, 
80GB (~80% of the chain).
Ideally, there would be a mode where your full node can signal a third mode „I 
keep the last 1000 blocks“ (or make this more dynamic).

2. Bootstrapping new peers
I’m not sure if full nodes must be the single point of historical data storage. 
Full nodes provide a valuable service (verification, relay, filtering, etc.). 
I’m not sure if serving historical blocks is one of them. Historical blocks 
could be made available on CDN’s or other file storage networks. You are going 
to verify them anyways,... the serving part is pure data storage.
I’m also pretty sure that some users have stopping running full nodes because 
their upstream bandwidth consumption (because of serving historical blocks) was 
getting intolerable.
Especially „consumer“ peers must have been hit by this (little experience in 
how to reduce traffic, upstream in general is bad for consumers-connections, 
little resources in general).

Having a second option built into full nodes (or as an external bootstrap 
service/app) how to download historical blocks during bootstrapping could 
probably be a relieve for "small nodes“.
It could be a little daemon that downloads historical blocks from CDN’s, etc. 
and feeds them into your full node over p2p/8333 and kickstarts your 
bootstrapping without bothering valuable peers.
Or, the alternative download, could be built into the full nodes main logic.
And, if it wasn’t obvious, this must not bypass the verification!

I’m also aware of the downsides of this. This can eventually reduce 
decentralisation of the storage of historical bitcoin blockchain data and – 
eventually – increase the upstream bandwidth of peers willing to serve 
historical blocks (especially in a transition phase to a second 
„download“-option).
Maybe it’s a tradeoff between reducing decentralisation by killing low resource 
nodes because serving historical blocks is getting too resource-intense _or_ 
reducing decentralisation by moving some percentage of the historical data 
storage away from the bitcoin p2p network.
The later seems more promising to me.


To your proposal:
- Isn’t there a tiny finger-printing element if peers have to pick an 
segmentation index?
- SPV bloom filter clients can’t use fragmented blocks to filter txns? Right? 
How could they avoid connecting to those peers?




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] Unique node identifiers (and BIP150)

[Jonas Schnelli via bitcoin-dev]

Hi Tom

> Do you know the trick of having an open wifi basestation in a public street
> and how that can lead to tracking? Especially if you have a network of them.
> The trick is this; you set up an open wifi base station with a hidden ssid
> and phones try to connect to it by saying “Are you ssid=xyz?”
> This leads the basestation to know that the phone has known credentials with
> another wifi that has a specific ssid. (the trick is slightly more elaborate,
> but the basics are relevant here).
> 
> Your BIP is vulnarable to the same issue, as a node wants to connect using
> the AUTHCHALLENGE which has as an argument the hash of the person I’m trying
> to connect with.

This thread is not about BIP150/151.
The hash includes the encryption session which makes it impossible to distinct 
identities.

> 
> Your BIP says "Fingerprinting the requesting peer is not possible”.
> Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your
> hash never changes and as you connect to a node anyone listening can see you
> sending the same hash on every connect to that peer, whereever you are or
> connect from.

Not true. The hash includes the encryption session which is based on a 
ephemeral ECDH/HKDF per connection-session.

Have you read the BIP?





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] Unique node identifiers

[Jonas Schnelli via bitcoin-dev]

> Am 08.03.2017 um 22:09 schrieb Eric Voskuil :
> 
> On 03/08/2017 11:47 AM, Jonas Schnelli wrote:
 Nodes are by design not supposed to be identifiable in any way
>>> 
>>> This is of course my objection to BIP150 ("a way for peers to ...
>>> guarantee node ownership“).
>> 
>> Please Eric. Stop spreading FUD.
> 
> I'm always willing to debate this issue. I'm generally a little
> suspicious of one who demands another person to stop arguing. I got at
> least one such demand (along with a threat) on this subject privately
> last summer from a notable Core dev. There is a lengthy thread on this
> subject in which I raised these issues. Everyone is free to review that
> discussion.

What you did say in the sentence above (and I think is FUD) is, that BIP150 
will lead to every node being identifiable. This is just completely wrong.
There is nothing to say against a technical debate (and we had this), but I 
will ask you to stop if I see you attacking BIP150/151 at every occasion with 
FUDish arguments like this.





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] Unique node identifiers

[Jonas Schnelli via bitcoin-dev]

> 
>> 
>> > Nodes are by design not supposed to be identifiable in any way
> 
> This is of course my objection to BIP150 ("a way for peers to ... guarantee 
> node ownership“).

Please Eric. Stop spreading FUD.
BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed to not 
reveal any node identifier/identity without first get a crypto.-proof from 
other peer that he already knows your identity.
**Peers can’t be identified without having the identity-keys pre shared by the 
node operators.**



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] Currency/exchange rate information API

[Jonas Schnelli via bitcoin-dev]

I like the BIP. It can reduce workload during implementation on both sides of 
the API and it allows to show the user more data without implementing tons of 
proprietary APIs.
It’s not directly Bitcoin specific (example: BIP32 is also not Bitcoin 
specific), but I think a BIP is the right way for this.


> 
>> Apart from that, my feeling is that it could be simplified. Is
>> longpolling useful?
> 
> I would think so, at least for Bitcoin since rates can change significantly in
> a short period of time (or can they anymore? I haven't really watched lately.)

Long polling is a simple push concept that works on most type of network 
configurations (NAT, proxy, etc.).
The only concern I see here is that an public API will quickly fill up the 
maximum allowed httpd connections.
But it’s solvable.

> 
>> And is the historical rate thing really necessary for typical applications?
> 
> When displaying historical transactions, it doesn't really make sense to use
> the current market rate, but rather the market rate at the time the payment
> was made. While wallets might simply cache it with the transaction, it would
> be perhaps nicer if it could be automatically restored for seed-only
> recoveries. In any case, if a service/wallet doesn't want to provide/use
> historical information, it can simply not implement that part.

I’m also not sure how useful historical datapoint are. I don’t think the use 
case where someone wants to restore from a seed and get all exchange rates 
during the time of the payment is something users are looking for.
However, It’s optional.

> 
>> If yes, the client should be allowed to decide on which time scale the
>> data should be. (tick, min, hour, day, ...) That goes together with
>> clearly defining the type field (something like low, high, open, close,
>> but without flexibility). Think of a candle-stick chart basically.
> 
> How is the current draft insufficient for this?
> 
>> Also, pushing may be more appropriate for "current" rates than polling.
>> Then no polling interval is necessary. On the other hand, this adds
>> complexity in other places, e.g., state.
> 
> Pushing is what longpolling does.

Agree with Luke. A „real“ push (though I’d say long-polling is the real push, 
AFAIK it’s also the technique behind Apple’s iOS push channel) would require a 
complex server setup that complicates many things like load-balancer, 
mem-caching, etc.






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] BIP150/151 concerns and some comments

[Jonas Schnelli via bitcoin-dev]

>> - If you use one of the todays available SPV clients, you will reveal
>> your complete wallet content („~all your addresses") to every network
>> observer between you and the node you have connected to. This means, if
>> you pay for a coffee (while being on the owners WIFI), the coffee owner
>> and all the involved ISPs can correlate your wallet with your other
>> internet behavior. Same is true for your cellphone provider if you use
>> cellular.
> What about allowing trusted users connecting on a different connection. Much 
> like the RPC one.
> Make that one encrypted. Different usecase, different connection.
>
- What protocol would you use? The same p2p protocol but different port
and/or different process? Why?
- If not the p2p protocol, how would you form a standard? Would it be
worth doing a standard?
- Could you fall back to the current SPV model against random untrusted
peers if you additional channel is not available?
- What are the downsides using current p2p network?
- Would this also solve the security problem of creating designated
channels between peers (the "addnode" thing is based on IPs)?





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

Re: [bitcoin-dev] BIP151 protocol incompatibility

[Jonas Schnelli via bitcoin-dev]

>> This indeed is not ideal for compatibility checks, but increases security.
> The issue I raised is that it is not backward compatible. It sounds like
> you agree but consider it a fair trade. My suggesting was that the BIP
> be updated to reflect the lack of compatibility.
It's still backward compatible. All (?) SPV clients and full node
implementation would still work if BIP151 has been implemented.
Isn't that backward compatibility?
>> I could not find a protocol specification that said communication must
>> be terminated when messages are transmitted before the version handshake
>> has been done.
> It doesn't need to be specified, most of Bitcoin is unspecified. The
> version handshake establishes the negotiated version. It is not possible
> to determine if a message is of the negotiated version before the
> version is negotiated. All messages apart from this one have followed
> that rule.
Yes. But encryption negotiation must be done before the version
handshake (security).
>
>> Also. BIP151 clearly says that the requesting peer needs to initiate the
>> encryption (encinit).
> An incoming connection will be dropped due to invalid protocol and
> potentially banned depending on the implementation.
This is not true. If the connecting peer (assume the SPV client) will
not request encryption, the responding peer (the node) will not enforce
or ask for encryption.
This is clearly written in the BIP.
>> It could very likely be possible that the initial responding peer tries
>> to initiate a encryption session which would mean that BIP151 was not
>> implemented correctly.
>> Correct me if I'm wrong please.
> I did consider the possibility, but there's this:
>
> "Encryption initialization must happen before sending any other messages
> to the responding peer (encinit message after a version message must be
> ignored)."
>
> https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#specification
>
> The BIP does not define "responding" and "requesting" peers, but:
>
> "A peer that supports encryption must accept encryption requests from
> all peers... The responding peer accepts the encryption request by
> sending a encack message."
>
> This implies the requesting peer is the peer that sends the message. You
> seem to be saying that the requesting peer is the one that initiated
> the connection and the responding peer is the connection receiver. If
> this is the case it should be more clearly documented. But in the
> case I experienced the "requester" of an encrypted session was also
> the "receiver" of the connection.
I think the BIP makes this very clear. IMO you are trying to hide your
standpoint behind a wired interpretations of the BIP.

From the BIP:
«To request encrypted communication, the requesting peer generates an EC
ephemeral-session-keypair and sends an encinit message to the responding
peer and waits for a encack message. The responding node must do the
same encinit/encack interaction for the opposite communication direction.»

This seems to be pretty clear to me. You can interpret the "requesting
peer" and "responding peer" per message interaction. But then the whole
BIP would make no sense.

I'm happy if you can do a PR on the BIP that makes the wording better.
This would actually be a productive step.
>
 Or do I make a mistake somewhere?
>>> Yes, the ordering of the messages. New messages can only be added after
>>> the handshake negotiates the higher version. Otherwise the handshake is
>>> both irrelevant (as Pieter is implying) and broken (for all existing
>>> protocol versions).
>> I could not find evidence of the protocol specification that would
>> forbid (=terminate connection) such messages and I think allowing
>> unknown-messages before the version handshake makes the protocol flexible.
> Flexible is certainly one word for it. Another way to describe it is
> dirty. Allowing invalid messages in a protocol encourages protocol
> incompatibility. You end up with various implementations and eventually
> have no way of knowing how they are impacted by changes. There could be
> a range of peers inter-operating with the full network while running
> their own sub-protocols. Given the network is public and strong
> identification of peers is undesirable, the invalid messages would
> reasonably just get sent to everyone. So over time, what is the
> protocol? Due to certain "flexibility" it is already a hassle to
> properly implement.
Then you would have to go after all BIPs deployed this way. This
argument has nothing to do with BIP151 it questions the whole new
protocol features deployment.
Again, check this code part:

https://github.com/bitcoin/bitcoin/blob/a06ede9a138d0fb86b0de17c42b936d9fe6e2158/src/net_processing.cpp#L2595


>
>> Are there any reasons we should drop peers if they send us unknown, but
>> correctly formatted p2p packages (magic, checksum, etc.) before the
>> version handshake, ... but not drop them if we have received unknown
>> messages after the version handshake?
>

[bitcoin-dev] BIP150/151 concerns and some comments

[Jonas Schnelli via bitcoin-dev]

Hi

Recently I read some concerns about BIP150/151 and its „identity system“.
I think we should take those concerns seriously and I wrote some
comments for some of the concerns I'm aware of. In my opinion, most of
these worries are unfounded.


Concern 1: BIP150 introduces a identity system that could partition the
network

###

- Users already filtering/authenticate peers by IP tables, „addnode“
command, peer banning in app-layer. Fast block relay is a good example
(example: FIBRE).
- BIP150 allows to switch from IP based authentication (which is
obviously not ideal) to a secure form of authentication with pre-shared
keys (ECDH).
- We can’t stop peer operators to selectively manage peers and there are
valid reasons to do that

Concern 2: But BIP150 makes it simpler and increase the risk of network
partitioning



- What is simpler, presharing a pubkey over a secure channel (PGP /
Signal) and store in on both peers or calling a „addnode “, or
„iptables-DROP “?

Concern 3: Identity is not something we want in Bitcoin

###

- BIP150 introduces an **optional** authentication over a EC pubkey. The
EC pubkey can be changed. It’s different per network interface. You only
reveal it to peers that already have proven the know your identity.
- IP addresses are also a form of identity and way more inflexible and
different to hide.


Concern 4: But peers can fingerprint my node and ban me after BIP150 has
been deployed

##

- They can’t fingerprint you over BIP150 messages, it does not reveal
your identity unless the responding peer has proven he knows your identity.


Concern 5: BIP150/151 is not necessary, we have already Tor and STunnel,
etc.

#

- Tor is an alternative, right. But do we want to depend on those
technologies? Using tor for a single secure channel seems like using
a sledgehammer to crack a nut.

- How many SPV users have encrypted channels to trusted nodes today? Is
it accessible for the novice user? 

- Peer operators who depend on designated connections (with addnode),
what security do they have today (IP address, really?)?

- I think tor is great, it can be an alternative or an additional
security enhancement (encrypt twice). IMO the focus of Tor is not on
securing single channels (it's rather onion routing / anonymity).

 

Concern 6: BIP151 gives a false sense of security and has no MITM detection

###

- BIP151 (pure encryption) has no MITM detection, correct.

- Without BIP151 encryption, everyone can hook into the stream and read
what’s going on. With BIP151, an attacker needs to actively substitute
ephemeral keys in both direction. This attack is A) more complex to
achieve and B) it’s an active attack (no excuse of „I just made some
statistics“), C) it requires the attacker to accept the risk of being
detected.

- C) is true because an optional authentication (can be BIP150 or
different) would reveal the attack.

- Some attacks are worthless if you have to take the risk mentioned in C)

 

Concern 7: But Bitcoin traffic is trustless, why the hell you want to
encrypt it?

#

- If you use one of the todays available SPV clients, you will reveal
your complete wallet content („~all your addresses") to every network
observer between you and the node you have connected to. This means, if
you pay for a coffee (while being on the owners WIFI), the coffee owner
and all the involved ISPs can correlate your wallet with your other
internet behavior. Same is true for your cellphone provider if you use
cellular.

- They still can, if you don’t have a trusted node, by performing the
attack that involves the risk mentioned in Concern 6.

 

Concern 8: If you want to have a light client, you should use a
different channel to communicate with your full node then the p2p layer

###

- From a design perspective, this could make sense

- From an end user’s perspective, this is undesirable (enabled different
port, lack of a (RPC / ZMQ, etc.) standard, no fallback option if the
trusted node is down, hard to setup)

- Using the p2p channel as the todays SPV do, seems very reasonable to
me. Keep the users on the p2p layer! If we don’t want the users on that
channel, we automatically form a different layer, the wallet-com wild-west.

- Keeping the users on the p2p layer also allows future changes where
they can help the network in some ways.

- Using the p2p layer for a tr

Re: [bitcoin-dev] BIP151 protocol incompatibility

[Jonas Schnelli via bitcoin-dev]

>> Look at feefilter BIP 133
>> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
>> or sendheaders BIP130
>> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
>> Isn't it the same there?
> No. This is what I was referring to. These messages are enabled by
> protocol version. If they are received by a node below the version at
> which they are activated, they are unknown messages, implying an invalid
> peer. The above messages cannot be sent until *after* the version is
> negotiated. BIP151 violates this rule by allowing the new control
> message to be sent *before* the version handshake.
This indeed is not ideal for compatibility checks, but increases security.
I could not find a protocol specification that said communication must
be terminated when messages are transmitted before the version handshake
has been done. I mostly looked into Bitcoin-Cores implementation (which
means also into BitcoinXT/UT, where this is allowed).

Also. BIP151 clearly says that the requesting peer needs to initiate the
encryption (encinit).
In case of light clients not supporting BIP151 connecting to peers
supporting BIP151, there should never be transmission of new message
types specified in BIP151.
>
>> Once BIP151 is implemented, it would make sense to bump the protocol
>> version, but this needs to be done once this has been
>> implemented/deployed.
> There are already nodes out there breaking connections based on the BIP.
It could very likely be possible that the initial responding peer tries
to initiate a encryption session which would mean that BIP151 was not
implemented correctly.
Correct me if I'm wrong please.
>
>> Or do I make a mistake somewhere?
> Yes, the ordering of the messages. New messages can only be added after
> the handshake negotiates the higher version. Otherwise the handshake is
> both irrelevant (as Pieter is implying) and broken (for all existing
> protocol versions).
I could not find evidence of the protocol specification that would
forbid (=terminate connection) such messages and I think allowing
unknown-messages before the version handshake makes the protocol flexible.

Are there any reasons we should drop peers if they send us unknown, but
correctly formatted p2p packages (magic, checksum, etc.) before the
version handshake, ... but not drop them if we have received unknown
messages after the version handshake?

I can't see that a such spec. would reduce the DOS attack vector?

>
>>> As for DOS, waste of bandwidth is not something to be ignored. If a peer
>>> is flooding a node with addr message the node can manage it because it
>>> understands the semantics of addr messages. If a node is required to
>>> allow any message that it cannot understand it has no recourse. It
>>> cannot determine whether it is under attack or if the behavior is
>>> correct and for proper continued operation must be ignored.
>> How do you threat any other not known message types?
> You may be more familiar with non-validating peers. If a message type is
> not known it is an invalid message and the peer is immediately dropped.
> We started seeing early drops in handshakes with bcoin nodes because of
> this issue.
If this had happened, it's very likely because the responding peer tried
to initiate a encryption session which is against BIP151 specs.
>
>> Any peer can send you any type of message anytime.
> Sure, a peer can do what it wants. It can send photos. But I'm not sure
> what makes you think it would be correct to maintain the connection when
> an *invalid* message is received.
Check:
https://github.com/bitcoin/bitcoin/blob/a06ede9a138d0fb86b0de17c42b936d9fe6e2158/src/net_processing.cpp#L2595
I think it was a wise implementation decision to allow unknown (not
invalid) messages.
This had allowed us to deploy stuff like compact blocks, feefilter, etc.
without breaking backward compatibility.
IMO, without a such flexibility, the deployment complexity would be
irresponsible high without really solving the DOS problem.
>
>> Why would your implementation how you threat unknown messages be
> different for messages specified in BIP151?
>
> Because it properly validates the protocol.
For feefilter or compact block or sendheaders?
You can't link a (unimplemented) specification (improvement process) to
a protocol version before deployment. Or can you?
Once it has been widely deployed, we should set a protocol minversion
for BIP151, right.





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

Re: [bitcoin-dev] BIP151 protocol incompatibility

[Jonas Schnelli via bitcoin-dev]

> All adopted BIPs to date have followed this
> pattern. This is not the same and it is not helpful to imply that it is
> just following that pattern.

Look at feefilter BIP 133
(https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
or sendheaders BIP130
(https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
Isn't it the same there?
Once BIP151 is implemented, it would make sense to bump the protocol
version, but this needs to be done once this has been
implemented/deployed. Or do I make a mistake somewhere?
>
> As for DOS, waste of bandwidth is not something to be ignored. If a peer
> is flooding a node with addr message the node can manage it because it
> understands the semantics of addr messages. If a node is required to
> allow any message that it cannot understand it has no recourse. It
> cannot determine whether it is under attack or if the behavior is
> correct and for proper continued operation must be ignored.
How do you threat any other not known message types? Any peer can send
you any type of message anytime. Why would your implementation how you
threat unknown messages be different for messages specified in BIP151?





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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Jonas Schnelli via bitcoin-dev]

Hi Tom

Please don't post release announcements for software that is
incompatible with the current bitcoin consensus rules here.
Otherwise we give green-lights to any sorts of altcoin to post their
releases here.

Thanks


> Bitcoin Classic version 1.2.0 is now available from;
>
>  
>
> This is a new major version release, including new features, various 
> bugfixes and performance improvements.
>
> This release marks a change in strategy for Bitcoin Classic, moving from the 
> very conservative block size proposal based on compromise to one where 
> Classic truly innovates and provides a long term solution for the market to 
> choose and leave behind the restrictions of the old.
>
> The most visible change in this version is the decentralised block size 
> solution where node operators decide on the maximum size.
>
> Bitcoin Classic is focused on providing users a way to get onto the Bitcoin 
> network using a high quality validating node for a large set of use cases. 
> Classic presents top notch quality processes in this release, to help anyone 
> running Bitcoin.
>
> We include in this release various projects with the beta label. People who 
> want to use the Classic node as an on-ramp to Bitcoin will find them 
> interesting. These projects will need to be enabled in the config by those 
> that want to test them.
>
> More background information on this release and Classic can be seen in this 
> video: https://vimeo.com/192789752
> The full release notes are on github at 
> https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
>




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

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Jonas Schnelli via bitcoin-dev]

Hi

> Unconfirmed transactions are incredibly important for real world use.
> Merchants for instance are willing to accept credit card payments of
> thousands of dollars and ship the goods despite the fact that the
> transaction can be reversed up to 60 days later. There is a very large
> cost to losing the ability to have instant transactions in many or
> even most situations. This cost is typically well above the fraud risk. 
>
> It's important to recognize that bitcoin serves a wide variety of use
> cases with different profiles for time sensitivity and fraud risk.
>
I agree that unconfirmed transactions are incredibly important, but not
over SPV against random peers.

If you offer users/merchants a feature (SPV 0-conf against random
peers), that is fundamentally insecure, it will – sooner or later – lead
to some large scale fiasco, hurting Bitcoins reputation and trust from
merchants.

Merchants using and trusting 0-conf SPV transactions (retrieved from
random peers) is something we should **really eliminate** through
education and by offering different solution.

There are plenty, more sane options. If you can't run your own full-node
as a merchant (trivial), maybe co-use a wallet-service with centralized
verification (maybe use two of them), I guess Copay would be one of
those wallets (as an example). Use them in watch-only mode.

For end-users SPV software, I think it would be recommended to...
... disable unconfirmed transactions during SPV against random peers
... enable unconfirmed transactions when using SPV against a trusted
peer with preshared keys after BIP150
... if unconfirmed transactions are disabled, show how it can be enabled
(how to run a full-node [in a box, etc.])
... educate, inform users that a transaction with no confirmation can be
"stopped" or "redirected" any time, also inform about the risks during
low-conf phase (1-5).

I though see the point that it's nice to make use of the "incoming
funds..." feature in SPV wallets. But – for the sake of stability and
(risk-)scaling – we may want to recommend to scarify this feature and –
in the same turn – to use privacy-preserving BFD's.






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

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Jonas Schnelli via bitcoin-dev]

Hi
> We introduce several concepts that rework the lightweight Bitcoin
> client model in a manner which is secure, efficient and privacy
> compatible.
>
> The BFD can be used verbatim in replacement of BIP37, where the filter
> can be cached between clients without needing to be recomputed. It can
> also be used by normal pruned nodes to do re-scans locally of their
> wallet without needing to have the block data available to scan, or
> without reading the entire block chain from disk.
I started exploring the potential of BFD after this specification.

What would be the preferred/recommended way to handle 0-conf/mempool
filtering – if & once BDF would have been deployed (any type,
semi-trusted oracles or protocol-level/softfork)?

From the user-experience perspective, this is probably pretty important
(otherwise the experience will be that incoming funds can take serval
minutes to hours until they appear).
Using BIP37 bloom filters just for mempool filtering would obviously
result in the same unwanted privacy-setup.





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

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

[Jonas Schnelli via bitcoin-dev]

Hi Tom

> I think you misunderstand tagged systems at a very basic level.  You think 
> that html can only use a bold tag  once in a document? Thats equivalent 
> to what you are saying.

Would the "additional" segment contain the same amount of
nSequence-equivalent token as the number of inputs in the "inputs" segment?
What if you only want to add a per-input-token in the additional segment
for a certain input (assume last input)?
I guess the fundamental difference to html is the possible nesting.

However, I think that should be mentioned/specified in the BIP.





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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

> The development paradigm of "maybe detect funds" is not something we
> should *not* encourage for Bitcoin IMO.

Sorry. That was one "not" to many.





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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

> Le 25/08/2016 à 09:39, Jonas Schnelli via bitcoin-dev a écrit :
>> (I think this case if not completely unrealistic):
>>
>> What would happen, if a user gave out 21 addresses, then address0 had
>> receive funds in +180 days after generation where address21 had receive
>> funds immediately (all other addresses never received a tx).
>>
>> In a scan, address0 would be detected at +180 days
>> which would trigger the resize+20 of the address-lookup-window, but, we
>> would require to go back 180day in order to detect received transaction
>> of address21 (new lookup-window) in that case.
>>
>> Or do I misunderstand something?
>>
>>
> 
> That case is not unrealistic; a merchant might generate addresses that
> are beyond their gap limit, and orders get filled at a later date.
> 
> In that case you will not get the same result when restoring your wallet
> in a block-scanning wallet and in Electrum.
> 
> The lack of consideration for these cases is another issue with BIP44.

The development paradigm of "maybe detect funds" is not something we
should *not* encourage for Bitcoin IMO.

Users might sweep their existing bip32/bip44 seed (which could miss
funds according to the problem above) to a new wallet and discard the
previous seed.

But I agree with Luke-Jr.
This Thread is not about specification, it's about what's used and what
should be marked as standard.

New BIPs could cover "overhauled" proposals for BIP39 and BIP44.
Otherwise – very likely – nothing will happen.





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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

Sorry for hijacking the thread again

> As I understand it, you can scan sequentially starting with the genesis
> block (or with a block at around the time when BIP44 was written).  Then
> if you find a new transaction, which requires to generate new addresses,
> you generate them and scan further from that point on.  This way you can
> scan in a single pass if the scanning process calls you back when it
> finds a transaction and allows you to change the set of addresses on the
> fly.

(I think this case if not completely unrealistic):

What would happen, if a user gave out 21 addresses, then address0 had
receive funds in +180 days after generation where address21 had receive
funds immediately (all other addresses never received a tx).

In a scan, address0 would be detected at +180 days
which would trigger the resize+20 of the address-lookup-window, but, we
would require to go back 180day in order to detect received transaction
of address21 (new lookup-window) in that case.

Or do I misunderstand something?






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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

Hi

> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that a BIP39 compatible wallet will have to check addresses from all the
> derivation methods that ever existed in the past, in order to ensure
> that all coins are correctly retrieved? Or will there be users that
> cannot access their coins because their BIP39 seed phrase is too old for
> newer software?

I totally agree with Thomas.

Another thing that I think could be a BIP misdesign:

BIP44 Gap Limits
From the BIP:

--
  "Address gap limit is currently set to 20. If the software hits 20
unused addresses in a row, it expects there are no used addresses beyond
this point and stops searching the address chain."
--

* Does that mean, we do a transaction rescan back to the genesis block
for every 20 addresses?
* Or is it a prerequirement to do a wallet recovery after BIP44's to
have access to a full address-indexed blockchain?

Or maybe I'm missing something.





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

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

[Jonas Schnelli via bitcoin-dev]

>> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in 
>> Bitcoin
>> Core and derivatives; it is unclear if used by clients yet. Can developers of
>> such clients please comment and let me know: 1) if their software supports
>> this BIP already; 2) if not, do they intend to support it in the future?
>> If and only if there are any clients using this service bit already, I will
>> update BIP 111 to Final Status in 2 weeks also.
> 
> Multibit is adding detection of the NODE_BLOOM bit in the next 2-3 weeks.
> 
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet 
> connects only to nodes that don’t support bloom filtering, the wallet never 
> gets updates. We have had a spike in users reporting that their wallet isn't 
> getting updated. To compound the problem, they rescan the blockchain and lose 
> all of their transaction history. It has caused much panic among less 
> technical users.
> 
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although 
> it is non-deterministic, so we aren't certain.
> 
> I imagine that other SPV wallets are having similar issues. BIP 111 really 
> isn’t optional at this point, so it should be marked final.

SPV Wallets should definitively update to respect NODE_BLOOM. Bloom
filtering is CPU and disk intense and some node operators have disabled
it (or will disabled it) because there is no direct p2p network-health
benefit.

SPV wallets should probably also make use of the new DNS seeder filter
option.
It is running at least on seed.bitcoin.sipa.be and
seed.bitcoin.jonasschnelli.ch.

The filter option allows SPV Wallets to only get nodes that signal
support for NODE_BLOOM.

The syntax is

   x.seed.bitcoin

Example for NODE_NETWORK together with NODE_BLOOM
dig x5.seed.bitcoin.jonasschnelli.ch
(NETWORK = (1 << 0), NODE_BLOOM = (1 << 2)) = (bin0101 = (int)5)






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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

> I have some experience with hardware wallet development and its
> integration and I know it's a mess. But it is too early to define such
> rigid standards yet. Also, TREZOR concept (device as a server and the
> primary source of workflow management) goes directly against your
> proposal of wallet software as an workflow manager. So it is clear NACK
> for me.

The current question – as already mentioned – is we ACK to work together
on a signing protocol or if we NACK this before we even have started.

I'm not saying that the draft proposal I made is the way to go, I'm
happy to NACK it myself in favor of a better proposal.

I strongly recommend to work together on a standard that will have one
central winner: the end user.





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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

> The main benefit is that you don't need "standard" to solve problem, but
> use natural tools in given environment and programming stack. Build a
> "standard" on top of URI protocol is a huge limitation, which does not
> give any advantage.

Standards can help an ecosystem to grow, can help to sustain a good user
experience.

The hardware wallet vendors have used "natural tools" and look where we
are. We have *native* plugins in Electrum, Copay, etc. for different
hardware wallets. Mostly the plugins are in the code base of the wallet,
which makes it – in theory – impossible to change from the perspective
of the hardware wallet vendor (there is no control of the deployment if
there are bugs in the plugins code).
The plugins functions overlap significant.

I think this is a bad design for security critical applications.

What I want as hardware wallet user:
* I'd like to have a trusted application (layer) where I'm sure I'm
using software provided through my hardware wallet vendor.

What I want as hardware wallet vendor:
* I'd like to be able to provide and update a software layer (app) to my
customer with the ability to provide code signatures and security
updates anytime. I do want to control the user experience.


> We already see issues with dead simple "bitcoin uri" standard, it barely
> works in most of bitcoin apps. Think of vague definitions of parameters
> or ability to send payment requests over it. HW API would be complicated
> by an order of magnitude and I have serious concerns that it will be
> helpful for anything. So why complicate things.

As far as I know most bitcoin wallets do support the bitcoin:// URI
scheme quite well.
I agree that BIP70 is a mess (including the bitcoin:// additions).

The proposed URI scheme would be completely different. The only
similarity is using the URI scheme as transport layer (which is the
proposed long term inter-app communication layer by Apple and Google).

>> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
> 
> Interprocess communication/libraries/dependencies on Android are not
> bound to specific transport anyhow. Such library could be used by any
> android app, and the library would implement proper transports for
> various supported vendors. USB for Trezor, NFC for something different
> etc. If the point is "make life of app developers easier", let's do this
> and do not define artifical "standards".

So you propose having one library that would support multiple vendors?
What if new vendors add a new transport layer (lets assume NFC or
Bluetooth), wouldn't that result in every possible consumer of that
library (all wallets) need to update before the new vendors transport
layer could be used, resulting in a huge deployment process probably
require many month until it can be used?

What if there is a critical security issue in the library? How would the
deployment plan looks like?

I really think we should remove the "hardware communication layer" from
wallets and move it towards the hardware vendor app.

What about iOS? Should we just leave that platform unsupported with
hardware wallets?





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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

> I fundamentally disagree with the concept of driving signing workflow by
> the wallet software. Wallet software does not know in advance all data
> necessary for the signer to do the job. As Jochen mentioned above,
> Segwit vs Non-segwit use cases are a good example, but there may be many.

I think this is easily solvable. The required data to verify and sign a
(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.

IMO what a signing devices requires in order to sign a (standard)
transaction:
-> serialized tx
-> serialized tx of the inputs
-> scriptPubKey of the inputs
-> inputs redeem-Scripts
-> input amounts
-> position of the change output any maybe its keypath
-> cosigners pubkeys for inputs and changeaddress

This seems to be manageable for a 1 round communication?
Or do I miss something?


> Currently the TREZOR protocol works like device is a server and wallet
> is a client calling methods on it. It's like: "Sign this for me,
> please", "Ok, give me this information", "Here it is", "Now I need this
> another piece" "There is the signature". Wallet does not know in
> advance what will go next, and it is for sake of simplicity. I'm quite
> happy with the protocol so far.

I think multiple rounds would still be possible with a clever design.
Although I could imaging that >95% of the users transaction would
require only a single "shot".

Whats the benefits of the multiple rounds communication? Would a single
round result in to many data transported?

Passing a 300kb chunk (assuming a large transaction) over a URI scheme
requires a couple of milliseconds on standard Smartphones or PCs.

> Considering the difference in between current hardware, I really don't
> think it is possible to find any minimal URI-based API good enough for
> communicating with all vendors. What I see more likely is some 3rd party
> libraries (JS, C++, Python, ...) defining high-level API and
> implementing hardware-specific protocols and transports as plugins. That
> way vendors are not limited by strict standard and application
> developers and services can integrate wide range of hardware wallets
> easily. However, this can be done already and we do not need any
> standardization process (yet).

The URI-based API allows transmitting data of multiple megabytes while
there is no need for...
* dependencies of any form (library, etc.)
* library support for a particular language
* platform that supports the dependencies of the library (like USBHID,
not supported by iOS)

Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?

How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?

Thanks
--




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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi Dana

>> The URI scheme does not require any sorts of wallet app level
>> configuration (where the stdio/pipe approach would require to configure
>> some details about the used hardware wallet).
> 
> Hi everybody, just thought I’d throw my opinion in here.
> 
> The URI scheme is a nice idea, but this ignores the fact that hardware wallet 
> vendors do most of the work on talking between the computer/mobile and the 
> wallet on a lower level of communication. In the case of BitLox, the base 
> protocol is Google’s ProtoBuf. The commands and transaction data is in a 
> “schema” which is then encoded in different methods accessible via ProtoBuf 
> (depending on the data being sent). The advantages of this protocol is that 
> it can be implemented on a wide variety of platforms. (but that’s a whole 
> 'nother discussion)
> 
> The URI would be handled way up in the specific application (such as the 
> mytrezor wallet software or the various standalone wallets) - nowhere near 
> the actual hardware communications layer.

This is maybe a question of the scope.
The BIP I'm proposing would make a clear interface cut between
wallet-with-unsigned-transaction and a signing-device (and maybe between
wallet-requires-pubkey, signing-device generate some pubkeys [or
non-hardened xpub]).

The detached-signing proposal does not duplicate work. It just moves the
current plugin design into a separate application. Plugins in security
and privacy critical wallet software is something that should probably
be avoided.

It's intentional at a high level to allow maximum flexibility at the
hardware interaction layer.

Your protobuf example is a good use-case. You could implement your
custom processes behind the URI scheme (which is probably way more
efficient then writing a couple of wallet plugins where you – at the end
– mostly don't control the deployment and the source-code).

Defining a standard on the hardware interaction layer is possible, but a
fairly different approach.





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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi all

Thanks for the response.


Jochen's points:
===
Indeed. There are some missing points and I'd like to work this into the
BIP. Thanks for bringing this up.

Along with a support for wallet-creation with a xpub from the signing
device, we might also want to support loading multiple pubkeys into a
keypool from the device (in case someone likes to use hardened
derivation at all levels). I guess this would not be over-complex to
achieve.

Luke's points:
=

USB / Plugin/Driver problematic
---
I don't think it would be wise to set Trezors USB communication
(hardware interface) as "the standard". A) A USB stack/interaction in
wallets should be avoided IMO. B) This approach won't work for some
platforms (like iOS) due to technical and legal restrictions.

In my opinion, each hardware wallet has to provide custom software in
any case. We don't want to standardize how a hardware wallet has to do
backups, recovers, firmware upgrade, etc. and if we agree on that, then
hardware wallets must provide an application (mostly Chrome extensions
today) to implement theses processes.

Also diversity at the hardware interface will reduce centralized risks
for weak security/vulnerabilities.

The proposed URI scheme approach does not require any sorts of
libraries/dependencies. USB HID can be a problem for cross platform
desktop wallets as well as it won't work of one of the major mobile
platform (iOS). USB HID interaction can be restricted or disabled in non
superuser setups where I'm not aware of any restriction on URI-Scheme level.

URI scheme instead of stdio/pipe

The URI scheme is not ugly. Its a modern way – implemented in almost all
platforms – how applications can interact with each other while not
directly knowing each other. Registering a URI scheme like "bitcoin://"
has some concrete advantages over just piping through stdio.

Also, the stdio/piping approach does not work for mobile platforms
(where the URI scheme works).

The URI scheme does not require any sorts of wallet app level
configuration (where the stdio/pipe approach would require to configure
some details about the used hardware wallet).


Thomase D.'s points:
===
Standardizing to many layers of the interaction stack (including the
hardware interaction) will very likely result in vendors not sticking to
the standard.

I agree, the URI scheme has some fragility, but at a level where we can
handle it and with the advantage of abstracting the used brand/device
for privacy and security reasons.

> The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets.

Most operating systems allow to check if a certain URL-Scheme is
supported (registered), this would allow at least to check for known
major vendors (like trezor, etc.) which should solve most
multi-hardware-wallet use-cases.

The URI return scheme does work fine and with the correct set timeouts
it should result in a neat user experience.
It's the proposed way of application intercommunication in Apple iOS [1]
and Google Android [2].

Conclusion:
===
* Non of the points convinced me that there is a better alternative to
the proposed URI scheme interaction (please tell me if I'm stubborn).
* Also, we should move the end users UX in the center of the
problems-to-solve (and not overweight the ideal
code-/API-/hardware-interaction-design while ignoring the end user
experience).
* We should try to not over-standardize the interaction with the device
itself to allow flexibility on the hardware wallet vendor side.

[1]
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
[2] https://developer.android.com/training/basics/intents/sending.html





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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

> I think it does not make sense to try to get this standardized for
> current Bitcoin transactions. They are just too complex.
> 
> What might be interesting is to have something similar for Segwit and
> Lightning transactions.
> 
> * TREZOR performs extended validation of the inputs, when all of
> prev-txs are streamed into the device and validated. Your standard does
> not tackle this at all and I don't think it's worthy to make this
> standard unnecessarily complicated.

I'm aware of this approach but I don't think this makes sense long term.
We need a better way on the protocol level to validate inputs amounts
(where segwit is a first step towards this).

IMO, not having a standard for hardware wallet interfaces/communication
will long term result in reducing the end user experience.

I think we should collaborate together and work out a standard.

My goal is to add hardware wallet support in Bitcoin-Core where adding
proprietary code (plugin-ish) is something we don't want to do for the
sake of security and compatibility.

As said, the "BIP" is very draft and I'm happy to include the input
streaming as part of it (or you could add it if you want because you
have more experience with it).





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

[bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

Unfortunately, there is no standard in how desktop- or mobile-wallets
can interact with a hardware device resulting in wallet vendors adding
plugins with proprietary code for non-standardized interfaces.

I started a BIP (extreme draft, feel free to improve language, grammar
and content) to address this missing part of the ecosystem.

I think it would be extremely helpful if @ledger, @trezor,
@voisin/@breadwallet, @electrum, @bitpay (and more?!) would help working
on a such standard.

The BIP describes two approaches how to communicate (pipe and
URI-scheme) with the signing-devices app, although, in my opinion, all
major platform do support the URI approach (maybe we could drop the pipe
approach then).
The URI approach means that there is no need to configure the
application location in order to start a inter-process(-app) communication.

Mediawiki:
https://github.com/jonasschnelli/bips/blob/8abb51f0b21b6664388f6e88f6fd642c90d25dca/bip-undef-0.mediawiki




 BIP (rough early stage draft)


  BIP: ???
  Title: Detached Signing
  Author: Jonas Schnelli 
  Status: Draft (early stage!)
  Type: Standards Track
  Created: 2016-08-02


== Abstract ==

This BIP describes a way how wallet applications can decouple sensitive
privatekeys from the internal keychain and interact with a
signing-devices (hardware wallet, "cold" storage) over a generic
interface in order to get signatures.

== Motivation ==

It seems like that the current approach for allowing signing-devices to
interact with third party wallets is to build a plugin [1][2][3]. Adding
plugins for each hardware wallet type will increase possible security
issues and result in multiple proprietary-third-party code within the
wallet application with very similar structures.

A generic interface how wallets can interact with signing-devices would
result in better user experience, less critical code and simpler
adaption for various signing-devices.

== Specification ==

In order to support desktop- and smartphone-wallet-applications, this
BIP describes two slightly different approaches (process pipe and URI
call) in how to interact with the signing-devices. If possible, the
modern URI approach should be chosen.

=== Signing-Device-Controller-Application ===

To allow a generic interface while still allowing different ways how to
internally communicate with the signing device itself (USB, TCP/IP,
air-gapped Qr-Code scanning, etc.) a controller-application is required.

=== General signing process ===

The wallets signing process must be according the following principal:
* Wallet prepares signing-request-object including bitcoin-transaction
or message together with metadata (scriptPubKey, hd-keypath of the inputs)
* Wallet passes signing-request-object to the
signing-device-controller-application
* Signing-device-controller-application processes
signing-request-object, eventually shows UI, user can sign or cancel
* Signing-device-controller-application sends back
signing-response-object with signatures or an error
* Wallet processes signing-response-object and completes data-object
creating process (example: add signatures to transaction and broadcast)

=== Desktop Process Intercommunication ===

Desktop wallets can interact with a signing device over process
intercommunication (pipe) together with a
signing-device-controller-application.
As specified below, the signing-request-object is a URI string passed
through the pipe. The desktop wallet needs to wait (with a recommended
timeout between 1 and 5 minutes) until the signing-response-object will
be sent back by the signing-device-controller-application.

=== Smartphone/URI App Intercommunication ===

Smartphones and modern operating systems are trying to sandbox
applications and interprocess communication (on pipe level) is mostly
disallowed.
On smartphones, we must use URI-schemes.
The wallet can pass information to the
signing-device-controller-application by using a predefined URI scheme.

detatchedsigning://?&returnurischeme=

The querystring must be URI encoded.
RFC 2616 does not specify a maximum length of URIs (get request). Most
modern smartphone operating system allow URIs up to serval megabytes.
Signing complex data-structure is therefore possible.

The returnurischeme must contain a URI schema where the
result of the signing process should be returned to.
The returnurischeme must be populated and "opened" once the signing
process has been completed (or cancled).

=== Signing Request ===

The signing request is a flexible URI-Query-String that will be used by
the Signing-device-controller-application for user confirmation as well
as for creating the signature.

The URI-query-string must conform to the following format:

detatchedsigning://sign?type=&data=&inputscripts=,,...&inputhdkeypath=,,...&returnscheme=

type = type of the data to sign
data = raw unsigned bitcoin transaction or text-message
(optional)inputscripts = scriptPubKey(s) of the inputs in exact order
(optional)inputhdkeypath = hd

Re: [bitcoin-dev] Authentication BIP

[Jonas Schnelli via bitcoin-dev]

> Yes. I think this limitation could be removed.
> A responding node can have – in theory – multiple identity-keys per
> network interface (network interfaces is also confusing, because you
> could run multiple bitcoind instances on the same interface with
> different ports).
> 
> The BIP should just make clear, that it is probably wise, to use
> different identity-keys for each network interface (ipv4, v6, tor).
> 

I have updated that part of the BIP

---
Each peer can configure multiple identity-keys (ECC, 32 bytes). Peers
should make sure, each network interface (IPv4, IPv6, tor) has its own
identity-key (otherwise it would be possible to link a tor address to a
IPvX address).
The identity-public-key(s) can be shared over a different channel with
other node-operators (or non-validating clients) to grant authorized access.
---

https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/auth_bip?expand=1





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

Re: [bitcoin-dev] Authentication BIP

[Jonas Schnelli via bitcoin-dev]

Hi Andy

>>
>>> Does openssh have this same problem?
>> No. OpenSSH doesn't make an effort to protect the privacy of its users.
>>
>>> I'm assuming this could be parallelized very easily, so it is not a huge
>>> problem?
>> It's not a issue because we're not aware of any usecase where a node
>> would have a large list of authenticated peers.
>>
>>> Each peer can configure one identity-key (ECC, 32 bytes) per listening
>> network interface (IPv4, IPv6, tor).
>>
>> I'm not aware of any reason for this limitation to exist. A node
>> should be able to have as many listening identities as it wants, with
>> a similar cost to having a large authorized keys list.
>>
> 
> So you are saying that you agree with me that the original text needs to
> be revised slightly or I am just misinterpreting the original text?

Yes. I think this limitation could be removed.
A responding node can have – in theory – multiple identity-keys per
network interface (network interfaces is also confusing, because you
could run multiple bitcoind instances on the same interface with
different ports).

The BIP should just make clear, that it is probably wise, to use
different identity-keys for each network interface (ipv4, v6, tor).

I'll try to overhaul that part.





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

[bitcoin-dev] Authentication BIP

[Jonas Schnelli via bitcoin-dev]

Hi

As already mentioned in the recent BIP151 thread
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html),
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.

The proposed authentication BIP does require BIP151.

The propose BIP does assume, node operators want to build trusted
connections for various reasons.

BIPs mediawiki github page available here:
https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/auth_bip?expand=1

===

  BIP: ???
  Title: Peer Authentication
  Author: Jonas Schnelli 
  Status: Draft
  Type: Standards Track
  Created: 2016-03-23

== Abstract ==

This BIP describes a way how peers can authenticate – without opening
fingerprinting possibilities – to other peers to guarantee ownership
and/or allowing to access additional or limited services.

== Motivation ==

We assume peer operators want to limit the access of different services
or increase datastream priorities to a selective subset of peers. Also
we assume peers want to connect to specific peers to broadcast or filter
transactions (or similar action that reveals sensitive informations) and
therefore they want to authenticate the remote peer and make sure that
they have not connected to a MITM.

Benefits with peer authentication:
* Peers could detect MITM attacks when connecting to known peers
* Peers could allow resource hungry transaction filtering only to
specific peers
* Peers could allow access to sensitive information that can lead to
node fingerprinting (fee estimation)
* Peers could allow custom message types (private extensions) to
authenticated peers

A simple authentication scheme based on elliptic cryptography will allow
peers to identify each other and selective allow access to restricted
services or reject the connection if the identity could not be verified.

== Specification ==

The authentication scheme proposed in this BIP uses ECDSA, ___secrets
will never be transmitted___.

___Authentication initialization must only happen if encrypted channels
have been established (according to BIP-151 [1]).___

The ___encryption-session-ID___ is available once channels are encrypted
(according to BIP-151 [1]).

The identity-public-keys used for the authentication must be pre-shared
over a different channel (Mail/PGP, physical paper exchange, etc.). This
BIP does not cover a "trust on first use" (TOFU) concept.

The authentication state must be kept until the encryption/connection
terminates.

Only one authentication process is allowed per connection.
Re-authenticate require re-establishing the connection.

=== Known-peers and authorized-peers database ===
Each peer that supports p2p authentication must provide two users
editable "databases"

# ___known-peers___ contains known identity-public-keys together with a
network identifier (IP & port), similar to the "known-host" file
supported by openssh.
# ___authorized-peers___ contains authorized identity-public-keys

=== Local identity key management ===
Each peer can configure one identity-key (ECC, 32 bytes) per listening
network interface (IPv4, IPv6, tor).
The according identity-public-key can be shared over a different channel
with other node-operators (or non-validating clients) to grant
authorized access.

=== Authentication procedure ===
Authentication after this BIP will require both sides to authenticate.
Signatures/public-keys will only be revealed if the remote peer could
prove that they already know the remote identity-public-key.

# -> Requesting peer sends `AUTHCHALLENGE` (hash)
# <- Responding peer sends `AUTHREPLY` (signature)
# -> Requesting peer sends `AUTHPROPOSE` (hash)
# <- Responding peer sends `AUTHCHALLENGE` (hash)
# -> Requesting peer sends `AUTHREPLY` (signature)

For privacy reasons, dropping the connection or aborting during the
authentication process must not be possible.

=== `AUTHCHALLENGE` message ===
A peer can send an authentication challenge to see if the responding
peer can produce a valid signature with the expected responding peers
identity-public-key by sending an `AUTHCHALLENGE`-message to the remote
peer.

The responding peer needs to check if the hash matches the hash
calculated with his own local identity-public-key. Fingerprinting the
requesting peer is not possible.

32bytes challenge-hash `hash(encryption-session-ID || challenge_type ||
remote-peers-expected-identity-public-key)`

`challenge_type` is a single character. `i` if the
`AUTHCHALLENGE`-message is the first, requesting challenge or `r` if
it's the second, remote peers challenge message.

=== `AUTHREPLY` message ===
A peer must reply an `AUTHCHALLENGE`-message with an `AUTHREPLY`-message.


| 64bytes || signature || normalized comp.-signature || A signature of
the encryption-session-ID done with the identity-key


If the challenge-hash from the `AUTHCHALLENGE`-message did not match the
local authentication public

Re: [bitcoin-dev] BIP proposal: derived mnemonics

[Jonas Schnelli via bitcoin-dev]

> But what are the alternatives?  Put an expensive processor and a decent
> amount of memory in every hardware wallet to support scrypt?  Use a
> million iterations and just wait 10 minutes after entering you
> passphrase?  Or compute the secret key on your online computer instead?

What the Digital Bitbox team does, is, PBKDF2 the user entered
passphrase on the computer with >20'000 iterations, then PBKDF2 again
onchip with the 2048 rounds.
If somebody manages to steal your backup (in that case a file/SDCard or
printed PDF), it would at least required > 22'048 iterations to derive
the key from a passphrase which I consider "stronger" then just using
2048 iterations.

> Also, how many iterations are secure?  A million?  Then just add two
> random lower-case letters to the end of your passphrase and you have a
> better protection with 2048 iterations.

I guess you shouldn't delegate KDF security to the user. But sure, this
could help as well. This is part of the UI.

On the other hand, forcing the user to select a long/more-secure
passphrase will very likely lead to many funds get lost behind
encryption because of lost/forgotten passphrases.

> If you want to be able to use
> your passphrase with cheap hardware and be protected against a high-end
> computer with multiple GPUs that is almost a mllion times faster, then
> you have to choose a good passphrase.  Or just make sure nobody steals
> your seed; it is not a brainwallet that is only protected by the
> passphrase after all.

Agree.
But IMO this fact should not be an excuse to reduce/use low iterations
during KDF (especially SHA2 based KDFs).





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

Re: [bitcoin-dev] BIP proposal: derived mnemonics

[Jonas Schnelli via bitcoin-dev]

Hi


> ==Generating the master mnemonic==
> 
> The master mnemonic is first derived as a standard mnemonic as described
> in BIP39.



> ==From master mnemonic to derived mnemonics==
> 
> From the master mnemonic a new string is created:
> 
> string = MasterMnemonic + " " + Count + " " + Strength;
> 
> Here, MasterMnemonic are the space separated words of the master
> mnemonic. Count = 0, 1, 2 denotes the different derived mnemonics of a
> given strength and Strength = numWords / 3 * 32, where numWords is the
> number of words desired for the derived mnemonic and only integer
> arithmetic is used in the calculation (e.g. for numWords = 14, Strength
> = 128). Both Count and Strength are converted to strings.
> 
> This string is then hashed using sha512:
> 
> hash = sha512(string);

1)
My humble cryptographic understanding tells me that you should probably
use sha512_hmac where you add an passphrase and a salt.

2)
Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
personally consider "not enough" to protect a serious amount of funds.

Also the checksum based on the predetermined wordlist has some security
downsides over using a plain 32byte entropy (64hex chars) or a
base58check encoded extended private master key.

3)
Another idea:
What would speak against deriving a child key after bip32, lets say at
m/88'/0'/n' and use the derived 256bits to encode your mnemonic?
This would at least require your master mnemonic passphrase to derive a
valid "child mnemonic".

4)
I'm still not convinced if we should encourage users to "only store and
backup" the bip39 mnemonic.
Reconstructing funds from a seed can be difficult especially if you
don't have access to a trusted TX-indexed full node (~150GB of data
required).
Novice users might also underestimate the risk of losing metadata
coupled with their transactions when they only store the wallet seed.





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

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

[Jonas Schnelli via bitcoin-dev]

Hi Arthur
> 
> I strongly agree!
> In crypto we should always follow well-studied open standard rather
> than custom construction.

I totally agree.
BIP151 does not introduce new cipher types.
The BIP uses ECDH together with ChaCha20-Poly1305@openssh.
Both very well known and broad used crypo.

/jonas



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

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

[Jonas Schnelli via bitcoin-dev]

> I haven't been able to find the beginning of this thread, so apologies
> if I've misunderstood what this is for, but it _sounds_ like we're
> re-inventing HKDF.

> I'd recommend reading the paper about HKDF. It stands out among crypto
> papers for having a nice clear justification for each of its design
> decisions, so you can see why they did it (very slightly) differently
> than the various constructions proposed up-thread.

Thanks Zooko

I think HKDF instead of a single HMAC_SHA512 seams reasonable and
something we should consider.

I'll try to evaluate the implications of using HKDF over HMAC_SHA512 and
will update the BIP if there are no concerns about it.





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

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli via bitcoin-dev]

>>> The core problem posed by BIP151 is a MITM attack. The implied solution 
>>> (BIP151 + authentication) requires that a peer trusts that another is not 
>>> an attacker.
>>
>> BIP151 would increase the risks for MITM attackers.
>> What are the benefits for Mallory of he can't be sure Alice and Bob may
>> know that he is intercepting the channel?
> 
> It is not clear to me why you believe an attack on privacy by an anonymous 
> peer is detectable.

If Mallory has substituted the ephemeral keys in both directions, at the
point where Alice and Bob will do an authentication, they can be sure
Mallory is listening.

Simple dummy example:
1.) Encryption setup with ECDH with ephemeral keys after BIP151
2.) Mallory is MITMling the connection. He is substituting both
direction with its own keys
3.) Connection is successfully MITMled
4.) Alice tells Bob "prove me that you are Bob, please sign the
session-ID with your identity key"
5.) Bob signs the sessionID (ECDH secret) with his identity key which
will be unusable for Mallory who has a substituted sessionID in both
directions.
6.) Alice has successfully detected the Mallory

Disclaimer: 4) and 5) are _not_ authentication proposals :-)





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

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli via bitcoin-dev]

> Yes, this is exactly what I meant. The complexity of the proposed 
> construction is comparable to that of Bitcoin itself. This is not itself 
> prohibitive, but it is clearly worthy of consideration.
> 
> A question we should ask is whether decentralized anonymous credentials is 
> applicable to the authentication problem posed by BIP151. I propose that it 
> is not.
> 
> The core problem posed by BIP151 is a MITM attack. The implied solution 
> (BIP151 + authentication) requires that a peer trusts that another is not an 
> attacker. 

BIP151 would increase the risks for MITM attackers.
What are the benefits for Mallory of he can't be sure Alice and Bob may
know that he is intercepting the channel?

MITM is possible today, it would still be possible (though under higher
costs) with BIP151.

With BIP151 we would have the basic tool-set to effectively reduce the
risks of being MITMled.

IMO we should focus on the risks and benefits of BIP151 and not drag
this discussion into the realm of authentication. This can and should be
done once we have proposals for authentication (and I'm sure this will
be a heated debate).

The only valid risk I have on my list from you, Eric, is the false sense
of security.

My countermeasure for that would be...
- deploy BIP151 together with the simplest form of authentication
(know_hosts / authorized_keys file, no TOFU only editable "by hand")
- make it more clear (in the BIP151 MOTIVATION text) that it won't solve
the privacy/MITM problem without additional authentication.

Or could you elaborate again – without stepping into the realm of
authentication/MITM (which is not part of the BIP or possible already
today) – why BIP151 would make things worse?





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

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

[Jonas Schnelli via bitcoin-dev]

> On Wed, Jun 29, 2016 at 08:34:06PM +0200, Jonas Schnelli via bitcoin-dev 
> wrote:
>>> Based on previous crypto analysis result, the actual security of SHA512
>>> is not significantly higher than SHA256.
>>> maybe we should consider SHA3?
>>
>> As far as I know the security of the symmetric cipher key mainly depends
>> on the PRNG and the ECDH scheme.
>>
>> The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret.
>> HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to
>> directly derive 512bits which allows to have two 256bit keys with one
>> HMAC operation (same pattern is used in BIP for the key/chaincode
>> derivation).
> 
> What's the rational for doing that "directly" rather than with two SHA256
> operations? (specifcially SHA256(0 . thing), SHA256(1 + thing) for the two
> parts we need to derive)

SHA256 and SHA512 are both from the SHA-2 family.

I have specified SHA512 to (slightly) increase the brute-force security
of the ecdh shared secret when knowing K_1 and K_2.

And I assumed (haven't measured the required cpu cycles) that a single
SHA512_HMAC is less expensive then two SHA256_HMAC.





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

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

[Jonas Schnelli via bitcoin-dev]

Hi Ethan


>> It is important to include the cipher-type into the symmetric cipher key to 
>> avoid weak-cipher-attacks.
> 
> the cipher-type here refers to the ECDH negotiation parameters?

No. Not to the ECDH negotiation.
BIP151 specifies a flexible symmetric key cipher type negotiation,
although, BIP151 only specifies chacha20-poly1...@openssh.com.

Lets assume someone adds another symmetric cipher type after BIP151 has
been deployed which has less strong security properties then
chacha20-poly1305.

If we don't include the ciphersuite-type in the key derivation HMAC, an
attacker/MITM could in theory force both nodes to use the weaker
symmetric cipher type.





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

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

[Jonas Schnelli via bitcoin-dev]

> Based on previous crypto analysis result, the actual security of SHA512
> is not significantly higher than SHA256.
> maybe we should consider SHA3?

As far as I know the security of the symmetric cipher key mainly depends
on the PRNG and the ECDH scheme.

The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret.
HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to
directly derive 512bits which allows to have two 256bit keys with one
HMAC operation (same pattern is used in BIP for the key/chaincode
derivation).

Keccak would be an alternative but we probably don't want to introduce
another new hash type just for the encryption.





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

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli via bitcoin-dev]

>> In my opinion, the question should be "why would you _not_ encrypt".
> 
> 1) creation of a false sense of security

False sense of security is mostly a communication issue.
BIP151 does focus on encryption (not trust).

Are users aware of the fact that ISP/WiFi-Providers can track their
bitcoin spending (if they use SPV+BF) and link it with other internet
traffic or sell the data to anyone who is interested to do correlation?

Are node operators aware of the possibilities that ISPs/Data-Centers,
etc. can hold back peers, etc.?

If there is a false sense of security/anonymity, then we are already
deep into this territory.
BIP151 was designed as a puzzle-pice towards better security and better
censorship resistance. You shouldn't project all sorts of "false sense
of security" into BIP151. Is a stepping stone towards greater security.

> 2) as a tradeoff against anonymity

Can you point out the tradeoffs?
BIP151 does not introduce fingerprinting possibilities.

> 3) benefit does not justify cost

Can you elaborate the costs?
[Extremely simplified]: we need 300 lines of code from openssh
(ChaCha20-Poly1305@openssl) and some ECDH magic (already in
Bitcoin-Cores codebase) together with two or three (maybe payed)
cryptoanalysis once the implementation is done.


>> There are plenty of other options to solve this problem. stunnel,
>> Bernsteins CurveCP, VPN, etc. which are available since years.
>> But the reality has shown that most bitcoin traffic is still unencrypted.
> 
> The question arises from concern over the security of the network in the case 
> where encryption (and therefore authentication) is pervasive.
> 
> As you point out, anyone can set up a private network of nodes today. These 
> nodes must also connect to the permissionless network to maintain the chain. 
> These nodes constitute a trust zone within Bitcoin. This zone of exclusion 
> operates as a single logical node from the perspective of the Bitcoin 
> security model (one entity controls the validation rules for all nodes).
> 
> Widespread application of this model is potentially problematic. It is a 
> non-trivial problem to design a distributed system that requires 
> authentication but without identity and without central control. In fact this 
> may be more challenging than Bitcoin itself. Trust on first use (TOFU) does 
> not solve this problem.

Yes. There is no plan to adopt a TUFO scheme. Bip151 does not use TUFO
it does not cover "trust" (It just encrypt all traffic).

Imaging Bip151 together with a simple form of preshared EC key
authentication (nonce signing or similar). You could drastically
increase the security/censor-resistance-properties between nodes where
owners have preshared identity keys (with nodes I also mean SPV/wallet
nodes).

And I guess there are plenty of awesome identity management system ideas
tied or not tied to the Bitcoin blockchain out there.
This is also a reason to not cover trust/authentication/identity in BIP151.
It is  possible to have multiple authentication schemes.

> In my opinion this question has not received sufficient consideration to 
> warrant proceeding with a network encryption scheme (which concerns me as 
> well, but as I consider it premature I won't comment).

Yes. I think nobody have started implementing BIP151. It's a draft BIP
and I think it's still okay and great that we have this discussion.

BIP151 hopefully has started some brainwork in how encryption and
authentication could work in Bitcoin and I'm happy to deprecate BIP151
if we have found a better solution or if we come to a point where we
agree that BIP151 does make the network security worse.

>> Example: IIRC non of the available SPV wallets can "speak" on of the
>> possible encryption techniques. Encrypting traffic below the application
>> layer is extremely hard to set up for non-experienced users.
> 
> Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, 
> if the proposal creates an insecurity its ease of deployment is moot.

If we assume increasing amount of novice users starting with Bitcoin
every day, how should these users run wallets without increasing
centralization by using webwallets or client/central-server wallets?
(which is OT, but an interesting question)

>> On top of that, encryption allows us to drop the SHA256 checksum per p2p
>> message which should result in a better performance on the network layer
>> once BIP151 is deployed.
> 
> I would not consider this a performance enhancing proposal. Simply dropping 
> the checksum seems like a better option. But again, it is moot if it creates 
> an insecurity.
> 
>> I agree that BIP151 _must_ be deployed together with an authentication
>> scheme (I'm working on that) to protect again MITM during encryption
>> initialization.
> 
> At a minimum I would propose that you modify BIP151 to declare a dependency 
> on a future BIP, making BIP151 incomplete without it. I think we can agree 
> that it would be unadvisable to deploy (and therefore

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli via bitcoin-dev]

Hi Eric

Sorry for not directly addressing your points.
I try to be more precise in this follow up email:

> I understand the use, when coupled with a yet-to-be-devised identity system, 
> with Bloom filter features. Yet these features are client-server in nature. 
> Libbitcoin (for example) supports client-server features on an independent 
> port (and implements a variant of CurveCP for encryption and identity). My 
> concern arises with application of identity to the P2P protocol (excluding 
> Bloom filter features).

I think the bloom filter SPV usecase is not "pure client-server". SPV
clients could request from/broadcast to multiple "trusted nodes".
Trusted nodes could be nodes where the operators have shared
identities/keys in advance over a different channel.

Further private p2p extensions (lets say a p2p form of the estimatefee
command) are something which needs to be discussed first and not
something that is encouraged or outlined in BIP151.

> It seems to me that the desire to secure against the weaknesses of BF is 
> being casually generalized to the P2P network. That generalization may 
> actually weaken the security of the P2P protocol. One might consider the 
> proper resolution is to move the BF features to a client-server protocol.

I don't see reasons why BIP151 could weaken the security of the P2P
network. Can you point out some specific concerns?


> The BIP does not make a case for other scenarios, or contemplate the 
> significant problems associated with key distribution in any identity system. 
> Given that the BIP relies on identity, these considerations should be fully 
> vetted before heading down another blind alley.

BIP151 does not rely on identities. BIP151 does not use persisted keys
(only ephemeral keys). The authentication/identity system needs to be
described in a another BIP.
But correct, BIP151 without a form of authentication/identity management
is vulnerable to all sorts of MITM attacks and that's why I think BIP151
must be deployed together with an p2p authentication scheme.

Scope creeping and the risks of overspecifying is the main reason to
focus on the "pure encryption part" in BIP151.

Thanks
---




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

Re: [bitcoin-dev] BIP 151

[Jonas Schnelli via bitcoin-dev]

Hi Eric

> I haven't seen much discussion here on the rationale behind BIP 151. 
> Apologies if I missed it. I'm trying to understand why libbitcoin (or any 
> node) would want to support it.
> 
> I understand the use, when coupled with a yet-to-be-devised identity system, 
> with Bloom filter features. Yet these features are client-server in nature. 
> Libbitcoin (for example) supports client-server features on an independent 
> port (and implements a variant of CurveCP for encryption and identity). My 
> concern arises with application of identity to the P2P protocol (excluding 
> Bloom filter features).
> 
> It seems to me that the desire to secure against the weaknesses of BF is 
> being casually generalized to the P2P network. That generalization may 
> actually weaken the security of the P2P protocol. One might consider the 
> proper resolution is to move the BF features to a client-server protocol.
> 
> The BIP does not make a case for other scenarios, or contemplate the 
> significant problems associated with key distribution in any identity system. 
> Given that the BIP relies on identity, these considerations should be fully 
> vetted before heading down another blind alley.


In my opinion, the question should be "why would you _not_ encrypt".


1) Transaction censorship
ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
transactions. Regardless if you are a miner or a validation/wallet node.

2) Peer censorship
MITM can remove or add entries from a "addr" message.

3) Fingerprinting
ISPs or any other MITM can intercept/inject fingerprinting relevant
messages like "mempool" to analyze the bitcoin network.

4) SPV
For obvious reasons regarding BF (see BIP or above).

5) Goundwork for a "client-server" model over the P2P channel
Fee estimation, bloom-filters, or any other message type that requires
authentication.

I would not reduce BIP151 to only solve the BF privacy/censorship problem.

If we agree that censorship-resistance is one of the main properties of
Bitcoin, then we should definitively use a form of end-to-end encryption
between nodes. Built into the network layer.

There are plenty of other options to solve this problem. stunnel,
Bernsteins CurveCP, VPN, etc. which are available since years.
But the reality has shown that most bitcoin traffic is still unencrypted.
Example: IIRC non of the available SPV wallets can "speak" on of the
possible encryption techniques. Encrypting traffic below the application
layer is extremely hard to set up for non-experienced users.

On top of that, encryption allows us to drop the SHA256 checksum per p2p
message which should result in a better performance on the network layer
once BIP151 is deployed.

I agree that BIP151 _must_ be deployed together with an authentication
scheme (I'm working on that) to protect again MITM during encryption
initialization.

---




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

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

[Jonas Schnelli via bitcoin-dev]

> To quote:
> 
>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key").
>>
>>  K_1 must be the left 32bytes of the HMAC_SHA512 hash.
>>  K_2 must be the right 32bytes of the HMAC_SHA512 hash.
> 
> This seems a weak reason to introduce SHA512 to the mix.  Can we just
> make:
> 
> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key")
> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")

SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
make use of bip32 features. I though a single SHA512_HMAC operation is
cheaper and simpler then two SHA256_HMAC.

AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
Bitcoin-Core uses it for HTTP RPC auth and Tor control.

I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC.



[1]
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions



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

Re: [bitcoin-dev] BIP 151 MITM

[Jonas Schnelli via bitcoin-dev]

Hi

> On Thu, Jun 09, 2016 at 01:24:09AM +, Gregory Maxwell wrote:
>> Reduction to plaintext isn't an interesting attack vector for an active
>> attacker: they can simply impersonate the remote side.
>>
>> This is addressed via authentication, where available, which is done by a
>> separate specification that builds on this one.
> 
> Are there any links to discussions on how authentication may be done?

I'm currently working on the Auth-BIP which is not worth reviewing it
right now (I will post it to the mailing list once it has been reached a
stable level where it can be discusses).

If you can't wait, here is the current work:
https://github.com/jonasschnelli/bips/blob/35d7e382cdd6955ff42726c3d06c44e33f61ae52/bip-undef-0.mediawiki


Most recent MITM/auth discussion (there where plenty of discussions on
IRC about this topic):
https://botbot.me/freenode/bitcoin-core-dev/2016-04-04/?msg=63463826&page=3






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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

>> Good point.
>> I have mentioned this now in the BIP but I think the BIP should allow
>> message > 16 MiB.
>> I leave the max. message length up to the implementation while keeping
>> the 4 byte length on the protocol level.
> 
> I expect the implementation defined max size to work (SSH 2.0 does this
> after all), but I want to make sure my suggestion is understood
> completely.
> 
> There is a length field for the encrypted data, and length field(s)
> inside of the encrypted data to indicate the length of the plaintext
> Bitcoin messages. I am suggesting that the outter (encrypted) length
> field be reduced, which will _not limit_ the length of Bitcoin
> messages. For example, if a 1 GiB Bitcoin message needed to be sent
> and the encrypted length field was 3 bytes - the sender is forced to
> send a minimum of 64 MACs for this message. The tradeoff is allowing
> the receiver to detect malformed data sooner and have a lower max
> buffering window **against** slightly higher bandwidth and CPU
> requirements due to the additional headers+MACs (the CPU requirements
> should primarily be in "finalizing each Poly1305").

Okay. Got your point.
The current BIPs assumption is that an encrypted package/message can
contain 1..n bitcoin messages (a single bitcoin message distributed over
multiple encrypted messages/packages was not specified).

But right, this could make sense.
Let me think this through

> An alternative way to think about the suggestion is tunnelling Bitcoin
> messages over TLS or SSH. TLS 1.2 has a 2-byte length field and SSH 2.0
> a 4-byte length field, but neither prevents larger Bitcoin messages from
> being tunnelled; the lengths are independent.

TLS/SSH tunneling is already possible with third party software like
stunnel.
Also there is promising projects that would encrypt the traffic "on a
deeper layer" (see CurveCP).

I think what we want is a simple, openssl-independent traffic encryption
built into the core p2p layer.

IMO the risk of screwing up the implementation is moderate.

The implementation is not utterly-complex:
OpenSSH chacha20:
https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cba69011a535f86f6b/chacha.c

Chacha20-Poly1305:
https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cba69011a535f86f6b/cipher-chachapoly.c

Sure. Before an implementation will be deployed to the endusers it will
require intense cryptoanalysis first.





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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

Hi Lee

Thank you very much for the valuable input.
I'm still processing your feedback

> 
> *Key Revocation*
> This is probably too complicated, but an additional public key would
> allow for cold-storage key revocation. Spreading the knowledge of such
> an event is always painful, but it could be stored in the blockchain. I
> think this is likely too complicated, but having these long-term keys
> constantly in memory/disk is unfortunate.
> 

Yes. This could be something that could be extended once the BIP is
stable and/or implemented.



>> K_1 must be used to only encrypt the payload size of the
>> encrypted message to avoid leaking information by revealing the
>> message size. 
>>
>> K_2 must be used in conjunction with poly1305 to build
>> an AEAD.
> 
> Chacha20 is a stream cipher, so only a single encryption key is needed.
> The first 32 bytes of the keystream would be used for the Poly1305 key,
> the next 4 bytes would be used to encrypt the length field, and the
> remaining keystream would be used to encrypt the payload. Poly1305
> would then generate a tag over the length and payload. The receiver
> would generate the same keystream to decrypt the length which
> identifies the length of the message and the MAC offset, then
> authenticate the length and payload, then decypt with the remaining
> keystream.
> 

Right. The AEAD construct I though of is probably called
chacha20-poly1...@openssh.com and specified in
https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305#L34

I think this construct has already serval implementations and is widely
used.

I have updated the BIP to mention the chacha20-poly1...@openssh.com
specification.

> Is it safer to define two keys to prevent implementations from screwing
> this up? You have to split the decryption and authentication, so the
> basic modes of libsodium cannot be used for instance. If a custom tag
> generation scheme is being used, then the basic modes are already
> unusable ...
> 
> *Failed Authentication*
> What happens on a failed MAC attempt? Connection closure is the
> easiest way to handle the situation.

Yes. I think closing would make sense.

>> After a successful encinit/encack
>> interaction from both sides, the messages format must use the
>> "encrypted messages structure". Non-encrypted messages from the
>> requesting peer must lead to a connection termination (can be
>> detected by the 4 byte network magic in the unencrypted message
>> structure).
> 
> The magic bytes are at the same offset and size as the encrypted length
> field in the encrypted messages structure. So the magic bytes are not a
> reliable way to identify unencrypted messages, although the probability
> of collision is low.

Yes. This is a good point.
The implementation should probably also accept messages that contain the
4 byte network magic from unencrypted messages (to avoid possible
collisions).
If the message is unencrypted, the length check or the unsuccessful
authentication check will lead to a disconnect.

>> {|class="wikitable"
>> ! Field Size !! Description !! Data type !! Comments
>> |-
>> | 4 || length || uint32_t || Length of ciphertext payload in number
>> of bytes
>> |-
>> | ? || ciphertext payload || ? || One or many ciphertext command &
>> message data
>> |-
>> | 8 || MAC tag || ? || MAC-tag truncated to 8 bytes
>> |}
> 
> Why have a fixed MAC length? I think the MAC length should be inferred
> from the cipher + authentication mode. And the Poly1305 tag is 16 bytes.
> 
> *Unauthenticated Buffering*
> Implementations are unlikely to (i.e. should not) process the payload
> until authentication succeeds. Since the length field is 4 bytes, this
> means an implementation may have to buffer up to 4 GiB of data _per
> connection_ before it can authenticate the length field. If the outter
> length field were reduced to 2 or 3 bytes, the unauthenticated
> buffering requirements drop to 64 KiB and 16 MiB respectively. Inner
> messages already have their own length, so they can span multiple
> encrypted blocks without other changes. This will increase the
> bandwidth requirements when the size of a single message exceeds 64 KiB
> or 16 MiB, since it will require multiple authentication tags for that
> message. I think an additional 16 bytes per 16 MiB seems like a good
> tradeoff.
> 

Good point.
I have mentioned this now in the BIP but I think the BIP should allow
message > 16 MiB.
I leave the max. message length up to the implementation while keeping
the 4 byte length on the protocol level.

> 
>> A responding peer can inform the requesting peer over a re-keying
>> with a encack message containing 33byte of zeros to
>> indicate that all encrypted message following after this
>> encack message will be encrypted with ''the next
>> symmetric cipher key''.
>>
>> The new symmetric cipher key will be calculated by
>> SHA256(SHA256(old_symetric_cipher_key)).
>>
>> Re-Keying interval is a peer policy with a m

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Jonas Schnelli via bitcoin-dev]

> On 14/05/16 10:16, Jonas Schnelli via bitcoin-dev wrote:
>> Importing a bip32 wallet (bip44 or not) is still an expert job IMO.
> 
> That's simply not true. All reasonable wallets (reasonable = user
> oriented) now use BIP39 mnemonic for doing exactly this.

AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs
android wallet [1] and Electrum [2] and Breadwallet [3].

But I think forming a BIP39 mnemonic into a extended master private key
is not the problem here.

The problems I see:
* What if the "old" wallet has used more then 1000 addresses? I guess
some wallets do not even create a lookup window up to 1000 addresses.
There is a high chance of loosing funds when doing sweep (move all funds
to a new wallet) operation.

* I guess most or maybe all wallets will keep all keys (the
"lookup-window" keys) in the wallet database which could affect
performance [4]

* I guess most wallets do not offer "moving the funds to a new seed" [5]
which results in not solving the problem of a "lost" or "compromised"
wallet and implies wrong security to the enduser.

* If I import a bip39 mnemonic into a hardware wallet (assume Trezor or
Keepkey) I have to type in the words into my computer which bypasses
some of the security my hardware wallet provides me (MITM seed attack).
Together with the point above this reduces the security of a wallet (in
particular cold storage significant).

Please correct me if I'm wrong.

I just wanted to point out that importing a wallet is a tricky step
especially cross-wallet imports (I think cross wallet imports is an
experts job without further improvements).

[1] https://github.com/bitcoin-wallet/bitcoin-wallet/issues/245
[2] http://docs.electrum.org/en/latest/seedphrase.html
[3] https://github.com/voisine/breadwallet/issues/360
[4] https://github.com/bitcoin-wallet/bitcoin-wallet/issues/158
[5]
https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRRestoreViewController.m#L225





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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Jonas Schnelli via bitcoin-dev]

Hi

> That's a valid concern, but I don't see the conflict here. In order to
> recover funds from a wallet conforming to BIPXX, you must have wallet
> software that handles BIPXX. Simply making BIPXX backwards compatible
> with previously created BIP44 or BIP43 purpose 0 wallets doesn't change
> this at all.

Maybe I'm going a bit offtopic. Sorry for that.

Importing a bip32 wallet (bip44 or not) is still an expert job IMO.
Also importing can lead to bad security practice (especially without a
sweep).

Users will send around xpriv or import an seed over a compromised
computer to a cold storage, etc.

I don't think users want to import private keys.
They probably want to import the transaction history and send all funds
covered by that seed to a new wallet.

I often though that task is better covered by a little GUI tool or
cli-app/script:
-> Accept different bip32 schematics (bip32 native, bip44, etc.)
-> Accept different bip39 (like) implementation
-> Create large lookup windows
-> Create a sweep transaction to a new address/wallet and sign/broadcast it.
-> Export transaction history (CSV)

But maybe I'm over-complicating things.

--




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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362

Hi.
I just updated the PR above with another overhaul of the BIP.
It's still under heavy review/work, nevertheless – at this point – any
feedback is highly welcome.

Changes since last update:
-> Removed AES256-GCM as cipher suite
-> Focusing on Chacha20-Poly1305 (implementation size ~300L)
-> Two symmetric cipher keys must be calculated by HMAC_SHA512 from the
ecdh secret
-> A session-ID (both directions) must be calculated (HMAC_SHA256) for
linking an identity authentication (ecdsa sig of the session-ID) with
the encryption
-> Re-Keying ('=hash(old_key)') can be announced by the responding peer
(after x minutes and/or after x GB, local peer policy but not shorter
then 10mins).
-> AEAD tag is now the last element in the new message format

It is very likely that the encrypted message format performs slightly
better than the current message format (removing the SHA256 checksum).

---




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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

> I guess my question didn't get across.
> 
> Why would you want to make your usecase do connections over the
> peer2peer
> (net.cpp) connection at all?
> 
> Mixing messages that are being sent to everyone and encrypted
> messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
> 
> 
> I agree doing it out-of-band is the easiest solution for people who need
> this privacy right now, but I do like the idea of adding this feature as
> the number of SPV wallets is going to increase. I think the best way to
> organize things would be to give encrypted messages their own port
> number, similar to how http vs. https works.

I'm not sure if different ports would make sense. I can't see a benefit
(happy if someone can convince me).
How would this affect p2p address management (address relay)? Wouldn't
this require to extend the current address message to support two port
numbers?


> We don't want two networks to develop, separated by which nodes support
> encryption and which don't, so ideally nodes would rebroadcast messages
> they receive on both (encrypted and non-encrypted) channels. This would
> essentially double the required bandwidth of the network, which is
> something to think about.

It can be the same "p2p network". The only difference would be, that
once two peers has negotiated encryption, the whole traffic between
_these two peers_, and _only_ these two pears, would be encrypted (would
_not_ affect traffic to/from other peers).

A simplified example:
1. Peer Alice connects to peer Bob
2. Alice asks Bob: "lets do encrypted communication, here is my session
pubkey"
3. Bob also supports encryption and answers "Yes, let's do this, here is
my session pubkey"
4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'm
Alice by signing the session ID with my identity pubkey"
5. Bob checks his "authorized-peers" database and look-up Alices pubkey
and verifies the signatures.
6. Bob tells Alice: "Good! I trust you now Alice, here is my identity
pubkey with a signature of our session-ID"
7. Alice looks up Bobs pubkey in her "known-peers" database and verifies
the signature.
8. Alice response to bob: "Perfect. Indeed, you are Bob!"
---
At this point, the communication is encrypted and the identities has
been verified (MITM protection).


(simplified negotiation [only one-way, missing dh explanation, missing
KDF, session-ID, cipher suite nego., missing re-keying, etc.])






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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

> I guess my question didn't get across. 
> 
> Why would you want to make your usecase do connections over the peer2peer 
> (net.cpp) connection at all?

First, because there _are_ a hight amount of SPV wallets in the field.
SPV wallets are "dumb-clients" with only a tiny value for the bitcoin
network (they don't validate, they don't relay). They already are
decoupled wallets. We need solution that offers higher privacy and
higher traffic analysis resistance.

Using the p2p channel for communication between full validation peers
and wallet-only-peers makes sense IMO because wallet-only-peers can
slowly validate the chain and create a UTXO set in the background (could
take a couple of weeks) or solve other purposes that increases the
security and/or serving something back to the bitcoin network.

Sure, you can always use client/server wallets (Coinbase / Copay, etc.)
that offers SSL.
But I strongly recommend to improve the communication and interface
possibilities between wallet-nodes (SPV) and full-validation-nodes.

Otherwise we will very likely see centralization regarding end-user
wallets (with all the large risks of disrupting the community in case of
attacks/thefts, etc.).

_If we think Bitcoin should scale, we also need to scale and improve at
the point where users enter the network and start using Bitcoin._

> Mixing messages that are being sent to everyone and encrypted messages is 
> asking for trouble.
> Making your private connection out-of-band would work much better.

The current encryption BIP requires to encrypt the complete traffic.
Having an option to do analysis resistant communication with a remote
peer within the protocol itself is something that is very valuable IMO.


>>> Also, you didn't actually address the attack-vector.
>>
>> Which attack-vector?
> 
> The statistical attack I mentioned earlier.  Which comes from knowing which 
> plain text messages are being sent over the encrypted channel, So as long as 
> you keep saying you want to encrypt data that identical copies of are being 
> sent to other nodes at practically the same time, you will keep being 
> vulnerable to that.

The encryption BIP recommends Chacha20-Poly1305 as encryption AEAD. This
is a very broad used encryption scheme (Google uses it to connect
Android phones with their cloud services).

Completely avoiding side channel on data analysis would probably require
extremely inefficient constant time encrypted datastreams.

Also, the BIP allows combining of multiple plaintext message in one
encrypted message.

Additionally we could extend the enc. BIP by allowing random padding of
encrypted messages or other techniques to reduce side channel analysis.





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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

Hi Tom

>> The encryption should be optional.
>> The proposed authentication scheme does take care of the
>> identity-management and therefor prevent MITM attacks.
>> Without the identity management, you might not detect sending/receiving
>> encrypted data from/to a MITM.
> 
> If you want to extend the Bitcoin protocol itself, you will have to resolve 
> that. Which many other solutions do (ssh for instance).

Please check the newest auth BIP (it solves MITM).

The encryption BIP itself does not cover peer authentication.
Encryption without authentication of peers can also be valuable.


>>> * What is the reason for using the p2p code to connect a wallet to a node?
>>> I suggest using one of the other connection methods to connect to the
>>> node.
>>> This avoids a change in the bitcoin protocol for a very specific usecase.
>>
>> Most known use-case: SPV.
> 
> You didn't answer the question.

I hope you see the today's problem with SPV.
You fully reveal to your ISP / WiFi provider most of your wallet
controlled addresses (when using BF). The ISP/WiFi provider can link
your bitcoin usage to other inet traffic and/or they could sell
information to statistics company like google.

Also, an attacker controlling a WiFi router or any other network peer
between your SPV node and the remote full node could censorship
transactions.

Etc. etc.

An encrypted channel together with a trusted full node would finally
allow to have a secure and save SPV communication.


>>> * Why do you want to do a per-message encryption (wrapping the original)?
>>> Smaller messages that contain predictable content and are able to be
>>> matched to the unencrypted versions on the wire send to other nodes will
>>> open this scheme up to various old statistical attacks.
>>
>> It's probably extremely inefficient to create a constant time stream.
> 
> Your use of "probably" makes me wonder if you already have an implementation. 
> Doing any encryption and handshaking design *without* actually having it 
> coded 
> and gone though testing yet makes no sense.
> I do not belief Bitcoin will benefit from "design by committee" where a 
> specification is drawn before an implementation is written.
> 
> Also, you didn't actually address the attack-vector.

Which attack-vector? MITM? Is conceptual solved with the auth BIP (that
requires encryption).

There is no implementation done yet.
It would be a waste of time to start writing a such implementation
_before_ having this discusses and improved by the community.

But the encryption BIP now recommends Chacha20-Polay1305 as AEAD which
is widely used.

I'm ready to write an implementation as soon as I have some signs that
the BIP does make sense.

Also, auth and enc is not something we will have in the next couple of
weeks. This might require a couple of months until its stable and ready
for production.

> 
>  
 Responding peers must ignore (banning would lead to fingerprinting) the
>>>
>>> requesting peer after 5 unsuccessfully authentication tries to avoid
>>> resource attacks.
>>>
>>> Any implementation of that kind would itself again be open to resource
>>> attacks.
>>> Why 5? Do you want to allow a node to make a typo?
>>
>> Good point. Maybe one false try should lead to ignoring the peer.
> 
> That doesn't take away the resource attack at all.
> 
>  
 To ensure that no message was dropped or blocked, the complete
 communication> 
>>> must be hashed (sha256). Both peers keep the SHA256 context of the
>>> encryption session. The complete enc message (leaving out
>>> the hash itself) must be added to the hash-context by both parties.
>>> Before sending a enc command, the sha256 context will be
>>> copied and finalized.
>>>
>>> You write "the complete communication must be hashed" and every message
>>> has a hash of the state until it is at that point.
>>> I think you need to explain how that works specifically.
>>
>> This is a relative simple concept and does not require rehashing the
>> whole communication. 
> 
> Apologies, I should have been more clear; the BIP should specify the actual 
> algorithm, otherwise you can't create an implementation from just reading the 
> BIP.

The sha256 context is gone now and replaced by a proper MAC.

> 
> Also, this may be a good time to ask why you want to have a per-message 
> encryption?
> Practically every single popular end-to-end encryption uses one approach or 
> another were it just encrypts as another layer. (the  L in ssl). You are 
> mixing layers, and unless you do that for a very good reason, or have a very 
> good reason why everyone else is doing it wrong, I suggest using a layered 
> encryption approach.

Like most other encryption layers, we would still use messages. But we
call them "encrypted messages", the have a tiny header of plaintext data
(message length, AEAD-tag) and they will contain  plaintext p2p
messages _after_ decrypting. The plaintext messages have a much simpler
header (removed the 4 bytes sha256 checksum, removed t

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362

Thanks for the feedback and IRC discussions.

I have overhauled both BIPs.
https://github.com/bitcoin/bips/pull/362/files#diff

Main changes for the encryption BIP:
* No message wrapping. Once encryption is established, everything is
encrypted. No timeout.
* Added MAC: proposed AEAD is now ChaCha20-Poly1305 with an alternative
for AES256-GCH
* Independent ECDH negotiation and independent secrets for the symmetric
cipher for both communication directions
* Optimized message format and message-batch-option for encrypted data

It could be that the p2p performance for Chacha20-poly1305 encrypted
message is slightly better then the current plaintext message format
(dropping the network magic and the sha256 per message).

P2p authentication BIP:
* No message wrapping. Peers keep the state once authenticated.
* Simplified and auth now requires encrypted channels.


Some answers...

> How does a peer know what messages the other peer requires to be
authenticated?

This is not covered by the auth BIP. Peers could agree on a protocol
extension outside of any BIP.
Once auth is possible, new BIPs could be written. Things like only
allowing filtering (or other services) to authenticated peers (and
disabling NODE_BLOOM).

> How does banning in this specific case enable fingerprinting as
opposed to any other banning?

Current nodes ignore a unknown message with a command like "auth".
Banning would allow a requesting peer to identify nodes that support
auth and attack them over different channels ("ah, ... this guy supports
auth, they must have some secret data, lets attack over SSH).

>> This proposal is backward compatible. Non supporting peers will
ignore the auth message.
> ... and not process it at all? How is that backward compatible?

Depends how we define backward compatibility. :-)
Peers supporting this "extension" can still interact with older peers.

> This proposal is backward compatible. Non supporting peers will ignore
the > enc* messages.

Current p2p implementation ignores any unknown command.






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

Re: [bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

>> I have just PRed a draft version of two BIPs I recently wrote.
>> https://github.com/bitcoin/bips/pull/362
> 
> I suggest running a spellchecker ;)

Thanks. Will do.


> * why would you not allow encryption on non-pre-approved connections?

The encryption should be optional.
The proposed authentication scheme does take care of the
identity-management and therefor prevent MITM attacks.
Without the identity management, you might not detect sending/receiving
encrypted data from/to a MITM.

> * we just removed (ssl) encryption from the JSON interface, how do you 
> suggest 
> this encryption to be implemented without openSSL?

The proposed encryption schema is based on ECDSA/ECDH (implemented in
libsecp256k1) and AES256CBC (implementation is on the way see
https://github.com/bitcoin/bitcoin/pull/7689).
OpenSSL is not required.

> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node. 
> This avoids a change in the bitcoin protocol for a very specific usecase.

Most known use-case: SPV.

> * Why do you want to do a per-message encryption (wrapping the original)? 
> Smaller messages that contain predictable content and are able to be matched 
> to the unencrypted versions on the wire send to other nodes will open this 
> scheme up to various old statistical attacks.

It's probably extremely inefficient to create a constant time stream.
Even most SSL/SSH application leak information because of the
communication message characteristics.

The current wrapping message proposal is not very efficient.
I will change it so that the p2p message header will contain the
encryption metadata. This should lead to a tiny overhead.


> 
>> Responding peers must ignore (banning would lead to fingerprinting) the 
> requesting peer after 5 unsuccessfully authentication tries to avoid resource 
> attacks.
> 
> Any implementation of that kind would itself again be open to resource 
> attacks.
> Why 5? Do you want to allow a node to make a typo?

Good point. Maybe one false try should lead to ignoring the peer.

> 
> 
>> To ensure that no message was dropped or blocked, the complete communication 
> must be hashed (sha256). Both peers keep the SHA256 context of the encryption 
> session. The complete enc message (leaving out the hash itself) 
> must be added to the hash-context by both parties. Before sending a 
> enc command, the sha256 context will be copied and finalized.
> 
> You write "the complete communication must be hashed" and every message has a 
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.

This is a relative simple concept and does not require rehashing the
whole communication. You just append the "new data".

Some pseudocode:

SHA256CTX ctx;

// first com
SHA256CTX_Update(ctx, 1stmessage);

// copy context
SHA256CTX ctxnew = ctx;

// finalize the copied context
sha256hash = SHA256CTX_Finalize(ctxnew); //use as checksum hash


 next message
SHA256CTX_Update(ctx, 2ndmessage);

// copy context
SHA256CTX ctxnew = ctx;

// finalize the copied context
sha256hash = SHA256CTX_Finalize(ctxnew); //use as checksum hash

... etc.





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

[bitcoin-dev] p2p authentication and encryption BIPs

[Jonas Schnelli via bitcoin-dev]

Hi

I have just PRed a draft version of two BIPs I recently wrote.
https://github.com/bitcoin/bips/pull/362

Two BIPs that addresses the problem of decoupling wallets/clients from
nodes while assuming a user (or a group) know the remote peer.

Authentication would be necessary to selective allow bloom filtering of
transactions, encryption or any other node service that might lead to
fingerprinting or resource attacks. Authentication would also be a
pre-requirement for certificate free encryption-handshakes that is
(enough?) resistant to MITM attacks.

Encryption is highly recommended if you connect a SPV node to a trusted
node.

Authentication would allow accessing private p2p extensions from a
remote SPV peer (example: fee estimation).

I'm aware of other methods to increase privacy and integrity (tor, VPN,
stunnel, etc.), however I think authentication and a basic communication
encryption should be part of the protocol and its setup should be
complete hassle-free.

Thanks for your feeback.

/jonas



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

Re: [bitcoin-dev] consensus rule change for TX fee safety

[Jonas Schnelli via bitcoin-dev]

Hi

> My guess is the user was using a client that does not adjust TX fee, and
> needed to manually set it in order to get the TX in the block sooner,
> and meant 15 mBTC or something.
> 
> I suggest that either :
> 
> A) TX fee may not be larger than sum of outputs
> B) TX fee per byte may not be larger than 4X largest fee per byte in
> previous block

I don't think a such "feature" or lets say protection should be part of
the consensus layer.

Such checks should be done by the tx creation clients (wallets) – or –
nodes could have an option to not accept transaction with insane fees
into their mempool (policy).





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

[bitcoin-dev] Fast bootstrapping with a pre-generated UTXO-set database

[Jonas Schnelli via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi

I’ve been thinking around a solution to reduce nodes bootstrap time
(IBD) as well as a way to reduce the amount of bandwidth/network usage
per node.
Not sure if this idea was/is already discussed, haven’t found anything
in a quick research.


==Title==
Fast bootstrapping with a pre-generated UTXO-set database.

==Abstract==
This documents describes a way how bitcoin nodes can bootstrap faster
by loading a pre-generated UTXO-set datafile with moderate reduction
of the security model.

==Specification==
Bitcoin-core or any other full node client will need to provide a
feature to "freeze" the UTXO-set at a specified height (will require a
reindex). The frozen UTXO-set – at a specific height – will be
deterministic linearized in a currently not specified
data-serializing-format.
Additionally, a serialized form of the current chain-index (chain
containing all block-headers) up to the specified height will be
appended to the pre-generated UTXO-set-datafile.
The datafile will be hashed with a double SHA256.

The corresponding hash will be produced/reproduced and signed (ECDSA)
by a group of developers, ideally the same group of developers who are
also signing deterministic builds (binary distribution).

Full node client implementations that supports bootstrapping from a
pre-generated UTXO-set, need to include...
1.) a set of pubkeys from trusted developers
2.) the hash (or hashes) of the pre-generated UTXO-set-datafile(s)
3.) n signatures of the hash(es) from 2) from a subset of developers
defined in 1)

To guarantee the integrity of developers pubkeys & signatures, methods
like the current gitian build, used in bitcoin-core, must be used.

New nodes could download a copy of the pre-generated UTXO-set, hash
it, verify the hash against the allowed UTXO-sets, verify the ECDSA
signatures from various developers, and continue bootstrapping from
the specified height if the users accepts the amount of valid signatures
.

Sharing of the pre-generated UTXO-set can be done over CDNs,
bit-torrent or any other file hosting solution. It would also be
possible to extend the bitcoin p2p layer with features to
distribute/share a such pre-generated UTXO-set, in chunks and with the
according hashes to detect invalidity before downloading the whole
content (but would probably end up in something very similar to
bit-torrent).


- --

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW1B1wAAoJECnUvLZBb1PsqzsP/iSdvyhUzy+BZVSZbKXNjk5P
2vrtirI6NvKQd8hHbrcFeLfyswzYc2JWRnX8sATlauIS0pYdr97JriwUGlvxvNrY
iVTDdf8MIVu8zScLQtJbMatpMvsewtqQEidn/yxWIhiCg4G2T5DZmlBU6O4XIKR6
5aPHElGOKZ15EWGHBG7z4owj3MiOaxhD9q5erBbfLPpcm08o6XAv5miqmGnnn3zh
gocg4Gxs6iDygh3b2dCJFwWIVPxF6UVJhyjv2kLZUmEHT2Y2QvdGcLIIewcWHDze
kgoZYmOEowujCbmeJ+LBwgOI0c1N6L/ciomPBne7ILmK4LyUEzyMLJKNYf/sZ8vI
sVlmwZwZZLfILC7mzMAM0pfj99IOW680WHch9v31lWFlxW/bLvLqAO7n3acQuD6s
xCZN2nAhmWC8FnMFxqB3EUz0lX8giV3qRJZjbQMS+ZrngYkAmVv2bAsoLndqf6MO
l9W8B+ICg1KZLGIOF2pUrInpkB6gUALDFnypV4CeIVdeqtk5l4LnCHK6c4++Hl5n
Bv5HQ/wTgKKNFtHBEJpWyYWvAjfFtgUZUKblR+Bh+D7/Gte1ehiYd02KYD4ds9Y4
3gfO8YbAz/I14Yuh2bIlvVKPWnLQBwL5BBioBfvmhV/r6rEpzWvB7H6Fmi1c759l
VlL0GiUV8ar2LlFhEmWk
=lZSy
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available

[Jonas Schnelli via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


> Why is the minimum storage quota of 550 MiB necessary for pruning
> nodes if the block data is not served to other nodes ? Could the
> client just do transaction verification and transaction relaying
> and only keep the block(s) being verified on disk ?
> 

We try to allow reorgs ~288 blocks deep also in pruning:

- From code comments:
Require that user allocate at least 550MB for block & undo files
(blk???.dat and rev???.dat)
At 1MB per block, 288 blocks = 288MB.
Add 15% for Undo data = 331MB
Add 20% for Orphan block rate = 397MB
We want the low water mark after pruning to be at least 397 MB and
since we prune in
full block file chunks, we need the high water mark which triggers the
prune to be
one 128MB block file + added 15% undo data = 147MB greater for a total
of 545MB
Setting the target to > than 550MB will make it likely we can respect
the target.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWpklQAAoJECnUvLZBb1Ps464P+gNqN+Rs5MnAFg5Hukxcj9BU
f+Zm5B99VMT3qWjJUjk05NTPLoa6vS6I6pkanWNlzmquZSardW0rW/7JS8wu8BiA
ILP3gMWMiF2w//0o+4uEhQt5FhUKQGUVgtXDprc/6WeOfpEBunk+/YTmFPpSMQym
w9roH+vrMBHNogSXjdIsn3qPGdVWWuc1PeeluMthN/f7Y5Y5kcyUJvvJmhNbNspG
UaGqh7vCDBvaHmxKuPRvqPlSqvwXjA3kxDP1s+VBtLGKnJzVoBqBEsody0UscQQO
RRvxbEdaRL1iTVgA0orsDCOMsBaUcKiZ4tlJUd+Z+ifHCVJ5Szl5fsqIIElF8vOk
hy8++T4XqPEZqlDnAIpOxE0eGnByvdkUrFew60nA+A+ivY7GkCFhMz8AP4VHrhFS
UOU2wDuBOsA6ssqkxMmc5Vizyb6CmL2Ho0csPqabvfRYk5VZACc63FbJ2xcdjDZz
CufvfJZ3O5dgSy29fn9XQHsU8qSn0DteSU/9OiHAJmvkqrvB0yT21kIQXUWiqYGk
xDvc/SVpttYqaW2hAgjFG9NGJ/D2dpliYNUjgwmijUVZuI9bkJ68l5CfpOzXYnNJ
e1AFzBeHVCKSn0advmTVdyybslU32g7ytzJQcQP2b8a4GQYEI6DNhTA5HTxWaj//
O+Cm0CkAbW1vNJqSolnU
=lDcA
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What is OpenSSL still used for?

[Jonas Schnelli via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Andrew

> In the release notes for 0.12, it says that we have moved from
> using OpenSSL to libsecp256k1 for signature validation. So what
> else is it being used for that we need to keep it as a dependency?

Openssl was dropped from the consensus layer (ECC) in 0.12, though, it
still used for...

1) ... getting random numbers (randomize the ECC signing context)
2) [wallet only] ... AES256 encryption of private keys
3) [GUI only] ... SSL/X.509 for BIP70 (payment protocol)

Openssl dependency for 1) and 2) could be removed. There are some –
outdated – relevant PRs:

Entropy: https://github.com/bitcoin/bitcoin/pull/5885
AES: https://github.com/bitcoin/bitcoin/pull/5949

I guess for point 3) [BIP70] it makes sense to keep openssl.

/jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWoIwAAAoJECnUvLZBb1PsWSMP/2VyURcUUmnFodX1UUkkTQSu
KmEMqRe3Ak1v4B5S+7raodYE+7ePONedHrciUgNfj0GBDu7/5Wl3LD0GnFb0//Nl
JEHPzNQB8xhRjhXux17rq+Kf60qjc+uybJQDDs9KfQQYS+hFTUKXX61s7wwY/QAy
6Vi5FxZRThzFUFWFZvG9KbRLWEbBVONnXLaA4pB0o7UnU2wAHkmPP5wyeCJLy3cW
uggeLYh3X6GBF/+IQ0ndO4yFJ09ROXBS7N1VisJy2Z4zTJr0y6rAVVG9XcPtlkMc
SvMULeiB34odvlZMRMFdCYLHCuff30jN2+aEJST/d+lr4IB2ai8veXwt69yya4p2
4UUL5ueOzKWfgcxVT/qDDcVkZJFqrhdHmMaEggelRakQCSdLly+4X7Mdo/Dx/RC2
PYUDQVGGFephTpzBTQ3fpRGtZu2JX45T2RKyF2qcVlzXrRW7SjqzwGWWuutwbbrS
V9cSMMVS7NU90mgCE4e3G2oqi40H8dOzg+opf5ynChEccgJwUlxrfjj4kJbQZRH1
X00tGeVs93MxQes+vacYq7VYX4pzM1kiU3EMNStyAvCzd8FbGxmiv3C1VKhRj3xK
Oo98Yg18OBL2jQCWHza3nOU5jN8AnjlkXNvrqsaGedjVNirlnR6a+qmklNIiY1lE
kBxMbfAhTLPY3ukqtaSh
=4GfM
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Announcing Jonas Schnelli as GUI maintainer

[Jonas Schnelli via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> I'd like to announce Jonas Schnelli as the new GUI maintainer of
> Bitcoin Core.
> 
> He's been very active in this area for the last year, as one
> example he redesigned all the icons for 0.11.0, has visualized
> various network statistics, and has been continuously improving the
> user experience. Something Bitcoin Core very much needs, in my
> opinion.
> 
> Unofficially he has been giving direction in GUI matters for quite
> a while already, so this only makes it 'official'.
> 
> He will be handling GUI related issues on the github tracker, and
> assisting on and merging GUI-related pull requests.
> 
> Welcome Jonas to the team!
> 

Thanks Wladimir!

My long term vision for bitcoin-core was always a more user friendly
UI without loosing the security and privacy features bitcoin-core offers
.
However, it has shown that this is relatively hard to achieve. Its
unclear to me, what role wallets (and related UIs) will play in the
future of bitcoin. I think it needs several years until something like
bitcoin can be used to "pay for every coffee in the world" [1].
But I'm happy to explore this path!

That was and is also the reason why I'm often focus on non-UI-related
changes that keep bitcoin healthy and form a more defined role for the U
I.

Short words to myself:
I'm a senior software developer, 35 years old, living in Switzerland
(UTC+1).

Thanks for the trust and I try to give my best to maintain and improve
the GUI.

[1] https://twitter.com/ronmckown/status/643101952763658240
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWRZukAAoJECnUvLZBb1PsbEAP/jERgMowXP7rSV8FXwQ6mR+r
CdO4xs3OHKuRyZJKLhXq/aC48ThshzDynRcKAJifcxhoIN0Msnt2oz/kwyfJSssT
FHB2dZVmuSXSNdOKVjwemiIQJ1xVENrfBNEINNVkix3LNgbi/3vwPuNj/ImHjWOc
mTAcD+JkzZSdkWL53TWPY5noizl3hd/LJD0lJ357FZlzmnpt9UiiZw6+X3+n5aJI
7J5avpeEa36hppdej5Jh9V0Kq8JMkXgip/jSq9uP009Nki9RNywFQL+Pa26AgJvu
VxAyJRjq6Dcb8D6dux8QcC8K114tAWncR6Lh2Z9DepNHhytk/TYBSi9+MWbnuWci
JiN6fRCeBTt2A/m7IsUbVegfrmPgBiHAS5Mx+Q9vjTBzOOmpBbL2ZXOXR9wE3t3d
9hBodZxnK37gU8UwKsoOiWuB4+rTp4rlt5iz32jd+/r6zUXv3whOy11HuICzVR0c
ll2aHfvr8TkqTRds0cvrb5ZroT63mmGFaqJIrskVruVoMxVWjdqnOIiNxtXWSnCd
T9jmxdojqrSwtM+3A60UmrSNVwyhZudZFmyJsjHZGAK6aV/eGYb595vXUDvx8mtH
fzeqmpivONDrNhqFrbLPR1V8kBx0UCN5FreMjdXtmU81UTqLd4o5lCh0AFZ7upCq
2DiMpEgittqOtxDwb8YY
=Q5KE
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Ads on bitcoin.org website

[Jonas Schnelli via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all

I'm a little bit concerned about the future of bitcoin.org.
A neutral website that informs about bitcoin, bitcoin-applications and
bitcoin-exchanges is important at this "early stage".

You might have seen that bitcoin.com does not claim to be neutral and
informative. As counterweight, a neutral and ad-free bitcoin.org site
is even more important.

Recently, bitcoin.org did merge a PR [1] that enables Google analytics
for bitcoin.org. The PR comments did show disagreement for this step.
For me, this seems to be against the about-us rules [2] in about "who
is in charge of bitcoin".
Personally I think allowing Google to collect data of bitcoin.org
visitors is against the bitcoin "philosophy".

Another PR [3] (not merged yet) would enable the technical base to
display ads on the site.

What ads would be displayed there?
If an ad provider would be implemented (like Google Ads), very likely
bitcoin related things like bitcoin application vendors or bitcoin
exchanges would be shown there.
Wouldn't this attack the neutrality model of bitcoin.org?

I think, it would move bitcoin.org in the wrong direction, towards
sites like bitcoin.com and it would loose the neutral "feeling" and
users and press very likely will see this as a "greedy" step.

I'd like to know, how changes on bitcoin.org happen? Do they follow
consensus-agreement among bitcoin-space contributors or does a group
of people decide what to merge and what not?

If site operators or contributers need to get payed for their (highly
appreciated) work or need to pay for infrastructure, we should address
this root problem.
I'm pretty sure we can raise funds for a such purpose and I'm offering
my help to speak to bitcoin businesses and individuals.


[1] https://github.com/bitcoin-dot-org/bitcoin.org/pull/1087
[2] https://bitcoin.org/en/about-us
[3] https://github.com/bitcoin-dot-org/bitcoin.org/pull/1136
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWRZD0AAoJECnUvLZBb1PsrBoQALebNL8OUIucB/MqtI8JK9Fa
RctlDuJlPeLCOC0oXjM4WKu/mzYATSuc/2y1xxWQLgRgteKRMd1+4ZcCIz0fqbIk
M4RsEr24klybRl7A4+vMmuL0OsXd3vXjU52AUDrSokdaCEITxeSpsRROX+t+tKz4
It5CXRdZS9gyaDswCiWsnDTDbSSbpOiz7DzaBQTMziOQYr+VKQg5G0FSsVGrGNso
N2LpKtADBwpPbVP57S6NwAkOERcVQnIdJ2Ag6NgLLkdIA8z3lSgd+Yvn1rdbdKQh
NkPWy1e0QHUPS6gCunKguJA46UdO0vuIY+ZLNIaOtnnEQFKtSn3VYERghWPY9WQ2
PhBZXGuSsLyQg9/3qKeae9e11S+bz7xJpNOwJC8FnOOOS4h6W74O5UG4B7QXd3Ap
0eQZd2+iRlp59RNaKMbiXIHodmbB/nbefbH7HK+qNvKvL4i01Ar8FBPjXPXf3tOA
U5WHb6h7ClmOJ+tWsgB4RdhUISE/ryzyA4s59troQlIWRm7aWF9cjq1JWRqKWhfy
CfjVsRje9QBYnX3aS5Y9Vh8lGuArr8ZxiBbXgA7bL951GgWge747vxadvESeimCv
W2qf7oFzQ1QKAm8NbTzLHJEjq0HVop1KBjGS0rjyf0upA0Xtdu4u1cfTvhK0ULAe
ZCkR3m2qdxJ/JqtUbioq
=ZXsV
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev