Jonas Schnelli [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-10-08 to 2022-11-03
💬 Posted a total of 110 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP-45, patch
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxs

Profile Code

nprofile1qqsf5337p74cjcaszd5cc9dq7fzf6xwf0uacs3vwtp6qjk6sqm0e5rqhex773

Author Public Key

npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxs

Show more details

Last Notes

2023-09-07 11:52:35

- reply

📅 Original date posted:2023-09-01
🗒️ Summary of this message: Tom is working on compressing bitcoin transactions for transmission through steganography and satellite broadcasting, and it would be helpful to have size comparisons and a clear definition for when not to use height/index.
📝 Original message:
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

2023-06-07 23:16:40

- reply

📅 Original date posted:2022-11-03
📝 Original message:> 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

2023-06-07 18:21:48

- reply

📅 Original date posted:2019-11-23
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191123/2ef48e0b/attachment.sig>

2023-06-07 18:21:11

- reply

📅 Original date posted:2019-10-11
📝 Original message: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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191011/f88698ba/attachment.html>

2023-06-07 18:19:37

- reply

📅 Original date posted:2019-07-26
📝 Original message:> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190726/5d396389/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190726/5d396389/attachment.sig>

2023-06-07 18:19:35

- reply

📅 Original date posted:2019-07-22
📝 Original message: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 <https://github.com/petertodd/bloom-io-attack>
[2] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki>
[3] https://github.com/bitcoin/bitcoin/pull/9238 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190722/e941efeb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190722/e941efeb/attachment-0001.sig>

2023-06-07 18:18:43

- reply

📅 Original date posted:2019-06-17
📝 Original message: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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190617/06f5efa8/attachment-0001.sig>

2023-06-07 18:17:22

- reply

📅 Original date posted:2019-04-03
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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 for help with this.
>
> # More fully validating clients
>
> A particularly exciting use-case for assumeutxo is the possibility of mobile
> devices functioning as fully validating nodes with access to the complete UTXO
> set (as an alternative to SPV models). The total resource burden needed to start a node
> from scratch based on a snapshot is, at time of writing, a ~(3.2GB
> + blocks_to_tip * 4MB) download and a few minutes of processing time, which sounds
> manageable for many mobile devices currently in use.
>
> A mobile user could initialize an assumed-valid bitcoin node within an hour,
> transact immediately, and complete a pruned full validation of their
> assumed-valid chain over the next few days, perhaps only doing the background
> IBD when their device has access to suitable high-bandwidth connections.
>
> If we end up implementing an accumulator-based UTXO scaling design[5][6] down
> the road, it's easy to imagine an analogous process that would allow very fast
> startup using an accumulator of a few kilobytes in lieu of a multi-GB snapshot.
>
> ---
>
> I've created a related issue at our Github repository here:
> https://github.com/bitcoin/bitcoin/issues/15605
>
> and have submitted a draft implementation of snapshot usage via RPC here:
> https://github.com/bitcoin/bitcoin/pull/15606
>
> I'd like to discuss here whether this is a good fit for Bitcoin conceptually. Concrete
> plans for deployment steps should be discussed in the Github issue, and after all
> that my implementation may be reviewed as a sketch of the specific software
> changes necessary.
>
> Regards,
> James
>
>
> [0]: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
> [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
> [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @ 2.10GHz
> [3]: https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
> [4]: Marco Falke is due credit for this point
> [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
> [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/0005961e/attachment.sig>

2023-06-07 18:17:13

- reply

📅 Original date posted:2019-03-24
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190324/aef341d7/attachment.sig>

2023-06-07 18:17:11

- reply

📅 Original date posted:2019-03-22
📝 Original message: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 at 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 <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 <https://github.com/bitcoin/bitcoin/pull/15649#issuecomment-475782376>
Proposal:
<pre>
BIP: ???
Layer: Peer Services
Title: Version 2 Peer-to-Peer Message Transport Protocol
Author: Jonas Schnelli <dev at jonasschnelli.ch>
Status: Draft
Type: Standards Track
Created: 2019-03-08
License: PD
</pre>
== 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)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
Zohar, L.Vanbever]</ref>.
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 <ref
name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
BIP150]</ref> 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 ==
<blockquote>
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<ref>[https://tools.ietf.org/html/rfc2119
RFC 2119]</ref>.
</blockquote>
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
<code>NODE_P2P_V2</code>
<pre>
NODE_P2P_V2 = (1 << 11)
</pre>
A peer usually learns an address along with the expected service flags which
MAY be used to filter possible outbound peers.
A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted communication
specified in this proposal.
Peers MAY only make outbound connections to peers supporting
<code>NODE_P2P_V2</code>.
=== Handshake ===
<pre>
----------------------------------------------------------------------------------------
| Initiator Responder |
| |
| x, X := SECP256k1_KEYGEN() |
| CLIENT_HDATA := X |
| |
| --- CLIENT_HDATA ---> |
| |
| y, Y := SECP256k1_KEYGEN() |
| ECDH_KEY := SECP256k1_ECDH(X,y) |
| SERVER_HDATA := Y |
| |
| <-- SERVER_HDATA ---- |
| |
| ECDH_KEY := SECP256k1_ECDH(x,Y) |
----------------------------------------------------------------------------------------
</pre>
To request encrypted communication (only possible if yet no other messages have
been sent or received), the initiating peer generates an EC secp256k1 ephemeral
key and sends the corresponding 32-byte public key to the responding peer and
waits for the remote 32-byte public key from the counterparty.
ODD secp256k1 public keys MUST be used (public keys starting with 0x02). If the
public key from the generated ephemeral key is an EVEN public key (starting
with 0x03), negating the key and recalculating its public key SHOULD be done.
Only using ODD public makes it more complex to identify the handshake based on
analyzing the traffic.
The handshake request and response message are raw 32byte payloads containing
no header, length or checksum (the pure 32byte payload) and MUST be sent before
anything else.
Public keys starting with the 4-byte network magic are forbidden and MUST lead
to locally re-generate an ephemeral-key.
Pseudocode for the ephemeral-key generation
<pre>
do {
ecdh_key.MakeNewKey();
if (ecdh_key.GetPubKey()[0] == 3) {
ecdh_key.Negate();
}
} while (m_ecdh_key.GetPubKey()[0..3] == NETWORK_MAGIC);
</pre>
Once a peer has received the public key from its counterparty, the shared
secret MUST be calculated by using secp256k1 ECDH.
Private keys will never be transmitted. The shared secret can only be
calculated if an attacker knows at least one private key and the counterparties
public key. This key-exchange is based on the discrete log problem and thus not
sufficiently strong against known forms of possible quantum computer
algorithms. Adding an additional quantum resistant key exchange like NewHope is
possible but out of scope for this proposal.
After a successful handshake, the messages format MUST use the "v2 messages
structure". Non-encrypted v1 messages from the initiating peer MUST lead to an
immediate connection termination.
After a successful handshake, both peers MUST cleanse the ephemeral-session-key
from memory and/or persistence storage.
A peer not supporting this proposal will not perform the described handshake
and thus send a v1 version message.
Peers supporting this BIP MAY optionally allow unencrypted v1 communication by
detecting a v1 version message by the initial 11-byte sequence of <code>4byte
net magic || "version"</code>.
=== Symmetric Encryption Cipher Keys ===
Once the ECDH secret (<code>ECDH_KEY</code>) is calculated on each side, the
symmetric encryption cipher keys MUST be derived with HKDF
<ref>[https://tools.ietf.org/html/rfc5869 HKDF (RFC 5869)]</ref> after the
following specification:
1. HKDF extraction
<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="BitcoinSharedSecret||INITIATOR_32BYTES_PUBKEY||RESPONDER_32BYTES_PUBKEY", ikm=ECDH_KEY)</code>.
2. Derive Key_1_A (K_1 communication direction A)
<code>K1A = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_1_A", L=32)</code>
2. Derive Key_2_A (K_2 communication direction A)
<code>K1B = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_2_A", L=32)</code>
3. Derive Key_1_B (K_1 communication direction B)
<code>K2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_1_B", L=32)</code>
3. Derive Key_2_B (K_2 communication direction B)
<code>K2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_2_B", L=32)</code>
=== Session ID ===
Both parties MUST also calculate the 256bit session-id using <code>SID =
HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32)</code>. The
session-id can be used for authenticating the encryption-session (identity
check).
The session-id MUST be presented to the user on request.
=== ChaCha20-Poly1305 at Bitcoin Cipher Suite ===
==== Background ====
ChaCha20 is a stream cipher designed by Daniel Bernstein and described in
<ref>[http://cr.yp.to/chacha/chacha-20080128.pdf ChaCha20]</ref>. It operates
by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64
bit counter into 64 bytes of output. This output is used as a keystream, with
any unused bytes simply discarded.
Poly1305 <ref>[http://cr.yp.to/mac/poly1305-20050329.pdf Poly1305]</ref>, also
by Daniel Bernstein, is a one-time Carter-Wegman MAC that computes a 128 bit
integrity tag given a message and a single-use 256 bit secret key.
The chacha20-poly1305 at bitcoin combines these two primitives into an
authenticated encryption mode. The construction used is based on that proposed
for TLS by Adam Langley in
<ref>[http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 "ChaCha20
and Poly1305 based Cipher Suites for TLS", Adam Langley]</ref>, but differs in
the layout of data passed to the MAC and in the addition of encryption of the
packet lengths.
==== Detailed Construction ====
The chacha20-poly1305 at bitcoin cipher requires two 256 bits of key material as
output from the key exchange. Each key (K_1 and K_2) are used by two separate
instances of chacha20.
The instance keyed by K_1 is a stream cipher that is used only to encrypt the 3
byte packet length field and has its own sequence number. The second instance,
keyed by K_2, is used in conjunction with poly1305 to build an AEAD
(Authenticated Encryption with Associated Data) that is used to encrypt and
authenticate the entire packet.
Two separate cipher instances are used here so as to keep the packet lengths
confidential but not create an oracle for the packet payload cipher by
decrypting and using the packet length prior to checking the MAC. By using an
independently-keyed cipher instance to encrypt the length, an active attacker
seeking to exploit the packet input handling as a decryption oracle can learn
nothing about the payload contents or its MAC (assuming key derivation,
ChaCha20 and Poly1305 are secure).
The AEAD is constructed as follows: for each packet, generate a Poly1305 key by
taking the first 256 bits of ChaCha20 stream output generated using K_2, an IV
consisting of the packet sequence number encoded as an LE uint64 and a ChaCha20
block counter of zero. The K_2 ChaCha20 block counter is then set to the
little-endian encoding of 1 (i.e. {1, 0, 0, 0, 0, 0, 0, 0}) and this instance
is used for encryption of the packet payload.
==== Packet Handling ====
When receiving a packet, the length must be decrypted first. When 3 bytes of
ciphertext length have been received, they may be decrypted.
A ChaCha20 round always calculates 64bytes which is sufficient to crypt 21
times a 3 bytes length field (21*3 = 63). The length field sequence number can
thus be used 21 times (keystream caching).
The length field must be enc-/decrypted with the ChaCha20 keystream keyed with
K_1 defined by block counter 0, the length field sequence number in little
endian and a keystream position from 0 to 60.
Pseudo code example:
<pre>
// init
sequence_nr_payload = 0; //payload sequence number
sequence_nr_length_field = 0; //length field sequence number (will be reused)
aad_length_field_pos = 0; //position in the length field cipher instance keystream chunk
...
// actual encryption
if cache_length_field_sequence_number != sequence_nr_length_field {
cache_keystream_64_bytes = ChaCha20(key=K_1, iv=little_endian(sequence_nr_length_field), counter=0);
cache_length_field_sequence_number = sequence_nr_length_field
}
packet_length = XOR_TO_LE(cache_length_field_sequence_number[aad_length_field_pos - aad_length_field_pos+3], ciphertext[0-3])
sequence_nr_payload++;
aad_length_field_pos += 3; //skip 3 bytes in keystream
if (aad_length_field_pos + 3 > 64) { //if we are outside of the 64byte keystream...
aad_length_field_pos = 0; // reset at position 0
sequence_nr_length_field++; // increase length field sequence number
}
</pre>
Once the entire packet has been received, the MAC MUST be checked before
decryption. A per-packet Poly1305 key is generated as described above and the
MAC tag calculated using Poly1305 with this key over the ciphertext of the
packet length and the payload together. The calculated MAC is then compared in
constant time with the one appended to the packet and the packet decrypted
using ChaCha20 as described above (with K_2, the packet sequence number as
nonce and a starting block counter of 1).
Detection of an invalid MAC MUST lead to immediate connection termination.
To send a packet, first encode the 3 byte length and encrypt it using K_1 as
described above. Encrypt the packet payload (using K_2) and append it to the
encrypted length. Finally, calculate a MAC tag and append it.
The initiating peer MUST use <code>K_1_A, K_2_A</code> to encrypt messages on
the send channel, <code>K_1_B, K_2_B</code> MUST be used to decrypt messages on
the receive channel.
The responding peer MUST use <code>K_1_A, K_2_A</code> to decrypt messages on
the receive channel, <code>K_1_B, K_2_B</code> MUST be used to encrypt messages
on the send channel.
Optimized implementations of ChaCha20-Poly1305 at bitcoin are relatively fast in
general, therefore it is very likely that encrypted messages require not more
CPU cycles per bytes then the current unencrypted p2p message format
(ChaCha20/Poly1305 versus double SHA256).
The initial packet sequence numbers are 0.
K_2 ChaCha20 cipher instance (payload) must never reuse a {key, nonce} for
encryption nor may it be used to encrypt more than 2^70 bytes under the same
{key, nonce}.
K_1 ChaCha20 cipher instance (length field/AAD) must never reuse a {key, nonce,
position-in-keystream} for encryption nor may it be used to encrypt more than
2^70 bytes under the same {key, nonce}.
We use message sequence numbers for both communication directions.
<pre>
------------------------------------------------------------------------------------------
| Initiator Responder |
| |
| AEAD() = ChaCha20Poly1305Bitcoin() |
| MSG_A_CIPH = AEAD(k=K_1_A, K_2_A, payload_nonce=0, aad_nonce=0, aad_pos=0, msg) |
| |
| --- MSG_CIPH ---> |
| |
| msg := AEAD(k=K_1_A,K_2_A, n=0, ..., MSG_A_CIPH) |
| |
------------------------------------------------------------------------------------------
</pre>
==== Test Vectors ====
<pre>
message 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k1 (DATA) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k2 (AAD) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AAD keystream
76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28 bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7 da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37 6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86
ciphertext
76 b8 e0 9f 07 e7 be 55 51 38 7a 98 ba 97 7c 73 2d 08 0d cb 0f 29 a0 48 e3 65 69 12 c6 53 3e 32
MAC
d2 fc 11 82 9c 1b 6c 1d f1 f5 51 cd 61 31 ff 08
</pre>
<pre>
message 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k1 (DATA) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k2 (AAD) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AAD keystream
76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28 bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7 da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37 6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86
ciphertext
77 b8 e0 9f 07 e7 be 55 51 38 7a 98 ba 97 7c 73 2d 08 0d cb 0f 29 a0 48 e3 65 69 12 c6 53 3e 32
MAC
ba f0 c8 5b 6d ff 86 02 b0 6c f5 2a 6a ef c6 2e
</pre>
<pre>
message
ff 00 00 f1 95 e6 69 82 10 5f fb 64 0b b7 75 7f 57 9d a3 16 02 fc 93 ec 01 ac 56 f8 5a c3 c1 34 a4 54 7b 73 3b 46 41 30 42 c9 44 00 49 17 69 05 d3 be 59 ea 1c 53 f1 59 16 15 5c 2b e8 24 1a 38 00 8b 9a 26 bc 35 94 1e 24 44 17 7c 8a de 66 89 de 95 26 49 86 d9 58 89 fb 60 e8 46 29 c9 bd 9a 5a cb 1c c1 18 be 56 3e b9 b3 a4 a4 72 f8 2e 09 a7 e7 78 49 2b 56 2e f7 13 0e 88 df e0 31 c7 9d b9 d4 f7 c7 a8 99 15 1b 9a 47 50 32 b6 3f c3 85 24 5f e0 54 e3 dd 5a 97 a5 f5 76 fe 06 40 25 d3 ce 04 2c 56 6a b2 c5 07 b1 38 db 85 3e 3d 69 59 66 09 96 54 6c c9 c4 a6 ea fd c7 77 c0 40 d7 0e af 46 f7 6d ad 39 79 e5 c5 36 0c 33 17 16 6a 1c 89 4c 94 a3 71 87 6a 94 df 76 28 fe 4e aa f2 cc b2 7d 5a aa e0 ad 7a d0 f9 d4 b6 ad 3b 54 09 87 46 d4 52 4d 38 40 7a 6d eb 3a b7 8f ab 78 c9
k1 (DATA) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
k2 (AAD) ff 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
AAD keystream
c6 40 c1 71 1e 3e e9 04 ac 35 c5 7a b9 79 1c 8a 1c 40 86 03 a9 0b 77 a8 3b 54 f6 c8 44 cb 4b 06 d9 4e 7f c6 c8 00 e1 65 ac d6 61 47 e8 0e c4 5a 56 7f 6c e6 6d 05 ec 0c ae 67 9d ce eb 89 00 17
ciphertext
39 40 c1 e9 2d a4 58 2f f6 f9 2a 77 6a eb 14 d0 14 d3 84 ee b3 0f 66 0d ac f7 0a 14 a2 3f d3 1e 91 21 27 01 33 4e 2c e1 ac f5 19 9d c8 4f 4d 61 dd be 65 71 bc a5 af 87 4b 4c 92 26 c2 6e 65 09 95 d1 57 64 4e 18 48 b9 6e d6 c2 10 2d 54 89 a0 50 e7 1d 29 a5 a6 6e ce 11 de 5f b5 c9 55 8d 54 da 28 fe 45 b0 bc 4d b4 e5 b8 80 30 bf c4 a3 52 b4 b7 06 8e cc f6 56 ba e7 ad 6a 35 61 53 15 fc 7c 49 d4 20 03 88 d5 ec a6 7c 2e 82 2e 06 93 36 c6 9b 40 db 67 e0 f3 c8 12 09 c5 0f 32 16 a4 b8 9f b3 ae 1b 98 4b 78 51 a2 ec 6f 68 ab 12 b1 01 ab 12 0e 1e a7 31 3b b9 3b 5a 0f 71 18 5c 7f ea 01 7d db 92 76 98 61 c2 9d ba 4f bc 43 22 80 d5 df f2 1b 36 d1 c4 c7 90 12 8b 22 69 99 50 bb 18 bf 74 c4 48 cd fe 54 7d 8e d4 f6 57 d8 00 5f dc 0c d7 a0 50 c2 d4 60 50 a4 4c 43 76 35 58 58
MAC
98 1f be 8b 18 42 88 27 6e 7a 93 ea bc 89 9c 4a
</pre>
=== v2 Messages Structure ===
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 3 || length & flag || 23 + 1 bits || Encrypted length of ciphertext payload (not counting the MAC tag) in number of bytes (only 2^23 is usable, most significant bit is the rekey-flag)
|-
| 1-13 || encrypted command || variable || ASCII command (or one byte short command ID)
|-
| ? || encrypted payload || ? || The actual data
|-
| 16 || MAC tag || ? || 128bit MAC-tag
|}
Encrypted messages do not have the 4byte network magic.
The maximum message size is 2^23 (8’388’608) bytes. Future communication MAY
exceed this limit and thus MUST be split into different messages.
Decrypting and processing the message before the authentication succeeds (MAC
verified) MUST not be done.
The 4byte sha256 checksum is no longer required because the AEAD (MAC).
Both peers MUST keep track of the message sequence number (uint32) of sent and
received messages for building a 64-bit symmetric cipher IV.
The command field MUST start with a byte that defines the length of the ASCII
command string up to 12 chars (1 to 12) or a short command ID (see below).
==== 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. A peer conforming to this proposal MUST support short IDs
based on the table below and SHOULD use short command IDs for outgoing messages.
{|class="wikitable"
! Number !! Command
|-
| 13 || INV
|-
| 14 || HEADERS
|-
| 15 || PING
|-
| 16 || PONG
|-
|}
==== Length comparisons between v1 and v2 messages ====
<pre>
v1 in: 4(Magic)+12(Command)+4(MessageSize)+4(Checksum)+36(Payload) == 60
v2 inv: 3(MessageSize&Flag)+1(Command)+36(Payload)+16(MAC) == 56
(93.33%)
</pre>
<pre>
v1 ping: 4(Magic)+12(Command)+4(MessageSize)+4(Checksum)+8(Payload) == 32
v2 pong: 3(MessageSize&Flag)+1(Command)+8(Payload)+16(MAC) == 28
(87.5%)
</pre>
<pre>
v1 block: 4(Magic)+12(Command)+4(MessageSize)+4(Checksum)+1’048’576(Payload) = 1’048’600
v2 block: 3(MessageSize&Flag)+6(CommandStr)+8(Payload)+16(MAC) == 28 = 1’048’601
(100.000095%)
</pre>
=== Re-Keying ===
Re-keying can be signaled by setting the most significant bit in the length
field before encryption. A peer signaling a rekey MUST use the next key for
encryption messages AFTER the message where the signaling has been done.
A peer identifying a rekey by checking the most significant bit in the envelope
length must use the next key for decrypt messages AFTER the message where the
signaling has been detected.
The next symmetric cipher key MUST be calculated by <code>SHA256(SHA256(session
ID || old_symmetric_cipher_key))</code> and the packet sequence number of the
according encryption direction must be set to 0.
Re-Keying interval is a peer policy with a minimum timespan of 10 seconds.
The Re-Keying must be done after every 1GB of data sent (recommended by RFC4253
SSH Transport) or if the last rekey was more than an hour ago.
Peers calculate the counterparty limits and MUST disconnect immediately if a
violation of the limits has been detected.
=== Risks ===
The encryption does not include an authentication scheme. This BIP does not
cover a proposal to avoid MITM attacks during the encryption initialization.
However, peers MUST show the session-id to the user on request which allows to
identify a MITM by a manual verification on a secure channel.
Optional authentication schemes may be covered by other proposals <ref
name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
BIP150]</ref>.
An attacker could delay or halt v2 protocol enforcement by providing a
reasonable amount of peers not supporting the v2 protocol.
== Compatibility ==
This proposal is backward compatible (as long as not enforced). Non-supporting
peers can still use unencrypted communications.
== Reference implementation ==
* Complete Bitcoin Core implementation: https://github.com/bitcoin/bitcoin/pull/14032
* Reference implementation of the AEAD in C: https://github.com/jonasschnelli/chacha20poly1305
== References ==
<references/>
== Acknowledgements ==
* Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.
* Tim Ruffing for the review and the hint for the enhancement of the symmetric
key derivation
== Copyright ==
This work is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190322/307267fd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190322/307267fd/attachment-0001.sig>

2023-06-07 18:14:34

- reply

📅 Original date posted:2018-09-07
📝 Original message: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 at 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 at 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 at openssh ("a nonce consisting of the packet sequence number encoded as a uint64“).
But I’ll specified that more clear.
> - What if the uint32 overflows?
The max data before rekey is 1GB, AFAIK it is impossible to overflow.
> - "Re-Keying interval is a peer policy with a minimum timespan of 10 seconds." What if I receive
> too many re-keying requests? Nothing or should I raise the DoS score?
Current implementation proposal does a disconnect. With the risk of fingerprinting options, I think we can leave this open to the implementation?
> - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its
> own sending key, so this should just read "sent" instead of "sent or received“?
Yes. Should probably be „sent“,… and eventually a paragraph that states that a peer should disconnect if the remote peer did not rekey within that limit.
> Pseudocode could probably help here.
Agree. Will try to add.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180907/348e23e8/attachment.sig>

2023-06-07 18:14:32

- reply

📅 Original date posted:2018-09-03
📝 Original message: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 at openssh
========================================
The proposed AEAD could eventually be further optimized.
ChaCha20Poly1305 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180903/82a75538/attachment-0001.sig>

2023-06-07 18:14:14

- reply

📅 Original date posted:2018-08-29
📝 Original message:> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180829/f991e201/attachment.sig>

2023-06-07 18:14:13

- reply

📅 Original date posted:2018-08-28
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180828/15fc887c/attachment.sig>

2023-06-07 18:13:11

- reply

📅 Original date posted:2018-06-25
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180625/88470c4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180625/88470c4c/attachment.sig>

2023-06-07 18:13:04

- reply

📅 Original date posted:2018-06-19
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/c263f67b/attachment.sig>

2023-06-07 18:13:03

- reply

📅 Original date posted:2018-06-19
📝 Original message:> * 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/e76fa257/attachment-0001.sig>

2023-06-07 18:12:47

- reply

📅 Original date posted:2018-06-03
📝 Original message:> 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):
xp1qqqqqq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgnvv4zgnvv4zgnvv4zgngn
(140 chars)
Versus the bech32 (6 char checksum):
xp1qqqqqq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgn
(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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/2669b658/attachment.sig>

2023-06-07 18:12:47

- reply

📅 Original date posted:2018-06-03
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/32ff5291/attachment.sig>

2023-06-07 18:12:32

- reply

📅 Original date posted:2018-05-30
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180530/ff430ac7/attachment.sig>

2023-06-07 18:12:30

- reply

📅 Original date posted:2018-05-29
📝 Original message: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 for key material with the size of 512, 520 bits.
If the script type restriction is set, the according extended key must only be
used to derive addresses with the selected script type.
This does not stands in contradiction to derivation path proposals ([4]). It
does allow to derive and encode an extended key at a keypath where users assume
restricted script types in derivation due to other supported proposals.
Encoding
########
Bech32 must be used as encoding format (see the Bech32 rational [5]). Encoding
545 or 553 bits (results in 109 resp. 111 x 5 bits) will exceed the Bech32 property of a
guaranteed detection of 4 errors (only 3 are).
It is possible that there are more efficient BCH codes, especially for encoding
extended private keys. Since a Bech32 implementation needs to be present in
modern Bitcoin software, re-using Bech32 will allow to migrate to this proposal
with a minimal implementation effort.
Forensic, cpu-intense key-recovery (including brute-force techniques) may allow
to recover keys beyond the guaranteed error detection limits.
Bech32 HRPs
Mainnet Private Extended: xp
Mainnet Public Extended: xpu
Testnet Private Extended: tp
Testnet Public Extended: tpu
Mainnet Key: pk-
Testnet Key: tk-
Compatibility
###########
Only new software will be able to use these serialization and encoding format.
References
##########
[1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>
[2] https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki
[4] https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki
[5] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#rationale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180529/d2332b98/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180529/d2332b98/attachment.sig>

2023-06-07 18:12:10

- reply

📅 Original date posted:2018-05-17
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180517/6053a286/attachment-0001.sig>

2023-06-07 18:11:38

- reply

📅 Original date posted:2018-04-13
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180413/1dd52b17/attachment.sig>

2023-06-07 18:10:34

- reply

📅 Original date posted:2018-02-08
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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 wallet connected to
> your own full node. People who make use of Blockstream Satellite could
> use it to have an off-the-grid node connected to Electrum if that is
> their preferred wallet. In the situation of a traveller staying a cheap
> hostels, they could sync their node every couple of days to download
> recent blocks and use Electrum. Hopefully this software can be part of
> the plan to get full node wallets into the hands of as many people as
> possible.
>
> The same kind of ideas could be applied to other lightweight wallets.
> For example a full nodes can run on smartphones with pruning and
> blocksonly, then a similar script would allow the user to connect their
> Samourai Wallet, Breadwallet or GreenAddress app to their own full node.
>
>
> Further Reading:
>
> * https://bitcointalk.org/index.php?topic=2664747.msg27179198
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
> * https://bitcointalk.org/index.php?topic=1634967.0;all
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180209/c4c58f3c/attachment.sig>

2023-06-07 18:07:55

- reply

📅 Original date posted:2017-11-27
📝 Original message: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
—
</jonas>
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011692.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011692.html>
[2] https://github.com/bitcoin/bitcoin/pull/6973 <https://github.com/bitcoin/bitcoin/pull/6973>
> Am 26.11.2017 um 16:11 schrieb Jeff Johnson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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 <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 <https://mega.nz/#!YPIF2KTa!4FxxLvqzjqIftrkhXwSC2h4G4Dolk8dLteNUolEtq98>
>
> Thanks for reading, best wishes to all.
>
> -- Jeff Johnson
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171127/59a99830/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171127/59a99830/attachment.sig>

2023-06-07 18:07:53

- reply

📅 Original date posted:2017-11-21
📝 Original message: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]
—
</jonas>
[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 <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171121/31852331/attachment-0001.sig>

2023-06-07 18:06:41

- reply

📅 Original date posted:2017-09-30
📝 Original message:> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/4a7078c9/attachment.sig>

2023-06-07 18:06:41

- reply

📅 Original date posted:2017-09-30
📝 Original message:>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170930/c2a58417/attachment.sig>

2023-06-07 18:05:33

- reply

📅 Original date posted:2017-09-07
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org>:
>
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/01c4fef5/attachment.sig>

2023-06-07 18:04:46

- reply

📅 Original date posted:2017-08-13
📝 Original message: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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170813/dec1b7a3/attachment.sig>

2023-06-07 18:04:44

- reply

📅 Original date posted:2017-08-09
📝 Original message: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).
</jonas>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170809/12ef5842/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170809/12ef5842/attachment.sig>

2023-06-07 18:04:05

- reply

📅 Original date posted:2017-07-12
📝 Original message:> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/29aea872/attachment.sig>

2023-06-07 18:03:06

- reply

📅 Original date posted:2017-06-11
📝 Original message:Hi José
> a) Canonical Pointers
> The basic proposal.They look like this example: btc at 170.1/179-631-520
> Here is a link to the Google Docs document -> https://docs.google.com/document/d/1PBN4wKFYtgvDxV4DrWUdNe9Xqmb8GVxoIGDKRkY9Xr4/edit?usp=sharing <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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170611/80f97aa2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170611/80f97aa2/attachment-0001.sig>

2023-06-07 18:02:13

- reply

📅 Original date posted:2017-06-19
📝 Original message:> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/a2dd2bbf/attachment.sig>

2023-06-07 18:02:12

- reply

📅 Original date posted:2017-06-19
📝 Original message:>>
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/beccad65/attachment.sig>

2023-06-07 18:02:11

- reply

📅 Original date posted:2017-06-19
📝 Original message:>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/fda0aec0/attachment-0001.sig>

2023-06-07 18:02:10

- reply

📅 Original date posted:2017-06-19
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/d413208e/attachment.sig>

2023-06-07 18:01:05

- reply

📅 Original date posted:2017-05-11
📝 Original message:> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/96f3a942/attachment.sig>

2023-06-07 18:01:04

- reply

📅 Original date posted:2017-05-11
📝 Original message: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 <https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT>
Feedback is highly welcome.
</jonas>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/f520ab16/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/f520ab16/attachment.sig>

2023-06-07 18:00:23

- reply

📅 Original date posted:2017-04-18
📝 Original message: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?
</jonas>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/9cf44da5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/9cf44da5/attachment.sig>

2023-06-07 17:57:02

- reply

📅 Original date posted:2017-03-08
📝 Original message: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?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170308/42405465/attachment.sig>

2023-06-07 17:56:59

- reply

📅 Original date posted:2017-03-08
📝 Original message:> Am 08.03.2017 um 22:09 schrieb Eric Voskuil <eric at voskuil.org>:
>
> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170308/c29e775d/attachment.sig>

2023-06-07 17:56:59

- reply

📅 Original date posted:2017-03-08
📝 Original message:>
>>
>> > 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.**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170308/a20244e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170308/a20244e4/attachment.sig>

2023-06-07 17:56:53

- reply

📅 Original date posted:2017-03-06
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170306/ec223a69/attachment.sig>

2023-06-07 17:56:23

- reply

📅 Original date posted:2017-02-14
📝 Original message:>> - 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)?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170214/1e198586/attachment-0001.sig>

2023-06-07 17:56:23

- reply

📅 Original date posted:2017-02-14
📝 Original message: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 <ip>“, or
„iptables-DROP <ip>“?
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 trusted connection also allows to fallback
anytime to non-trusted nodes (if your trusted node is no longer
reachable). If your SPV peer needs to catch up a couple of hours while
your trusted peer was done, fine, download full blocks or change your
bloom filters FP rate significant (or sacrifices your privacy in this case).
</jonas>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170214/8559c0c1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170214/8559c0c1/attachment-0001.sig>

2023-06-07 17:56:21

- reply

📅 Original date posted:2017-02-14
📝 Original message:>> 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?
> There is no reason to treat invalid messages differently based on where
> they occur in the communication. After the handshake the agreed version
> is known to both peers. As a result there is never a reason for an
> invalid message to be sent. Therefore it is always proper to drop a peer
> that sends an invalid message.
That's up to the implementation. But the current flexibility exists
because we not drop.
Again, see above.
>> I can't see that a such spec. would reduce the DOS attack vector?
> This was previously addressed (immediately below).
No. I'd like to hear from you why the DOS attack vector would be larger
if the encryption neg. would be after the version handshake.
>
>>>>> 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.
> Yes, this is the purpose of version negotiation, which is why there are
> version and verack messages. And this is also why, in the satoshi
> client, two of the above messages are sent from the verack handler. The
> feefilter message is sent dynamically but only if the peer's version
> allows it.
Again. Encryption – for the sake of security – must be the first
interaction.
This is exceptional for BIP151 and I'd like to hear the real downsides
of doing that.
>
>> You can't link a (unimplemented) specification (improvement process) to
>> a protocol version before deployment. Or can you?
> I'm not sure I follow your question. The BIP should presumably declare a
> version number if one is necessary.
What? You want to define protocol version number in draft improvement
specifications?
How should that be possible?
It's like defining a new HTML version number if you propose/draft a new
video streaming format.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170214/0b660431/attachment.sig>

2023-06-07 17:56:20

- reply

📅 Original date posted:2017-02-13
📝 Original message:>> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170213/ec9da1fb/attachment-0001.sig>

2023-06-07 17:56:18

- reply

📅 Original date posted:2017-02-13
📝 Original message:> 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?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170213/310f938e/attachment.sig>

2023-06-07 17:55:22

- reply

📅 Original date posted:2017-01-07
📝 Original message: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
</jonas>
> Bitcoin Classic version 1.2.0 is now available from;
>
> <https://bitcoinclassic.com/gettingstarted.html>
>
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170107/c17797bd/attachment.sig>

2023-06-07 17:55:07

- reply

📅 Original date posted:2017-01-04
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170104/76132d83/attachment.sig>

2023-06-07 17:55:03

- reply

📅 Original date posted:2017-01-01
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170101/91d3f504/attachment.sig>

2023-06-07 17:53:29

- reply

📅 Original date posted:2016-09-22
📝 Original message:Hi Tom
> I think you misunderstand tagged systems at a very basic level. You think
> that html can only use a bold tag <b> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160922/70a1092a/attachment-0001.sig>

2023-06-07 17:53:05

- reply

📅 Original date posted:2016-08-25
📝 Original message:> The development paradigm of "maybe detect funds" is not something we
> should *not* encourage for Bitcoin IMO.
Sorry. That was one "not" to many.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/3a663553/attachment.sig>

2023-06-07 17:53:04

- reply

📅 Original date posted:2016-08-25
📝 Original message:> 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 <address-birthday>+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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/500f4db6/attachment.sig>

2023-06-07 17:53:04

- reply

📅 Original date posted:2016-08-25
📝 Original message: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 <address-birthday>+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?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/b7df9cb6/attachment.sig>

2023-06-07 17:53:03

- reply

📅 Original date posted:2016-08-24
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/c679a7ea/attachment.sig>

2023-06-07 17:53:01

- reply

📅 Original date posted:2016-08-24
📝 Original message:>> 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<networkservice_flags_filter_as_int>.seed.bitcoin....
Example for NODE_NETWORK together with NODE_BLOOM
dig x5.seed.bitcoin.jonasschnelli.ch
(NETWORK = (1 << 0), NODE_BLOOM = (1 << 2)) = (bin00000101 = (int)5)
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/c7311f2b/attachment.sig>

2023-06-07 17:52:52

- reply

📅 Original date posted:2016-08-18
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/343d9d28/attachment.sig>

2023-06-07 17:52:51

- reply

📅 Original date posted:2016-08-18
📝 Original message: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?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/ca1a24d9/attachment.sig>

2023-06-07 17:52:50

- reply

📅 Original date posted:2016-08-17
📝 Original message: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 waaaaay 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/3eea9613/attachment-0001.sig>

2023-06-07 17:52:50

- reply

📅 Original date posted:2016-08-18
📝 Original message: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
--
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/5ae29972/attachment.sig>

2023-06-07 17:52:49

- reply

📅 Original date posted:2016-08-17
📝 Original message: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
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/63e4d8a4/attachment-0001.sig>

2023-06-07 17:52:47

- reply

📅 Original date posted:2016-08-16
📝 Original message:> 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).
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/75ee098a/attachment.sig>

2023-06-07 17:52:46

- reply

📅 Original date posted:2016-08-16
📝 Original message: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
</jonas>
---- BIP (rough early stage draft)
<pre>
BIP: ???
Title: Detached Signing
Author: Jonas Schnelli <dev at jonasschnelli.ch>
Status: Draft (early stage!)
Type: Standards Track
Created: 2016-08-02
</pre>
== 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.
<code>detatchedsigning://<command>?<querystring>&returnurischeme=<returnurischeme://></code>
The <code>querystring</code> 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 <code>returnurischeme</code> 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:
<code>detatchedsigning://sign?type=<bitcoin-p2pkh|bitcoin-p2sh|bitcoin-msg>&data=<raw-transaction|message>&inputscripts=<scriptPubKey-input0>,<scriptPubKey-input1>,...&inputhdkeypath=<hdkeypath0>,<hdkeypath1>,...&returnscheme=<returnurischeme></code>
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-keypath of the inputs in exact order
(optional)returnscheme = a URI scheme where the response must be sent to
(smartphone approach)
* inputhdkeypath or inputscripts must be provided.
=== Signing Response ===
The signing response is a flexible URI-Query-String that will be sent
back to the wallet application and must contain the signatures or an
error code.
The URI-query-string can be opened (smartphone approach) or will be sent
back though the interprocess pipe.
<code><returnurischeme>://signresponse?errorcode=<errorcode>&signatures=<signature-input0>,<signature-input0>,...</code>
In case of ECDSA, the returned signatures must be normalized compact
signatures with the size of 64bytes (128 hex chars).
==== Possible error code ====
0 = no error
1 = user canceled
2 = timeout
10 = missing key identifier (missing HD keypath or input scriptpubkey)
11 = unsupported signing type
12 = could not resolve script
50 = unknown internal error
==== Examples ====
===== Simple p2pkh transaction =====
Unsigned raw transaction:
<code>0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388ac00000000</code>
(input ced97f90d7d10a767dfd2bed769ac42cc48be1d3e648f1bfb5dbb70f9dd13cfd
vout:1, output: P2PKH mtgQ54Uf3iRTc9kq18rw9SJznngvF5ryZn 1 BTC)
signing-request URI must be:
<code>detatchedsigning://sign?type=bitcoin-p2pkh&data=0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388ac00000000&inputscripts=76a914531148ad17fdbffd4bac72d43deea6c7cf0387d088ac&inputhdkeypath=m/0'/0'/1&returnscheme=myapp</code>
The <code>inputhdkeypath</code> is optional in this case
signing-response URI must be:
<code>detatchedsigning://signresponse?error=0&signatures=<128hex-chars></code>
===== Simple a bitcoin message =====
Message: <code>Lorem ipsum dolor sit amet</code>
signing-request URI must be:
<code>detatchedsigning://sign?type=bitcoinmsg&data=Lorem+ipsum+dolor+sit+amet&inputhdkeypath=m/0'/0'/2</code>
signing-response URI must be:
<code>detatchedsigning://signresponse?error=0&signatures=<128hex-chars></code>
=== Support for multiple signing-devices ===
Must operating systems allow only one registered application per
URI-scheme. To support multiple signing-devices, wallets and
signing-devices can optional add support for brand based URI-schemes.
In addition to the standard URI scheme,
signing-devices-controller-applications can register an additional URI
scheme (with the identical request/response syntax and logic) including
a brand-identifier.
Registering a brand-identifier based URI scheme without registering the
default URI scheme is not allowed.
Wallets can detect if a certain brand based URI scheme is supported and
therefore gives user a selection if multiple signing-devices where
detected [4][5].
<code>detatchedsigning<brandid>://</code>
Supported brand-identifiers are:
* trezor
* ledger
* keepkey
* digitalbitbix
== References ==
[1] https://github.com/spesmilo/electrum/pull/1662
[2] https://github.com/spesmilo/electrum/pull/1391
[3] https://github.com/bitpay/copay/pull/3143
[4]
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/
[5]
https://developer.android.com/reference/android/content/pm/PackageManager.html
== Acknowledgements ==
== Copyright ==
This work is placed in the public domain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/fe4471a9/attachment.sig>

2023-06-07 17:52:22

- reply

📅 Original date posted:2016-08-09
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/2de7eeaa/attachment.sig>

2023-06-07 17:52:22

- reply

📅 Original date posted:2016-08-12
📝 Original message:> 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
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160812/c8a0c3c3/attachment.sig>

2023-06-07 17:52:20

- reply

📅 Original date posted:2016-08-08
📝 Original message: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 <dev at jonasschnelli.ch>
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-key, the signature must contain 64bytes of
zeros.
The requesting peer can check the responding peers identity by checking
the validity of the sent signature against with the pre-shared remote
peers identity-public-key.
If the signature was invalid, the requesting peer must still proceed
with the authentication by sending an `AUTHPROPOSE`-message with 32
random bytes.
=== `AUTHPROPOSE` message ===
A peer can propose authentication of the channel by sending an
`AUTHPROPOSE`-message to the remote peer.
If the signature sent in `AUTHREPLY` was invalid, the peer must still
send an `AUTHPROPOSE`-message containing 32 random bytes.
The `AUTHPROPOSE` message must be answered with an
`AUTHCHALLENGE`-message – even if the proposed requesting-peers
identity-public-key has not been found in the authorized_peers database.
In case of no match, the responding `AUTHCHALLENGE`-message must
contains 32 bytes of zeros.
| 32bytes || auth-propose-hash || hash || `hash(encryption-session-ID
== Post-Authentication Re-Keying ==
After the second `AUTHREPLY` message (requesting peers signature ->
responding peer), both clients must re-key the symmetric encryption
according to BIP151 while using ___a slightly different re-key key
derivation hash___.
They both re-key with `hash(encryption-session-ID ||
old_symmetric_cipher_key || requesting-peer-identity-public-key ||
responding-peer-identity-public-key)`
== Identity-Addresses ==
The peers should display/log the identity-public-key as an
identity-address to the users, which is a base58-check encoded
ripemd160(sha256) hash. The purpose of this is for better visual
comparison (logs, accept-dialogs).
The base58check identity byte is `0x0F` followed by an identity-address
version number (=`0xFF01`).
An identity address would look like
`TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA` and can be interpreted as a remote
peers fingerprint.
== Compatibility ==
This proposal is backward compatible. Non-supporting peers will ignore
the new `AUTH*` messages.
== Example of an auth interaction ==
Before authentication (once during peer setup or upgrade)
# Requesting peer and responding peer create each an identity-keypair
(standard ECC priv/pubkey)
# Requesting and responding peer share the identity-public-key over a
different channel (PGP mail, physical exchange, etc.)
# Responding peer stores requesting peers identity-public-key in its
authorized-peers database (A)
# Requesting peer stores responding peers identity-public-key in its
known-peers database together with its IP and port (B)
Encryption
# Encrypted channels must be established (according to BIP-151 [1])
Authentication
# Requesting peer sends an `AUTHCHALLENGE` message
AUTHCHALLENGE:
[32 bytes, hash(encryption-session-ID || "i" ||
<remote-peers-expected-identity-public-key>)]
# Responding peer does create the same hash `(encryption-session-ID ||
"i" || <remote-peers-expected-identity-public-key>)` with its local
identity-public-key
# If the hash does not match, response with an `AUTHREPLY` message
containing 64bytes of zeros.
# In case of a match, response with an `AUTHREPLY` message
AUTHREPLY:
[64 bytes normalized compact ECDSA signature (H)] (sig of the
encryption-session-ID done with the identity-key)
# Requesting peer does verify the signature with the
`remote-peers-identity-public-key`
# If the signature is invalid, requesting peer answers with an
`AUTHREPLY` message containing 32 random bytes
# In case of a valid signature, requesting peer sends an `AUTHPROPOSE`
message
AUTHPROPOSE:
[32 bytes, hash(encryption-session-ID || "p" ||
<client-identity-public-key>)]
# Responding peer iterates over authorized-peers database (A), hashes
the identical data and looks for a match.
# If the hash does not match, responding peer answer with an
`AUTHCHALLENGE` message containing 32 bytes of zeros.
# In case of a match, responding peer sends an `AUTHCHALLENGE` message
with the hashed client public-key
AUTHCHALLENGE:
[32 bytes, hash(encryption-session-ID || "r" ||
<client-identity-public-key>)]
# Requesting peer sends an `AUTHREPLY` message containing 64 bytes of
zeros if server failed to authenticate
# Otherwise, response with signature in the `AUTHREPLY` message
AUTHREPLY:
[64 bytes normalized compact ECDSA signature (H)] (sig of the
encryption-session-ID done with the identity-key)
# Responding peer must verify the signature and can grant access to
restricted services.
# Both peers re-key the encryption after BIP151 including the
requesting-peer-identity-public-key and responding-peer-identity-public-key
== Disadvantages ==
The protocol may be slow if a peer has a large authorized-peers database
due to the requirement of iterating and hashing over all available
authorized peers identity-public-keys.
== Reference implementation ==
== References ==
* [1] [[bip-0151.mediawiki|BIP 151: Peer-to-Peer Communication Encryption]]
== Acknowledgements ==
* Gregory Maxwell and Pieter Wuille for most of the ideas in this BIP.
== Copyright ==
This work is placed in the public domain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/e83bc378/attachment-0001.sig>

2023-06-07 17:52:03

- reply

📅 Original date posted:2016-07-27
📝 Original message:> 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).
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160727/9022ee3f/attachment.sig>

2023-06-07 17:52:02

- reply

📅 Original date posted:2016-07-26
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160726/d070c20b/attachment.sig>

2023-06-07 17:51:52

- reply

📅 Original date posted:2016-07-04
📝 Original message:> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160704/029dc8b2/attachment.sig>

2023-06-07 17:51:51

- reply

📅 Original date posted:2016-07-04
📝 Original message: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 at openssh.
Both very well known and broad used crypo.
/jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160704/97fb8245/attachment.sig>

2023-06-07 17:51:49

- reply

📅 Original date posted:2016-06-28
📝 Original message: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
---
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/404f4808/attachment.sig>

2023-06-07 17:51:43

- reply

📅 Original date posted:2016-06-30
📝 Original message:>>> 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 :-)
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160630/0920253c/attachment.sig>

2023-06-07 17:51:43

- reply

📅 Original date posted:2016-06-30
📝 Original message:> 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?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160630/ddefb09d/attachment.sig>

2023-06-07 17:51:40

- reply

📅 Original date posted:2016-06-28
📝 Original message:>> 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 at 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 to implement) encryption alone.
I think BIP151 does what it says: encryption and laying groundwork for
authentication.
You wouldn't probably say BIP32 is incomplete because it does not cover
a scheme how to recover funds (or BIP141 [SW consensus] is incomplete
because it does not cover p2p [BIP144]).
The missing MITM protection (solvable over auth) is prominent mentioned
in the BIP [1].
(from your other mail):
>> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?
>
> TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.
> The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.
I agree that the secure trusted 2nd channel key-sharing problem can be
significant for large networks and/or connecting to unknown identities.
But as said, there could be multiple ways of sharing identity keys.
If you want to connect your node to serval other trusted nodes, you can
simply physically preshare keys or do it over GPG / Signal App, etc..
And if I have followed the news correctly, there are some clever guys
working on various internet of trust 2.0 proposals...
>>
>> BIP151 does not rely on identities. BIP151 does not use persisted keys
>> (only ephemeral keys).
>
> BIP 151 is incomplete without authentication.
I would agree if you would say, _trusted encryption_ is incomplete with
authentication. But IMO BIP151 is complete and should be deployed
together with one or multiple authentication schemes.
[1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/3748c989/attachment.sig>

2023-06-07 17:51:36

- reply

📅 Original date posted:2016-06-28
📝 Original message: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.
---
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/4b67008b/attachment.sig>

2023-06-07 17:51:35

- reply

📅 Original date posted:2016-06-29
📝 Original message: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-poly1305 at 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/47d92fd6/attachment.sig>

2023-06-07 17:51:34

- reply

📅 Original date posted:2016-06-29
📝 Original message:> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/8661e056/attachment.sig>

2023-06-07 17:51:33

- reply

📅 Original date posted:2016-06-28
📝 Original message:> 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.
</jonas>
[1]
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/bbe12795/attachment.sig>

2023-06-07 17:51:33

- reply

📅 Original date posted:2016-06-29
📝 Original message:> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/3c5c25c5/attachment.sig>

2023-06-07 17:51:02

- reply

📅 Original date posted:2016-06-09
📝 Original message:Hi
> On Thu, Jun 09, 2016 at 01:24:09AM +0000, 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
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160609/8f75bb8c/attachment.sig>

2023-06-07 17:50:52

- reply

📅 Original date posted:2016-05-25
📝 Original message:>> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160525/3aed6567/attachment.sig>

2023-06-07 17:50:51

- reply

📅 Original date posted:2016-05-18
📝 Original message: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.
>> <code>K_1</code> must be used to only encrypt the payload size of the
>> encrypted message to avoid leaking information by revealing the
>> message size.
>>
>> <code>K_2</code> 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-poly1305 at 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-poly1305 at 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 <code>encinit</code>/<code>encack</code>
>> 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 <code>encack</code> message containing 33byte of zeros to
>> indicate that all encrypted message following after this
>> <code>encack</code> message will be encrypted with ''the next
>> symmetric cipher key''.
>>
>> The new symmetric cipher key will be calculated by
>> <code>SHA256(SHA256(old_symetric_cipher_key))</code>.
>>
>> Re-Keying interval is a peer policy with a minimum timespan of 600
>> seconds.
>
> Should the int64_t message count be reset to 0 on a re-key? Or should
> the value reset to zero after 2^63-1? Hopefully the peer re-keys before
> that rollover, or keystream reusage will occur. Unlikely that many
> messages are sent on a single connection though. And presumably this
> only re-keys the senders side? Bi-directional re-keying would be racy.
I just added the RFC4253 recommendation as a must (re-key after every
1GB of data sent or received).
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160518/b974c034/attachment.sig>

2023-06-07 17:50:42

- reply

📅 Original date posted:2016-05-14
📝 Original message:> 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
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160514/22aca5af/attachment.sig>

2023-06-07 17:50:42

- reply

📅 Original date posted:2016-05-14
📝 Original message: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.
--
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160514/fb88c8d0/attachment.sig>

2023-06-07 17:50:05

- reply

📅 Original date posted:2016-04-01
📝 Original message:> 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).
---
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160401/39552c3c/attachment.sig>

2023-06-07 17:50:01

- reply

📅 Original date posted:2016-03-25
📝 Original message:> 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 <code>auth</code> 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 > <code>enc*</code> messages.
Current p2p implementation ignores any unknown command.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160325/79ef629f/attachment.sig>

2023-06-07 17:49:58

- reply

📅 Original date posted:2016-03-26
📝 Original message:> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160326/6b17032b/attachment.sig>

2023-06-07 17:49:58

- reply

📅 Original date posted:2016-03-27
📝 Original message:> 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.])
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160327/0d52fd3e/attachment.sig>

2023-06-07 17:49:57

- reply

📅 Original date posted:2016-03-25
📝 Original message: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 <code>enc</code> message (leaving out
>>> the hash itself) must be added to the hash-context by both parties.
>>> Before sending a <code>enc</code> 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 <n> plaintext p2p
messages _after_ decrypting. The plaintext messages have a much simpler
header (removed the 4 bytes sha256 checksum, removed the 4byte network)
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160325/438b2e1f/attachment-0001.sig>

2023-06-07 17:49:56

- reply

📅 Original date posted:2016-03-23
📝 Original message:>> 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 <code>enc</code> message (leaving out the hash itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> 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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160323/3dd53763/attachment-0001.sig>

2023-06-07 17:49:55

- reply

📅 Original date posted:2016-03-23
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160323/0c31649c/attachment.sig>

2023-06-07 17:49:40

- reply

📅 Original date posted:2016-03-03
📝 Original message: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).
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160303/a0e73400/attachment-0001.sig>

2023-06-07 17:49:22

- reply

📅 Original date posted:2016-02-29
📝 Original message:-----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).
- ----------------------
</jonas>
-----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-----

2023-06-07 17:47:58

- reply

📅 Original date posted:2016-01-21
📝 Original message:-----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-----

2023-06-07 17:47:56

- reply

📅 Original date posted:2016-01-25
📝 Original message:-----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.
</jonas>
-----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-----

2023-06-07 17:44:41

- reply

📅 Original date posted:2015-11-13
📝 Original message:-----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-----

2023-06-07 17:44:40

- reply

📅 Original date posted:2015-11-13
📝 Original message:-----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-----

2023-06-07 17:43:52

- reply

📅 Original date posted:2015-10-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Here is the beginnings of an implementation to replace leveldb
> with sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite
>
> It builds, but still needs work before passing tests.
Nice work!
Although not sure if we should focus directly on sqlite4 (could be
optional with a configure flag and a subtree [until stable], sqlite3
supported over depends).
Also i personally would recommend to not implement it as a
replacement, instead, support multiple backends (wrapper header /
different wrapper implementations [leveldb / sqlite3 / sqlite4]). But
– agreed – should not be the focus, but a nice additional flexibility
if it not require much more work.
And – in theory – multiple database back-ends would allow migration.
Before investigating to deep, i think we need a dbwrapper bench tool
that represents our needs and our style how we hit the database.
Gavins recently added bench target / bench environment could be used
for that.
/jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWKdlgAAoJECnUvLZBb1Ps7J8P/2L6215fd0rWGv5uvbLSnQvm
hy1T2AaOfH5HXd2m95icaKYk+ugvQAL80Q/67YwZbPLsT4fErgegw8n75Z6nh/Pc
OJ1EtAvD+Kc/Vm0Wcvt421HXwnm4f+j+8eoEvpG6DdC8gfIG+efhM7DljeNbPFrA
ieNe7XrQ1EZ29lMzpQv0nx3bi6tUHOWuazk82B6vnK49MjH7nrUFipcc18nXbSpM
ZKjQakXmfqIBG8QP9ZUYUlW4aoG0oaOoZnGjQA2LeXBJpIPLpE/WPg0XaXubC+No
232CJNtNyUOmjkb2qbep6vSYgqGJNy1HbCU5y3qooxJhFnKdo63CQsyJKSpL/ssi
0lWraNxjbacxsBn+63In3wEkj02orwm2zTO4I77wCrZmJgpvBFb9bZWTeL8DCYSG
DTkZoKWEK74xvm+dNpEWXK9Lm1ltfyhPdaFeMoRDub4w2uuYlk3KuD8Vdy81HYJb
sak8FbkiWw9xx2OP9+G56Arf9W6mnJ3YHJGrY4SXeRAfuNYwGFHIGt6I1JobuHy4
VWmcHuooz/Q9JLUu3Rr3HsEdXYgCmgmWuzTgWG+Hx92Y6XLWV5pOX+vFRO6J5fSm
aTYPD4GsTM3FROXw5ezlXJ+2y1+ITzmrfm03fEDQvoIyH0TwBqBc5sMBBkma5DDR
0HUthPHWCD+AxbBPbRVa
=CUMX
-----END PGP SIGNATURE-----