< jonasschnelli>
IMO SGX lays a floor for "next generation backdoors"
< TD-Linux>
the scare of that is possibly one reason intel licenses the feature
< jonasschnelli>
But only intel knows... I guess they can hand out licenses to who they want including all sorts of "agencies"...
< TD-Linux>
jonasschnelli, that ship has already sailed with the ME, which has much more power than SGX.
< jonasschnelli>
Yeah,... ME is worse. But if users starts to trust SGX (with the ledger or similar), intel as "indirect access" to keys.
< jonasschnelli>
It may gives a very wong sense of security to users...
< jonasschnelli>
(I guess we are OT here, but since nobody complains and gmaxwell posted the URL we continue)
< TD-Linux>
jonasschnelli, SGX can only talk with its parent process
< jonasschnelli>
TD-Linux: but AFAIK some researchers showed cache attacks via other enclaves
< TD-Linux>
yes, those are identical to normal cross process or cross VM cache attacks
< TD-Linux>
I think it's reasonable to say that SGX is no worse than no SGX, but not as good as a hardware wallet.
< jonasschnelli>
TD-Linux: Indeed.
< jonasschnelli>
But
< jonasschnelli>
The part that can make it worse is the eventually false sense of security. Corporations may consider storing keys via SGX rather then a completely decoupled environment / HSM
< bitcoin-git>
bitcoin/master 822755a Pieter Wuille: Fix: make CCoinsViewDbCursor::Seek work for missing keys...
< bitcoin-git>
bitcoin/master 513da90 Gregory Maxwell: Add test for empty chain and reorg consistency for gettxoutsetinfo.
< bitcoin-git>
bitcoin/master b4b057a Pieter Wuille: Merge #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo....
< bitcoin-git>
[bitcoin] sipa closed pull request #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo. (master...test_more_gettxoutset) https://github.com/bitcoin/bitcoin/pull/10445
< cfields>
sipa: maybe i misunderstood your question, then
< sipa>
i think you can just delete the else branch
< sipa>
and leave addrConnect.nServices untouched
< sipa>
and if you think you can't, then my understanding of the code is probably wrong
< cfields>
sipa: look at line 1799. in the event that we _don't_ have our quota of preferred outgoing nodes yet, but we've selected a last resort after 40 tries, we're only expecting NODE_NETWORK from it
< sipa>
ah, yes!
< sipa>
of course
< sipa>
utACK
< cfields>
phew, you had me scrutinizing that really hard :)