d increase the chance they earn money from it) or
protect against the theft (and reduce the chance they earn money from it).
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> Original Message
> Subject: Re: [bitcoin-dev] Two Drivechain B
Hello ZmnSCPxj,
Thanks for contributing your thoughts. I wish I were able to respond sooner!
1. I'm a little confused about the second half of your message, and its
emphasis on pools. As you know, pools can be created or destroyed an
unbounded number of times, costing only a small time lag. So I
coordinate with
the Thief under this structure. But perhaps this idea may trigger someone else
to consider how to exploit the precise mathematics of P2PKH to create something
similar to a HTLC.
Regards,
ZmnSCPxj
Original Message
Subject: Re: [bitcoin-dev] Two Drivechain BIPs
Local Time:
On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote:
> ...
> This vulnerability can be fixed if withdrawals are restricted to
> simple P2PKH or P2WPKH only,
Limiting the withdrawal outputs to P2PKH and perhaps P2WPKH (would there
be any network benefit to supporting witness pubkeys for
Good morning Paul and Chris,
>I don't agree with the conclusion (that the optimal policy is "always
>downvoting", see above), but even if this analysis turns out to be correct, it
>isn't a total disaster. The result (which is in the original Nov
>2015 specification) is that miners are the ones
Good morning Paul and Chris,
>3. Collective Action Problem
>
>There actually is a collective action problem inherent to fraudulent
>withdrawals.
>
>If miners wish to fraudulently withdraw from the sidechain, they need to
>choose the destination addresses (on mainchain Bitcoin Core) months in
Hi Other Chris,
Thanks for pointing this out. Here are my responses.
On 12/4/2017 3:11 PM, Chris Stewart wrote:
>There is another interesting analysis on BMM and drivechains from
/u/almkglor on reddit. I'm going to share here for visibility.
>> 3 and 7 will mean that non-verifying miners will be
Hello,
I would like to refer to these BIPs in other contexts and conversations.
Regardless of the pitfalls or benefits, the discussion and technical review
happening in this thread (and the ones before) are well-formed ideas with
an active champion. The point of BIP numbers/conventions are so
>As far as I can tell there is no opportunity cost to casting a malicious
vote, no repercussions, and no collective action barrier that needs to be
overcome.
There is another interesting analysis on BMM and drivechains from /u/almkglor
on reddit
Hello Chris,
1. Marginal Cost
There actually is a very small cost to casting a malicious vote,
relative to an honest vote. This is because the software (when run
as-is), will automatically vote correctly. But to vote fraudulently you
must decide on what to do instead, and configure that! This
On Sunday 03 December 2017 9:32:15 PM Matt Corallo wrote:
> Given the lack of convincing evidence of that "Risk of centralisation of
> mining" drawback in section 4.3 of the sidechains paper has been
> meaningfully addressed, I'd say its pretty important that new sidechains be
> an incredibly rare
Hi Matt,
Thanks for very much for your thoughtful review
Comments below.
On 12/3/2017 4:32 PM, Matt Corallo wrote:
> ...
>
> ...
>
> Comments on BIP 1:
>
> At a high level, I'm rather dissapointed by the amount of data that is
> going into the main chain here. Things such as a human readable
Process note: It looks like the BIPs have never been posted to
bitcoin-dev, only high-level discussion around the idea. As I understand
it, this is *not* sufficient for BIP number assignment nor
(realistically) sufficient to call it a hard "proposal" for a change to
consensus rules.
Would love to
13 matches
Mail list logo
