Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

I fully agree with sipa and his reasoning that this proposal is not solving any particular problem, but making it actually a bit worse. Also, do you know what I hate more than copy bitcoin addresses? Copy pasting zillion random fields for SEPA/wire transfers. And I believe that a single copy

Re: [bitcoin-dev] BIP 174 thoughts

On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > seems a bit overkill for how simple the format is, and pulling in a > large dependency just for this is a bit silly. Although making it > protobuf-compatible is an interesting idea,

Re: [bitcoin-dev] Start time for BIP141 (segwit)

On Sun, Oct 16, 2016 at 10:58 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev > wrote: > > It's not the website's fault if wallet devs aren't updating their > > statuses. Besides, "WIP" can

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

As Luke pointed, BIP44 is already used by many wallets and to my knowledge people don't have any real world issues with that, including loading funds in another BIP44 wallet. I'm not saying that BIP44 is perfect from all points of view, but IMO it just works for most use cases. Let's set it as

Re: [bitcoin-dev] Hardware Wallet Standard

On Thu, Aug 18, 2016 at 11:35 AM, Jonas Schnelli wrote: > I agree that BIP70 is a mess (including the bitcoin:// additions). The > proposed URI scheme would be completely different. This reminds me https://xkcd.com/927/ I have some experience with hardware wallet

Re: [bitcoin-dev] Hardware Wallet Standard

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

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] Making AsicBoost irrelevant

Ehm, I though those discussions about "ASICs are bad, because X" ended years ago by starting "ASIC unfriendly" altcoins. ASIC industry is twisted even without AsicBoost. I don't see any particular reason why to change rules just because of 10% edge. This is opening Pandora box and it is

[bitcoin-dev] Fwd: Proposal to update BIP-32

I received this: -- Forwarded message -- From: Pieter Wuille Date: Fri, Apr 22, 2016 at 6:44 PM Subject: Re: [bitcoin-dev] Proposal to update BIP-32 To: Marek Palatinus Cc: Bitcoin Dev On Thu,

Re: [bitcoin-dev] Proposal to update BIP-32

Sipa, you are probably the most competent to answer this. Could you please tell us your opinion? For me, this is straightforward, backward compatible fix and I like it a lot. Not sure about the process of changing "Final" BIP though. Slush On Wed, Apr 20, 2016 at 6:32 PM, Jochen Hoenicke via

Re: [bitcoin-dev] AsicBoost

To my understanding it is purely software thing. It cannot be detected from outside if miner uses this improvement or not. So patenting it is worthless. slush On Tue, Apr 5, 2016 at 1:01 AM, Mustafa Al-Bassam via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Alternatively