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 (

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 GUI

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

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 m

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

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

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 f

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

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 O

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

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

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 over

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

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 a

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 of

[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] 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 start

[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: https://gist.gith

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

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

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 traffi

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

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

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 is

Re: [bitcoin-dev] Weekly development meetings on IRC

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan > via bitcoin-dev wrote: >> At Monday's code sprint we had a good idea to schedule a regular >> developer meeting in #bitcoin-dev. >> >> Attendance is of course voluntary, but it ma

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 ma

Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Perhaps Pedro wants to also participate in a 2-of-2 cosigning > arrangement with a merchant that will deliver a laptop to him, so > Pedro provides this merchant with the same extended public key > derived from path m/45', and the merchant provides

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 on

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

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 ha

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 consensus

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

[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. ==T

Re: [bitcoin-dev] consensus rule change for TX fee safety

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

[bitcoin-dev] p2p authentication and encryption BIPs

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 bl

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 authen

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

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

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

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 net

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 y

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

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

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 i

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 coul

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 does

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 spe

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

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 feat

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

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 s

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

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

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

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

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 and

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 its

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

Hi Arthur > > I strongly agree! > In crypto we should always follow well-studied open standard rather > than custom construction. I totally agree. BIP151 does not introduce new cipher types. The BIP uses ECDH together with ChaCha20-Poly1305@openssh. Both very well known and broad used

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 Digit

[bitcoin-dev] Authentication BIP

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 requi

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

Re: [bitcoin-dev] Authentication BIP

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

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

Re: [bitcoin-dev] Hardware Wallet Standard

> 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

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 multipl

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

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

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 to

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 wa

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 supp

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] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

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

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

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

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 bitcoin-dev@lists.

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 in

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 l

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] 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 (https://g

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 referring

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

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 c

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

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“). >> >> Please Eric. Stop

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 ssid

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 run

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

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 three

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

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 pro

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 kn

  1   2   >