On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev
wrote:
>
> At this point in time it also appears the greatest risk to Taproot
> dying a slow death is a small group of developers who think talking in
> conservative tones and talking about endless philosophy makes Bitcoin
> a
Your Excellency,
You don’t seem to understand how Bitcoin currently works. A signature is a
mathematical /probabilistical proof that the person who signed (the output) is
the same person who created the script (the input) that was paid to (i.e. not
fraud). You cannot see that he is that
No, it's not the same. This approach is not guaranteed to activate. On
flag day, it'd check for (say) 20% miner support, and activate if so. If
>80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally.
Also, the day before lock-in, this would still
would it help by first setting a regular period of e.g. 6 months when
only at that time would consensus rules ever be changed? not, "6
months from now taproot will be introduced', a rule, "*any* consensus
change regardless of what they are (including NO change) will *ONLY*
be made at regular
On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
While I support essentially any proposed taproot activation method, including a flag day activation, I think it is
premature to call BIP8 dead.
Even today, I still think that starting with BIP8 LOT=false is, generally speaking,
On 2021-03-03 20:48, Chris Belcher wrote:
On 03/03/2021 17:30, yanma...@cock.li wrote:
Is that supposed to be a good thing? "We should do X because it'll
work"
doesn't prove X is actually good. These things can be evil, but they
can
also be legitimate opposition to a change. Taking away the
While I support essentially any proposed taproot activation method,
including a flag day activation, I think it is premature to call BIP8 dead.
Even today, I still think that starting with BIP8 LOT=false is, generally
speaking, considered a reasonably safe activation method in the sense that
I
It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain rules
enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote
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>
Yesterday we held a UASF (LOT=true) kick off meeting on the ##uasf IRC channel.
The conversation log is here: http://gnusha.org/uasf/2021-03-02.log
It was announced (at short notice admittedly) here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html
It is clear
On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its
own
followers fork away. Crucially, miner signalling cant be used to change
the activation date for nodes
On Tue, Mar 02, 2021 at 06:21:59PM +, Chris Belcher via bitcoin-dev wrote:
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.
That depends on the definition you choose to work with but since the community
had to produce a fix that implies something
> consensus requires the ledger to be honest does not prove that it is honest.
Actually, that’s exactly what it does. A logical/mathematical requirement
(necessity) is also called a proof.
e
From: bitcoin-dev On Behalf Of
LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
Sent: Tuesday,
On Sun, Feb 28, 2021 at 11:45:22AM -0500, Matt Corallo via bitcoin-dev wrote:
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022. Going
The bitcoin world is close to total gridlock on the question of how to
activate taproot. There's no agreement on activation[1][2], and if an
agreement isn't reached then nothing happens. That would be really
terrible because we'd miss out on the benefits of taproot and
potentially other future
Good Afternoon,
No-one has yet demonstrated that Conjoin or using Wasabi wallet is secure if it
relies on third-parties. Are the transaction not forwarded partially signed as
with an SPV wallet? So it is possible the SPV server cannot redirect funds if
dishonest? SPV wallets are secure
Good Afternoon,
All people are entitled to privacy in their purse, and all transactions should
be open to the scrutiny of an honest government. You can debate whether any
government is honest. Mixing does not remove the record from the public ledger,
where it is possible to see that any
"Today I spent approximately $5 at a chip shop in North London in cash. Besides
the fact that I have voluntarily chosen to share this information, it is
absolutely no concern of yourself or any other party that this transaction has
occured."
Good Afternoon,
Requiring little argument I concur,
> I believe this is what BIP 60 does, or did you have something else in
> mind?
Right, it achieves the first goal of dissociating `fRelay` from BIP37 but
it doesn't document Core specific behavior of disconnecting peers for raw
TX messages reception
from outbound block-relay-only peers, as
19 matches
Mail list logo
