Tao Effect [ARCHIVE] on Nostr: ð Original date posted:2017-07-13 ð Original message:Dear Paul, > In point of ...
ð
Original date posted:2017-07-13
ð Original message:Dear Paul,
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
I may very well have confused who counts what, but for this discussion on *theft* it's irrelevant, so I won't push further on this.
Let's move on to the theft.
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
To be crystal clear: I am entirely uninterested in the un-upgraded nodes, what you call [DC#0].
They are irrelevant to my argument.
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
This is false.
For miners to steal P2SH funds, the P2SH script would have to be coded to explicitly allow them to do it.
How many P2SH scripts are you aware of that are used for the purpose of facilitating such theft?
I know of none, and I bet there are none.
Whereas in DC, every single usage of DC allows miners to steal funds.
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
It appears you are playing games with the meaning of "invalid" here, so that sentence is invalid.
I was very clear what I meant by "invalid" in my email: WT^ transactions that represent miners stealing funds. Please stick to that and do not play word games.
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
So, here you are again re-affirming that WT^ transactions representing stolen funds are allowed in DC, and by tying them all together you are also affirming that the SPV proofs mentioned in DC are completely irrelevant / pointless / unused.
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
So in the first sentence you say they "cannot steal funds", but everything else you've said, including the following paragraph, and your specification, indicates they can.
I've finally collected all my thoughts / concerns and have also summarized them in this document:
https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 <https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9>;
Kind regards,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 7:58 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I will repeat that Drivechain can sometimes be confusing because it is different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he equivocates on the team "steal", using it to mean two different things: [a] spending an invalid transaction, and [b] a withdrawal that would not match the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>>> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
>>
>> What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.
>
> Greg quoted a passage that contained an older parameter estimate of "a few days", and I thought it would be helpful and informative if I clarified that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
>
>
>> Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.
>
> As I stated above, the document is mostly accurate. There is no other more up to date version.
>
>
>>> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>>
>> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.
>
>
> Above, Greg omitted his original question. For reference, it was:
>
>> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
>
> The answer is that both DC and P2SH use transactions which are 'always valid' to some group of people (un-upgraded users) but which are sometimes invalid to new users. So the only difference would be for [DC#0] vs other versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
>>> Again, from the perspective of a mainchain user, every withdrawal is valid.
>>
>> And that is not how P2SH works.
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
>
>
>>> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
>>
>> How is that an answer to my question?
>
> Greg is, of course, not entitled to an answer to irrelevant questions -- just as he would not be entitled to an answer if he asked for my favorite color or my home address. And such answers would needlessly consume the mailing list's scarce time.
>
>
>> What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?
>
> It is clear to me that, if we are not clear on the basics first, we cannot hope to tackle anything intermediate. We will come back to this after clearing up soft fork part.
>
>
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
>> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction â invalid in the sense that it contains funds which miners are stealing?
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
>
>
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/abb2b4f4/attachment-0001.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/abb2b4f4/attachment-0001.sig>;
ð Original message:Dear Paul,
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
I may very well have confused who counts what, but for this discussion on *theft* it's irrelevant, so I won't push further on this.
Let's move on to the theft.
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
To be crystal clear: I am entirely uninterested in the un-upgraded nodes, what you call [DC#0].
They are irrelevant to my argument.
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
This is false.
For miners to steal P2SH funds, the P2SH script would have to be coded to explicitly allow them to do it.
How many P2SH scripts are you aware of that are used for the purpose of facilitating such theft?
I know of none, and I bet there are none.
Whereas in DC, every single usage of DC allows miners to steal funds.
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
It appears you are playing games with the meaning of "invalid" here, so that sentence is invalid.
I was very clear what I meant by "invalid" in my email: WT^ transactions that represent miners stealing funds. Please stick to that and do not play word games.
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
So, here you are again re-affirming that WT^ transactions representing stolen funds are allowed in DC, and by tying them all together you are also affirming that the SPV proofs mentioned in DC are completely irrelevant / pointless / unused.
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
So in the first sentence you say they "cannot steal funds", but everything else you've said, including the following paragraph, and your specification, indicates they can.
I've finally collected all my thoughts / concerns and have also summarized them in this document:
https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 <https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9>;
Kind regards,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 7:58 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I will repeat that Drivechain can sometimes be confusing because it is different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he equivocates on the team "steal", using it to mean two different things: [a] spending an invalid transaction, and [b] a withdrawal that would not match the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>>> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
>>
>> What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.
>
> Greg quoted a passage that contained an older parameter estimate of "a few days", and I thought it would be helpful and informative if I clarified that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
>
>
>> Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.
>
> As I stated above, the document is mostly accurate. There is no other more up to date version.
>
>
>>> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>>
>> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.
>
>
> Above, Greg omitted his original question. For reference, it was:
>
>> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
>
> The answer is that both DC and P2SH use transactions which are 'always valid' to some group of people (un-upgraded users) but which are sometimes invalid to new users. So the only difference would be for [DC#0] vs other versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
>>> Again, from the perspective of a mainchain user, every withdrawal is valid.
>>
>> And that is not how P2SH works.
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
>
>
>>> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
>>
>> How is that an answer to my question?
>
> Greg is, of course, not entitled to an answer to irrelevant questions -- just as he would not be entitled to an answer if he asked for my favorite color or my home address. And such answers would needlessly consume the mailing list's scarce time.
>
>
>> What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?
>
> It is clear to me that, if we are not clear on the basics first, we cannot hope to tackle anything intermediate. We will come back to this after clearing up soft fork part.
>
>
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
>> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction â invalid in the sense that it contains funds which miners are stealing?
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
>
>
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/abb2b4f4/attachment-0001.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/abb2b4f4/attachment-0001.sig>;