Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to
use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners
can help to avoid the risk of forks, they aren't the
On 2/27/21 6:55 PM, Luke Dashjr wrote:
This has the same problems BIP149 did: since there is no signalling, it is
ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF
nodes will remain on the same chain, with conflicting perceptions of the
rules, and resolution (if ever)
On Sat, Feb 27, 2021 at 09:19:34AM -1000, David A. Harding via bitcoin-dev
wrote:
> - Discussion thread 1:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014186.html
Two particularly useful emails from that thread are:
-
On Fri, 26 Feb 2021 at 20:57, Keagan McClelland via bitcoin-dev
wrote:
> The goals are to increase data redundancy in a way that more uniformly shares
> the load across nodes, alleviating some of the pressure of full archive nodes
> on the IBD problem. I am working on a draft BIP for this
On Sat, 27 Feb 2021 at 22:09, Yuval Kogman wrote:
> and there is work on fountain codes. There is also some work on
apologies, the first half of this line should have been deleted as it
was worked into the next sentence.
___
bitcoin-dev mailing list
I just want to lay out some facts as I see them because frankly I feel
any personal opinion is irrelevant at this point and without agreement
on facts we are going round in circles. I end with a personal opinion
which you can feel free to ignore.
1) There is a long list of current and past Core
On Fri, Feb 26, 2021 at 11:40:35AM -0700, Keagan McClelland via bitcoin-dev
wrote:
> Hi all,
Hi Keagan,
> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had
This has the same problems BIP149 did: since there is no signalling, it is
ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF
nodes will remain on the same chain, with conflicting perceptions of the
rules, and resolution (if ever) will be chaotic. Absent resolution,
I have good news for you: Taproot does not enable monero-like privacy
features any moreso than already exist in Bitcoin today. At its core,
taproot is a way to make transactions with embedded smart contracts less
expensive, done so in a manner that may marginally improve privacy
dependent on user
Good Afternoon,
It has been reported that Taproot will enable some Monero like features
including the ability to hide transactions.
If that is the case I offer a full NACK and let me explain.
A part of the benefit of using Bitcoin is its honesty. The full transaction is
published on the
Good Afternoon,
Does anybody have a consensus list of the existing consensus items? i.e. to
itemise the operation of consensus into a list.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian
Hi Keagan,
I had a very similar idea. The only difference being for the node to decide
on a range of blocks to keep beforehand, rather than making the decision
block-by-block like you suggest.
I felt the other nodes would be better served by ranges due to the
sequential nature of IBD. Perhaps
12 matches
Mail list logo
