ZmnSCPxj,
I think that this implication affects other applications built on the
blockchain, not just the PubRef proposal:
> There is a potential for a targeted attack where a large payout going to
a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction
finds that
ZmnSCPxj,
> Lightning uses a "short channel ID" which is basically an index of block
number + index of transaction + index of output to refer to channels.
Oh wow, this is very similar to the PUBREF proposal. In fact the OP_PUBREF4
operation could be modified to take the tuple: (block number,
Hey ZmnSCPxj,
As to your first point. I wasn't aware there was so much volatility at the
tip, also 100 blocks is quite the difference! I agree no one could
references a transaction in a newly formed blocks, but I'm curious how this
number was chosen. Do you have any documentation or code that
I noticed that this Merkle tree we are building is made more expensive by
including repetitive data. So, this proposal draws inspiration from LZ78,
an algorithm which constructs a dictionary of repetitive strings which are
then referred to by their index. What if the blockchain already built a
Fungibility is a good question for inductive reasoning. After all, what is
a claim without some rigger?
There exists some set of wallets 'w' which contain a balance of satoshi too
small to recover because it doesn't meet the minimum transaction fee
required to confirm the transaction. These
Very interesting,
Block mixing did not resolve the selfish mining that is currently observed
on the network. This mitigation was only intended to limit the maximum
impact of waiting for a 2nd block to be produced.
Rebalancing the selfish-mining incentives with FPNC and a faster block
creation
On Wednesday, October 7, 2020 1:31 PM, Mike Brooks via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But first of all, I'd like to say that the idea for FPNC came out of a
> conversation with ZmnSCPxj's in regards to re-org stability. When I had
> proposed b
Hello Everyone,
Below is a novel discussion on block-withholding attacks and FPNC. These
are two very simple changes being proposed here that will
dramatically impact the network for the better.
But first of all, I'd like to say that the idea for FPNC came out of a
conversation with ZmnSCPxj's
Good Morning ZmnSCPxj ,
It is cheaper and easier to delay messages, or preempt the spreading of
messages, than it is to produce a better fitness score. Whether it be
through pre-emption or an eclipse - an adversary can influence the size of
both sides of the disagreement, which is a strange
Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/will
Hey Bob McElarth,
I appreciate this discussion. The issues with chain thrashing was
explicitly addressed with heredity, I saw this problem, and there is an
elegant solution here.
Sorry that summation process wasn't made clear in the paper, I'll be sure
to go back and improve this. Here is a
dev@lists.linuxfoundation.org> wrote:
>
> On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> [snip]
>
>> The solution above also has 19 prefixed zeros, and is being broadcast for
>> the same blockheight value o
ZmnSCPxj,
No, it would be better to use parachains for Mars.
-Mike Brooks
On Tue, Sep 29, 2020, 11:31 PM ZmnSCPxj wrote:
>
> > At this point very little is stopping us from speeding up block
> creation times. PoS networks are proving that conformations can be a minute
> or less - why not
Hey Everyone,
A lot of work has gone into this paper, and the current revision has been
well received and there is a lot of excitement on this side to be sharing
it with you today. There are so few people that truly understand this
topic, but we are all pulling in the same direction to make
at is further behind.
The difference between the 2013 post and FPNC is the alignment of
incentives.
-Mike
On Sat, Sep 26, 2020, 3:12 AM David A. Harding wrote:
> On Fri, Sep 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev
> wrote:
> > - with a fitness test you have a 1
Hey Jeremy,
Thanks for your response, but I think you misunderstood a crucial feature
- with a fitness test you have a 100% chance of a new block from being
accepted, and only a 50% or less chance for replacing a block which has
already been mined. This is all about keeping incentives moving
ayer - especially when it affects
> mining incentives. I don't see how people will take this seriously -
> especially when you regard how often consensus changes are made to _fix_
> something as opposed to add something new.
>
> Best regards,
>
> Thomas
> On 9/24/20 8
ZmnSCPxj,
The growing tare in growing disagreement continues to divide mining
capacity while the network waits for formation of future blocks - you'll
never get to complete consensus unless three is a way to avoid ambiguity
in disagreement, which you have not addressed. The topic of my
Hey Larry,
Great project, and great youtube video. Expect a PR from me.
... If you actively ping nodes that are running a weaker block, you could
inform them of the new block, there could be a mechanism to
eradicate dissent.
-Mike
On Thu, Oct 1, 2020 at 9:43 AM Larry Ruane wrote:
> Hello
Hey Everyone,
A lot of pressure rides on AttemptToEvictConnection() because it is used to
limit the impact of eclipsing attacks. With continued centralization, fair
connection formation becomes a bigger concern. I am curious how other
members of the community feel about the preferential treatment
The attached BIP describes a new opcode that unlocks the ability to have
transactions that are about 37% smaller than a traditional single-source
segwit transaction. (Savings vary based on the number of inputs.)
The pursuit of smaller transactions is vital for Inclusive Accountability
as less
Hey ZmnSCPxj,
Re-orgs should be solved in a different way.
Best Regards,
Micahel
On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj wrote:
> Good morning Mike,
>
> Hard NAK.
>
> The responses to the original posting already pointed out important
> problems with this:
>
> * Encourages address reuse,
22 matches
Mail list logo
