[bitcoin-dev] Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt)

2022-08-20 Thread Felipe Micaroni Lalli via bitcoin-dev
Hi dear devs, 1. THE ISSUE - DAEMON+CLI I had a wallet in a server production since 2017 (5 years old) and when it reached about 273 MB, 2.079.337 transactions and 446.503 generated addresses, the performance started to degrade exponentially. Most of the commands, e.g.

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-11 Thread Felipe Micaroni Lalli via bitcoin-dev
The expectation is that in a few years a space in the block will be very competitive / expensive and be used only as a bridge for second layers or big transactions. Who would have thought in 2017 that one day we would be worried about cheap rates! Anyway, it seems like a good point and I suggest

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-06-04 Thread Felipe Micaroni Lalli via bitcoin-dev
Totally agree. I couldn't agree more. On Fri, Jun 3, 2022 at 3:44 PM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Note: This email is an opinion and not an attack on bitcoin > > Covenants on bitcoin will eventually be implemented with a soft fork. CTV > is the

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-04-28 Thread Felipe Micaroni Lalli via bitcoin-dev
Hi Keagan, The worst case scenario is: no new proposals are accepted and the Bitcoin remains the same. This is not so bad. I think a bad actor will usually want to *add* (or remove) something that breaks. I don't know if the boycott of new proposals is as effective in breaking Bitcoin. It means

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

2022-04-27 Thread Felipe Micaroni Lalli via bitcoin-dev
The idea seems interesting at first glance, but soon we see several problems. The biggest problem with votes of this type is that they can be easily manipulated. Imagine a powerful attacker who impersonates someone in good faith and arrives with a proposal that looks great but has dark ends behind

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-15 Thread Felipe Micaroni Lalli via bitcoin-dev
Interesting discussion. Correct me if I'm wrong: but putting too many features together in one shot just can't make things harder to debug in production if something very unexpected happens. It's a basic principle of software engineering. Change. Deploy. Nothing bad happened? Change it a little

Re: [bitcoin-dev] Taproot NACK

2021-03-03 Thread Felipe Micaroni Lalli via bitcoin-dev
Dear LORD HIS EXCELLENCY JAMES HRMH (& HMRH), a.k.a. "The Australian", This discussion list is serious stuff, please stop making noise. Fungibility is a desirable property, anyway. Thank you! On Wed, Mar 3, 2021 at 12:04 PM Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>

Re: [bitcoin-dev] Bitcoin Core versus XT observations

2015-08-19 Thread Felipe Micaroni Lalli via bitcoin-dev
On 19/08/2015 09:24, Ken Friece via bitcoin-dev wrote: 5.) Not-BitcoinXT is a really terrible idea. Mike has proven time and time again that he will not blink or back down. The chances of Not-BitcoinXT gaining 25% of the hashrate are pretty much nil, so in effect, all Not-BitcoinXT will do is