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

Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: > > On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote: > >>> The payment request message is just as one-way as an address is.

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

Op 28 sep. 2017, om 17:13 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: > > On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev wrote: > >>> This feels redundant to me; the payment protocol already ha

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

Op 27 sep. 2017, om 22:01 heeft Bryan Bishop via bitcoin-dev het volgende geschreven: > > On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev > > wrote: >

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

Op 29 sep. 2017, om 05:18 heeft Peter Todd <p...@petertodd.org> het volgende geschreven: > > On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev > wrote: >> Peter Todd wrote: >> Perhaps outside the scope of BIP173, but what about baking it into

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

> Op 30 sep. 2017, om 06:49 heeft Jonas Schnelli via bitcoin-dev > het volgende geschreven: > >> On 09/29/2017 02:03 PM, Luke Dashjr wrote: >> Paper wallets are a safety hazard, insecure, and generally not advisable. >> > > I have to agree with Luke. >

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

Op 2 okt. 2017, om 03:56 heeft Luke Dashjr via bitcoin-dev het volgende geschreven: > > On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote: >>> b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114 >>> but now I think it

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

A 12-24 word BIP39 mnemonic is easy to write down and has the benefit of not needing to trust a printer. However without also supporting BIP43/44/49 this would probably cause confusion. Supporting these would be a larger project as well. Although widely used, the standards are still Proposed /

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

Peter Todd wrote: > > Re-use of old addresses is a major problem, not only for privacy, but also > operationally: services like exchanges frequently have problems with users > sending funds to addresses whose private keys have been lost or stolen; [...] > > To help combat this problem, I

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

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

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

Have you thought about combining this with BIP-47? You could associate payment codes with email via DNS. It would be nice if there was a way to get rid of the announcement transaction in BIP-47 and establish a shared secret out of bound. That would simplify things, at the cost of an additional

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

Can you clarify what you mean by "whitelisting all blocks before the softfork block"? The most conservative approach could be to leave the code in place until the very last non-segwit P2SH UTXO from before the soft fork block has been spent. But this would never happen if even a single private

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

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

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

I often find myself wanting to leave relatively small comments on BIP's that are IMO not worth bothering this list. By default each BIP has a wiki page for discussion, e.g. https://github.com/bitcoin/bips/wiki/Comments:BIP-0150 This is linked to from the Comments-URI field in the BIP. In order

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

One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125 [0]. It allows wallets to recommend lower fees, because if a transaction gets stuck due to underestimation, the fee can easily be bumped. Bitcoin Core has had support for RBF for a while, and as of v0.15.0 recommends lower

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

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

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

I would like to see this specifically for P2SH-PWPKH and/or native SegWit bech32 addresses. Use cases I can think of are "I'm the whale in charge of these funds, listen to me" and some form of polling. It's nice if funds aren't excluded from these type of functionalities just because they

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

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

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

eMMC storage, which low end devices often use, come in 2x increments. Running a pruned full node on 8 GB is difficult if not impossible (the UTXO set peaked at 3.5 GB in January, but a full node stores additional stuff). However, 16 GB is only €10 more expensive and presumably standard by the

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

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

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

ithm as described in BIP0039. > > But your proposal is a million miles away from simply adding some standard > in-language names to some word lists feels like it's derailing the OP's > simple proposal. Maybe start own email chain about it. > > Alan > > On

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

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

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

I can see how merging after the fact could be more practical than appending existing transactions. I think what Moral Agent suggested is the same as your original proposal, namely dropping rule 3. Only fee per weight unit increase from rule 4 would matter. The minimum per WU increase could be

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

Just to clarify two points: > The good part is that it does not have to be adopted by exchanges. If popular > exchanges do not adopt it, it is trivial to make an adapter service which > translate COX to whatever proprietary API of the exchange. Be sure to elaborate on the difference in trust

Re: [bitcoin-dev] Schnorr signatures BIP

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

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

> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev > het volgende geschreven: > > ==Motivation== > > One of the most powerful heuristic's employed by those whose goal is to > undermine > bitcoin's fungiblity has been to assume all inputs of a transaction are > signed by > a single

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

Concept ACK. > ==Considerations== > > (to be discussed) > > * ''Client MAY store and gossip address formats that they do not know > about'': does it ever make sense to gossip addresses outside a certain > overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for > networks

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

Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network? What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping

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

> (1) It has been well documented again and again that there is desire to > remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in > non-segwit scripts represents a rather significant vulnerability in Bitcoin > today, and (3) lots of effort has gone into attempting to find

Re: [bitcoin-dev] Taproot proposal

Hey Pieter, I think this is a reasonable collection of changes that make sense in combination. Some initial feedback and questions. >From the BIP: > If one or more of the spending conditions consist of just a single key (after > aggregation), > he most likely one should be made the internal

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

ACK for adding Kalle. Recent drama aside, having a single editor is not ideal. There's currently 110 open pull requests to the BIPs repo. - Sjors > Op 23 apr. 2021, om 04:09 heeft Luke Dashjr via bitcoin-dev > het volgende geschreven: > > Unless there are objections, I intend to add Kalle

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

Hi all, First of all thanks for your continued work on standardising multisig setup. The use case I personally find most interesting is not a multi-party setup, but rather just combining a bunch of my own devices. Those might even be in the same room during the setup, only to be moved to my

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

Thanks for the detailed response. Just 1 thing I needed to clarify: > To the list of concerns at the top of the BIP, I would add one: losing > multisig setup context. E.g. in the event of a fire where you only recover > your steel engraved mnemonic(s), but no longer have the wallet descriptors.

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

Thanks for writing this up! I think your modular BIP approach makes sense. (the abstract should mention this too) Contents look good to me, modulo missing test vectors. I also suggest dropping combo(), see below. Regarding the use of h vs ', especially since they result in a different

Re: [bitcoin-dev] Taproot Fields for PSBT

Hi Andrew, I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION contain not just the derivation path for the xonlypubkey, but also the tapleaf merkle path. First I thought it was perhaps necessary in order for a signer to guess which script leaves it can sign with its

Re: [bitcoin-dev] Bitcoin Core 24.1 released

There's a typo in the tracker subdomain: trakcer.bitcoin.sprovoost.nl should be tracker.bitcoin.sprovoost.nl , but I'll just add that subdomain now. - Sjors > Op 19 mei 2023, om 12:56 heeft Michael Ford via