Hi, I don't normally comment on HN but this thread intrigued me. As someone who was quite interested in the Teechan work when it first came out, I have a couple thoughts/questions:
> I'd appreciate if you linked to those actual deployments, something with a description of how they worked.
I'm not sure if this is it, but it looks like something was recently put online (seems to match the authors names): https://arxiv.org/abs/1707.05454
> Your Teechan performance figures reported in your paper and initial announcement were recorded with those counters implemented in RAM, in such a way that a power outage would put users in a position where they can lose funds.
I don't think they disputed that, in fact iirc, they made that quite clear and even under failure cases where a user's CPU loses power, funds are not completely lost; two options remain, either the counterparty can settle the channel (meaning no funds are lost), or the refund tx comes into play. Of course this isn't ideal, but the point remains, for channels where the difference between the most recent state and the refund state is not enormous, this deployment model can make sense. If you want to avoid this, it can be circumvented with backup power generators etc. But they never tried to hide this fact. If you read the paper, they were clear that Teechan did not use hardware counters.
> Teechan as presented in your paper that I was criticizing wasn't a Lightning network competitor, it's a payment channel competitor. So obviously an apples-to-apples comparison would be appropriate.
Surely for an "apples-to-apples" comparison as you request, CLTV/CSV payment channels don't even compare with LN/Teechan: CTLV/CSV are only unidirectional and they suffer the exhaustion problem. In addition they can only be funded by a single party, so to compare them to bidirectional payment channels like these would be unfair too, no? Also, if you want to compare LN/Teechan pre-segwit, you have the same problem: LN payment channels can only be funded by a single party, in addition, they also require monitoring the blockchain (at the moment). I'm not saying Teechan is the better, I'm saying it has it's own set of advantages/disadvantages and as someone who seems to be pushing back against Teechan a lot, you should know these trade-offs?
> To say that without making it clear that SGX is not in fact something that can be deployed on a whim due to the necessity of getting a license to use a SGX application in production is quite dishonest, especially in the context of the Bitcoin segwit debate that you positioned Teechan within.
Granted, although this might be the biggest challenge in deploying Teechan today, it's by no means impossible: I know of a few companies who have licenses with Intel. Intel didn't create this stuff to sit on a shelf. And even if you ignore Intel, it seems to me that several companies are now looking into deploying payment channels with trusted hardware. e.g. I'm sure you are aware of Blockstream :)
To summarize, Peter, sometimes you have to give credit where credit is due. I know you might have personal differences with Gun, and I don't want to get between you, but for outsiders who don't really have much technical insight here, you seem to be twisting the facts a little? Sure, you might not agree with the work, but hey, the company you work for seems to like it enough to pay someone to do it (http://jobs.khoslaventures.com/jobdetail.php?jobid=698427)
> I'd appreciate if you linked to those actual deployments, something with a description of how they worked.
I'm not sure if this is it, but it looks like something was recently put online (seems to match the authors names): https://arxiv.org/abs/1707.05454
> Your Teechan performance figures reported in your paper and initial announcement were recorded with those counters implemented in RAM, in such a way that a power outage would put users in a position where they can lose funds.
I don't think they disputed that, in fact iirc, they made that quite clear and even under failure cases where a user's CPU loses power, funds are not completely lost; two options remain, either the counterparty can settle the channel (meaning no funds are lost), or the refund tx comes into play. Of course this isn't ideal, but the point remains, for channels where the difference between the most recent state and the refund state is not enormous, this deployment model can make sense. If you want to avoid this, it can be circumvented with backup power generators etc. But they never tried to hide this fact. If you read the paper, they were clear that Teechan did not use hardware counters.
> Teechan as presented in your paper that I was criticizing wasn't a Lightning network competitor, it's a payment channel competitor. So obviously an apples-to-apples comparison would be appropriate.
Surely for an "apples-to-apples" comparison as you request, CLTV/CSV payment channels don't even compare with LN/Teechan: CTLV/CSV are only unidirectional and they suffer the exhaustion problem. In addition they can only be funded by a single party, so to compare them to bidirectional payment channels like these would be unfair too, no? Also, if you want to compare LN/Teechan pre-segwit, you have the same problem: LN payment channels can only be funded by a single party, in addition, they also require monitoring the blockchain (at the moment). I'm not saying Teechan is the better, I'm saying it has it's own set of advantages/disadvantages and as someone who seems to be pushing back against Teechan a lot, you should know these trade-offs?
> To say that without making it clear that SGX is not in fact something that can be deployed on a whim due to the necessity of getting a license to use a SGX application in production is quite dishonest, especially in the context of the Bitcoin segwit debate that you positioned Teechan within.
Granted, although this might be the biggest challenge in deploying Teechan today, it's by no means impossible: I know of a few companies who have licenses with Intel. Intel didn't create this stuff to sit on a shelf. And even if you ignore Intel, it seems to me that several companies are now looking into deploying payment channels with trusted hardware. e.g. I'm sure you are aware of Blockstream :)
To summarize, Peter, sometimes you have to give credit where credit is due. I know you might have personal differences with Gun, and I don't want to get between you, but for outsiders who don't really have much technical insight here, you seem to be twisting the facts a little? Sure, you might not agree with the work, but hey, the company you work for seems to like it enough to pay someone to do it (http://jobs.khoslaventures.com/jobdetail.php?jobid=698427)