[bitcoin-dev] Future Of Bitcoin-Cores Wallet

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi (excuse my english; it’s not my native language) As you might noticed, bitcoin-cores wallet didn’t got that much focus during the last month (even years?). Wallet development has mostly moved towards SPV (bitcoinj), thin clients (Electrum),

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

-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

[bitcoin-dev] Ads on bitcoin.org website

-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

Re: [bitcoin-dev] Announcing Jonas Schnelli as GUI maintainer

-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

Re: [bitcoin-dev] CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Roy > So who physically manually uploads the gitian build to bitcoin.org > ? It's done by the core devs (very likely the project maintainer). I think it doesn't matter who did the upload to bitcoin.org. What really would

Re: [bitcoin-dev] BIP 151 MITM

Hi > On Thu, Jun 09, 2016 at 01:24:09AM +, Gregory Maxwell wrote: >> Reduction to plaintext isn't an interesting attack vector for an active >> attacker: they can simply impersonate the remote side. >> >> This is addressed via authentication, where available, which is done by a >> separate

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

> 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 =

Re: [bitcoin-dev] BIP 151

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

[bitcoin-dev] Fast bootstrapping with a pre-generated UTXO-set database

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

Re: [bitcoin-dev] What is OpenSSL still used for?

-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

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available

-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

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

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

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

> 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

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

> 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

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

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 >

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

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

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

> 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 im

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

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

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

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;

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

> 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

Re: [bitcoin-dev] BIP 151

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

Re: [bitcoin-dev] Authentication BIP

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

Re: [bitcoin-dev] BIP 151

> 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

Re: [bitcoin-dev] BIP 151

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

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

> 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"

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

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,

Re: [bitcoin-dev] BIP 151

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)

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

> 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? >> >> A

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

> 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

Re: [bitcoin-dev] Hardware Wallet Standard

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,

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

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

Re: [bitcoin-dev] BIP151 protocol incompatibility

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

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

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

Re: [bitcoin-dev] BIP151 protocol incompatibility

> 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

Re: [bitcoin-dev] BIP151 protocol incompatibility

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

[bitcoin-dev] Hardware Wallet Standard

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

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

> The development paradigm of "maybe detect funds" is not something we > should *not* encourage for Bitcoin IMO. Sorry. That was one "not" to many. signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list

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

Hi Tom > I think you misunderstand tagged systems at a very basic level. You think > that html can only use a bold tag once in a document? Thats equivalent > to what you are saying. Would the "additional" segment contain the same amount of nSequence-equivalent token as the number of inputs

Re: [bitcoin-dev] Hardware Wallet Standard

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

Re: [bitcoin-dev] Hardware Wallet Standard

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.

Re: [bitcoin-dev] Hardware Wallet Standard

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

Re: [bitcoin-dev] Hardware Wallet Standard

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

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

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

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

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

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

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

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

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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

Hi Tom Please don't post release announcements for software that is incompatible with the current bitcoin consensus rules here. Otherwise we give green-lights to any sorts of altcoin to post their releases here. Thanks > Bitcoin Classic version 1.2.0 is now available from; > >

Re: [bitcoin-dev] Unique node identifiers

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

Re: [bitcoin-dev] Unique node identifiers

> Am 08.03.2017 um 22:09 schrieb Eric Voskuil : > > On 03/08/2017 11:47 AM, Jonas Schnelli wrote: Nodes are by design not supposed to be identifiable in any way >>> >>> This is of course my objection to BIP150 ("a way for peers to ... >>> guarantee node ownership“). >>

Re: [bitcoin-dev] Unique node identifiers (and BIP150)

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

Re: [bitcoin-dev] Currency/exchange rate information API

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

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

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

Re: [bitcoin-dev] Would anyone object to adding a dlopen message hook system?

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

Re: [bitcoin-dev] A Segwit2x BIP

> Code to support 2x (the hard fork part of the proposal) has been out and > tested for much longer than that. Tested? Where? However, the hardfork part may be out there for a long time but _is still broken_. /jonas signature.asc Description: Message signed with OpenPGP

Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options

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

[bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits

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

Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits

> 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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

> 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

Re: [bitcoin-dev] Bitcoin pointers

Hi José > a) Canonical Pointers > The basic proposal.They look like this example: btc@170.1/179-631-520 > Here is a link to the Google Docs document -> > https://docs.google.com/document/d/1PBN4wKFYtgvDxV4DrWUdNe9Xqmb8GVxoIGDKRkY9Xr4/edit?usp=sharing > >

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

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

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

> 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

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

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

Re: [bitcoin-dev] Block compression

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

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

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

Re: [bitcoin-dev] BIP 174 thoughts

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

Re: [bitcoin-dev] New serialization/encoding format for key material

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

[bitcoin-dev] New serialization/encoding format for key material

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

Re: [bitcoin-dev] New serialization/encoding format for key material

Hi The BIP proposal is now available here: https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719 Reference C code is available here: https://github.com/jonasschnelli/bech32_keys Feedback, criticism, etc. welcome! Thanks — Jonas signature.asc Description: Message signed with

Re: [bitcoin-dev] New serialization/encoding format for key material

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

Re: [bitcoin-dev] BIP 174 thoughts

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 >

Re: [bitcoin-dev] Electrum Personal Server alpha release

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)

Re: [bitcoin-dev] BIP 174 thoughts

> * 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

Re: [bitcoin-dev] Building a Bitcoin API and query system.

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

Re: [bitcoin-dev] Overhauled BIP151

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

Re: [bitcoin-dev] Building a Bitcoin API and query system.

> 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

Re: [bitcoin-dev] BloomFilter issue with segwit addresses

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

[bitcoin-dev] Overhauled BIP151

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

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

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

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

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:

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

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

Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol

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?

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

> 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

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

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

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

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

Re: [bitcoin-dev] Compressed Bitcoin Transactions

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

Re: [bitcoin-dev] Refreshed BIP324

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

Re: [bitcoin-dev] Compressed Bitcoin Transactions

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