< luke-jr>
gmaxwell: so you custom made a private key based on the required signature?
< jl2012>
luke-jr: I think it's key recovery
< luke-jr>
jl2012: ?
< jl2012>
gmaxwell's tx
< luke-jr>
looks like the script is checking the hash of the signature rather than the pubkey
< jl2012>
public key recovery
< luke-jr>
but the signature needs to commit to the input txid
< luke-jr>
since the pubkey is not restricted, however, I assume the spender can just calculate a privkey from the signature + data, and provide the pubkey for that
< jl2012>
no you can't
< jl2012>
but with signature + data, you could have the pubkey
< jl2012>
but you don't know the private key
< jl2012>
if you could know private key this way, ECDSA is broken
< luke-jr>
hmm
< gmaxwell>
I didn't create that txn, someone on bct linked it asking for what was happening there, it's amusing though.
< arubi>
was trying to see if anyone who was implementing their own verifier would be forked off testnet. nobody came forward so I guess we're ok :)
< arubi>
well R+N is the valid X coordinate, but since we do % N, this non X coordinate R is what's left
< arubi>
R+N < P
< gmaxwell>
oh it's a wrap case, okay. whew.
< gmaxwell>
I thought you were saying that R (the point) wasn't on the curve, rather than r (the scalar, R.x mod P).
< arubi>
oh yes, capitalization is important
< gmaxwell>
The former shouldn't verify.
< gmaxwell>
reminds me that we need to add a case where R.x -> r overflows in signing to the libsecp256k1 tests.
< gmaxwell>
arubi: sadly a lot of places don't run testnet nodes...
< gmaxwell>
arubi: looks like webbtc is stuck as of the 4th in fact.
< gmaxwell>
the first block it's missing is 00000000021d4ec041244b516e55d35f733ba8a1f538d26764b67e881b2e030f
< arubi>
gmaxwell, yea, too bad.. not many stake holders like to keep an eye on testnet.. maybe when it's reset sometime it'll give people a chance to start a node
< gmaxwell>
would be nice to know why it's rejecting that block.
< gmaxwell>
it's seen it but considers it orphaned.
< gmaxwell>
(so I wonder if it thinks its invalid)
< arubi>
interesting. looks like a simple block to validate. will check when I'm back from work, cheers
< gmaxwell>
yea, I don't see any obvious stunts in it.
< gmaxwell>
it may just be that the site didn't survive a long reorg.
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #9435: Removed unused variable in test, fixing warning. (master...pr/coins-unused) https://github.com/bitcoin/bitcoin/pull/9435
< gmaxwell>
warren: do you know anything about https://www.ringingliberty.com/bitcoin/ ? doesn't appear to have a determinstic build process, anyone looked to see if these binaries are backdoored? someone wandering into #bitcoin is using them.
< robert__>
its the first result when you google fedora bitcoin
< luke-jr>
is it intentional that CCoinsViewMemPool::Cursor doesn't work? :x
< sipa>
luke-jr: CCoinsViewMemPool is generally broken
< sipa>
it only works for a few use cases
< luke-jr>
sipa: should I go ahead and document this? "* Its Cursor also doesn't work. In general, it is broken as a CCoinsView implementation outside of a few use cases." or something