Re: [bitcoin-dev] Proposal for an Informational BIP

>>> I think the biggest problem you have with this proposal is "rolling your >>> own security". >>> >>> Are you aware that the dictionary is designed such that the first four >>> letters are unique to each word? Taking those four letters and >

Re: [bitcoin-dev] Proposal for an Informational BIP

on as most wallets have been > using for years. > > C > > On Sat, 8 May 2021 at 17:21, BitPLATES® (Chris) via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi, >> >> I'd like to submit an idea for review, as a potential inf

Re: [bitcoin-dev] Proposal for an Informational BIP

o Chris, >>> Isn't your suggestion already covered by BIP39 since there is not >>> restriction in how you choose your passphrase? >>> >>> It's up to any user to choose his password like you propose. I see your >>> proposal more like a w

Re: [bitcoin-dev] Proposal for an Informational BIP

. Thus you get a > chicken-egg problem, at least for some implementations. Probably you could > use the restore feature to work around this - but it's one step more that > should be mentioned. > > > Kind regards > Tobias > > > > > BitPLATES® (Chris) via bitcoin-de

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

On 7/23/19 10:47 AM, Andreas Schildbach via bitcoin-dev wrote: 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 t

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

On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote: > One aspect which isn't in this BIP draft is direct support for unconfirmed > transactions. I consider such a feature an important UX feature for mobile > phones, and something which I've personally seen as an important > UX-experi

Re: [bitcoin-dev] Mutli-push op_return

am I correct to assume that multiple pushdatas in op_return would normally be considered standard? On 01/08/2017 10:08 PM, Luke Dashjr wrote: > On Monday, January 09, 2017 2:09:09 AM Chris via bitcoin-dev wrote: >> Would there be an objection to making op_return outputs with two >> push

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

Thanks for doing some work on this Jonas. It's something I've been interested in for a while. I haven't had an opportunity to read the bips but I will do so soon and comment. As far as the use cases others mentioned, connecting and SPV wallet to your full node is certainly one. It would make it ea

Re: [bitcoin-dev] On the security of softforks

On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev > wrote: 2) The risk of an old full node wallet accepting a transaction whose coins passed through a script that depends on the softforked rules. There's that, but there's also a case where

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On 12/08/2015 10:12 AM, Gavin Andresen via bitcoin-dev wrote: > Why segwitness as a soft fork? Stuffing the segwitness merkle tree in > the coinbase is messy and will just complicate consensus-critical code > (as opposed to making the right side of the merkle tree in > block.version=5 blocks the se

Re: [bitcoin-dev] Opt-in Full Replace-By-Fee (Full-RBF)

On 11/16/2015 07:42 PM, Peter Todd via bitcoin-dev wrote: > Sequence is used for opting in as it is the only "free-form" field > available for that purpose. Opt-in per output was proposed as well by > Luke-Jr, however the CTxOut data structure simply doesn't contain any > extra fields to use for th