Paul, > The confusion below stems from his conflation of several different ideas.
I'm right here, are you having a conversation with me or are you on a stage talking to an audience? > 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. 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. > 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. > Again, from the perspective of a mainchain user, every withdrawal is valid. And that is not how P2SH works. > [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? What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean? In P2SH, all upgraded nodes will reject invalid P2SH 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? Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy. 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 5:26 PM, Paul Sztorc <truthc...@gmail.com > <mailto:truthc...@gmail.com>> wrote: > > The confusion below stems from his conflation of several different ideas. > > I will try to explicitly clarify a distinction between several types of user > (or, "modes" of use if you prefer): > > [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. > > > On 7/12/2017 6:43 PM, Tao Effect wrote: >> >> 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? > 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. > > [DC#0] Yes > [DC#1] Yes > [DC#2] Yes > [DC#3] Yes > > 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]. > > (And this is the main advantage of DC over extension blocks). > > >> 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. > [DC#0] They do. > [DC#1] They do. > [DC#2] They do. > [DC#3] They do. > > Again, from the perspective of a mainchain user, every withdrawal is valid. > > >> 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. > There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1]. > > [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. > > >> 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. > Somehow I doubt it. > > > Paul
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
