[bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect]

Paul,

I'm assuming it's OK with you that I pick up from where we left off in the "Scaling Roadmap" thread [1], so as to be on-topic per your request. (For others reading, part of my reply to the previous email in this thread is here [2]).

For reference, I said:

> Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script?
> 
> In other words, miners don't have complete control over the coins, full nodes keep a check on them.
> 
> At least that was my understanding, and if that's not the case then it doesn't make sense to me why Pieter would earlier in this thread object to Drivechain on the grounds that it's a different security model.


CryptAxe's response was in part:
> You guys are both right that it is a different security model, with the important distinction that it is opt-in. What I disagree with about what you said is only that we are encouraging more risky behavior by adding consensus rules via softfork. There are additional risks with drivechains, but not because of how the new consensus rules would be added (it would be the same risk as the P2SH softfork).


I am now looking closer again at step number 4 in the Drivechain specification [2]:

4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they’re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.


It seems to me that where our disagreement lies is in this point.

The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?

The following suggests to me it isn't:

1. Pieter Wuille's email suggests he disagrees [4]

2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.


In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.


If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.

Kind regards,
Greg Slepak


[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html>
[3] http://www.truthcoin.info/blog/drivechain/ <http://www.truthcoin.info/blog/drivechain/>
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html>

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jun 19, 2017, at 9:04 AM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
> 
> Hi Greg,
> 
> Responses below:
> 
> On 6/18/2017 5:30 PM, Tao Effect wrote:
>> In Drivechain, 51% of miners have total control and ownership over all
>> of the sidechain coins.
> 
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
> 

[ ...snip.. ]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d949a60c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d949a60c/attachment.sig>