Hi!
As a minor diversion while discussing activation parameters, I felt it
would be meaningful to collect a survey on what people are already using
Taproot for in either conceptual, prototype, or implemented/spec phases.
I suspect there are a lot of people tinkering with Taproot one way or
anothe
The assumption of malice on the part of those of us supporting a UASF is
tragic and frankly ridiculous. Many of us backed off of the effort the
second that this Speedy Trial solution was proposed in order to dislodge
the gridlock on the LOT value. I can't say for certain that 100% of those
working
On 3/6/21 14:56, Michael Folkson wrote:
Hi Matt
> I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split
the network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make
a lo
I don't think anyone is proposing anything to "prevent" other people from doing anything they wish. My understanding of
the goal of this proposal, itself, was to keep the community together by proposing a solution that was palatable to all.
My point was that I'm not sure that this proposal achiev
On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev
wrote:
>
> I'm really unsure that three months is a short enough time window that there
> wouldn't be a material effort to split the
> network with divergent consensus rules. Instead, a three month window is
> certainly long enough to
Hi Matt
> I'm really unsure that three months is a short enough time window that
there wouldn't be a material effort to split the network with divergent
consensus rules. Instead, a three month window is certainly long enough to
organize and make a lot of noise around such an effort, given BIP 148
On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo wrote:
> I'm really unsure that three months is a short enough time window that there
> wouldn't be a material effort to split the network with divergent consensus
> rules.
I oppose designing activation mechanisms with the goal of preventing
As said before, you are free to create the BIP in your own repository
and bring it to discussion on the mailing list. then you can do a PR
Lonero Foundation via bitcoin-dev
escreveu no dia sábado,
6/03/2021 à(s) 08:58:
>
> I know Ethereum had an outlandishly large percentage of nodes running on A
I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split the
network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make a
lot of noise around such an effort, given BIP 148 was organ
Replies inline. Several sections removed, where I basically agree.
On 3/4/21 08:47, Russell O'Connor wrote:
Appologies as I've rearranged your comments in my reply.
I agree with you. I also think we have plenty of evidence to proceed with taproot and could proceed with a PR for such
a flag day
Hi Andrew,
This is a slight misunderstanding of the proposal. Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.
Thus using your figures it would instead be:
* start height = 681408 /* about May 1st */
* timeout height = 69
Hi,
Given recent discussions around possible cracks to RSA, ECDSA and even sha256
we have been looking at possible options for hardening Bitcoin against those
potential attack vectors. While most consider it a low priority, IMO it is
better to discuss this issue than ignore it especially given
On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> On 3/3/21 09:59, Anthony Towns wrote:
> > A couple of days ago I would have disagreed with this; but with Luke
> > now strongly pushing against implementing lot=false, I can at least see
> > your point...
> Right. It may be the case th
The most sensible approach I’ve seen yet.
e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev
> wrote:
>
> On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev
> wrote:
>> ## Example timeline
>> - T+0: release of one or more full nodes with activation code
>> -
On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev
wrote:
> ## Example timeline
> - T+0: release of one or more full nodes with activation code
> - T+14: signal tracking begins
> - T+28: earliest possible lock in
> - T+104: locked in by this date or need to try a different
I know Ethereum had an outlandishly large percentage of nodes running on
AWS, I heard the same thing is for Bitcoin but for mining. Had trouble
finding the article online so take it with a grain of salt. The point
though is that both servers and ASIC specific hardware would still be able
to benefit
I found a hint of common ground in reddit that I absolutely loves and
just had to share here on the ML to discuss
Luke's suggestion: To minimise the signal from 90% to 50%+1 during the
MUST_SIGNAL phase.
https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_t
> A large portion of BTC is already mined through AWS servers and non-asic
specific hardware anyways. A majority of them would benefit from a hybrid
proof, and the fact that it is hybrid in that manner wouldn't
disenfranchise currently optimized mining entities as well.
My instincts tell me that t
Hi, in regards to my research this is just one of my patents:
https://patents.google.com/patent/CN110825707A
This isn't related to this proposal but gives you a general depth of
understanding in regards to the technology and field I'm working on in
reducing redundancy and efficiency. You aren't a c
19 matches
Mail list logo
