#tlsnotary-chat

waxwing: nothing particular

just updated the websites in the question

no response from tether.to

can't get anything done today, too busy reading this crazy crazy "news"...

i posted a link here last night

the same one i got 100 upvotes for

oakpacific: ah yes, that was indeed a good one :)

it must be knowledge within a small circle long time ago

oakpacific: i was thinking, if it turned out that the DPR/SR coins were actually gox coins, then it's a shame the feds sold most of them off eh.

only 200k so far, so other than the 200k already found, 250k's destiny is still undecided

it appears that the goxxings will continue until morale improves.

it's just our massive and painful divorcing process from gox's legacy

i think the State would like the married couple to stay together as long as possible

well at least they don't seem to like the idea of karpeles behind slikroad

this actually answers one of my questions long ago

SR's mixer only mixed coins going into SR itself

which are all suspicious on their own

so how does the mixing make sense

i see

but where would it get the other non-sr utxos from?

btw, maybe you knew it, but this is interesting: http://antilop.cc/sr/

waxwing: that's exactly what i was saying: there was apparently no non-sr coins

which didn't make sense to me

oakpacific: i'm saying: if they *wanted* to get non-sr utxos to mix with, where would they get them?

gox, then nowhere

buterin responds to me in his usual terse style :) https://www.reddit.com/r/Bitcoin/comments/2sjwr...

i have noticed the same trait on similarly brillant people, e.g., gmaxwell

always try to squeeze as much information as possible in one single post

it's no exaggeration to say they could put in one post someone's life's worth of learning

omg, when can i have 120 people paying attention to my TLSNotary post? let alone trying it out

120 isn't cool. You know what's cool? 120,000 :)

writing this down in case i forget it: imagine 2 arbitrators, both have to commit to their arbitration verdict and then reveal. if disagree, N other arbitrators check. the "loser" gets punished.

not a tlsnotary specific idea of course

waxwing: i am pondering about the fundamental question of the different natures of consensuses

also, the practical problem is how to bootstrap the network, such a scheme would work when we have already have a considerable number of arbitrators, but can't protect us when there are only a few

yeah, like i say, more just about decentralised arbitration, than about tlsnotary

waxwing: it would be greatly appreciated if you can spare a minute to mail partners@bitreserve.org

oakpacific: sure, just send it to me. is that what you mean?

waxwing: i can write the text no problem

but just say we see that you are interested in proving your bank balance, and we have a software that can do it without accessing the account is ok

oakpacific: you sure you don't want to write it? i don't know anything about it :)

waxwing: well, they are basically like tether.to, we shouldn't pretend to know more than we do i guess

just talking about proving bank balance

and my english is not as good

i'll proofread no problem :)

i can send it from the group mail

waxwing: cool

oakpacific: mkarrer : this is what i was talking about last couple of days. robert sams' stablecoins idea: i think this whitepaper is excellently written

a pure market (auction) mechanism to separate speculative demand from transactional demand

waxwing, how is tls downgrade handled ? the server must respond with a lower tls version?

dansmith_btc: hang on a sec

dansmith_btc: ok, now i have to remember :)

i believe the server provides its suggestion in the server hello

the biggest surprising thing to pay attention to is that the tls version in the premaster secret must be the same as what was originally suggested in the client hello, not the lower version negotiated during the handshake

dansmith_btc: i believe what i wrote there is basically correct, in particular see the 'server version' field of server hello in the RFC. Is that enough info?

oh ffs .. http://siliconangle.com/blog/2015/01/16/bitcoin...

waxwing, i grepped tlsn_ssl for tlsver and I cant see where the version in server hello is checked. I would expect it to be done in start_handshake but it is not done there.

dansmith_btc: ok hang on, i'll take a look

waxwing: re: the news 'u wot m8?"

dansmith_btc: sorry it took so long, but the downgrade is here: https://github.com/tlsnotary/tlsnotary/blob/mas...

i think that check_complete_records should now be unnecessary actually; i think its work has been replaced by tls_record_decoder etc. in the ssl.py file

not sure exactly why i chose to put it there.

oakpacific: you'll have to give me more than that :)

dansmith_btc: if you want me to expand on what i just said, let me know.

waxwing: i was referring to the article's author

ok. still don't get it

well, the title is plain wrong, so...

you mean because it says egopay is a bitcoin thing?

yeah, egopay simply cannot be called a bitcoin payment processor

it's a e-wallet platform that has existed many years before bitcoin

right, that was my first thought when i saw the article, but i wasn't sure. so my 'ffs' was a mixture of that and the fact that ... people keep running off with the (various types of) money :)

dansmith_btc: if you understood what i said above, then to continue the thought, i'm wondering if it makes a lot more sense to put the downgrade check in the TLSServerHello constructor.

waxwing, ok, that makes sense now. Although checking every record for a downgrade is a hack. Also, what if reliable site PMS uses 1.1 but the audit site downgrades to 1.0 - then the prepared PMS will be rejected by the audit site because the prepared PMS contains 1.1

a couple of things

first, it's not every record, but every handshake record

but i agree, we should put it somewhere else e.g. serverhello constructor

re: reliable site vs audit site. i thought i had this figured out, but now i'm confused again. let me have a think.

ah yes

the point is what i said above; the PMS must use *what the client hello originally suggested* , not what is negotiated afterwards

this is really lucky for us

because without that foible, we would not be able to do downgrades.

so we always suggest 1.1, so 1.1 is what appears always in the PMS starting bytes.

dansmith_btc: is it making sense?

ah, ok, thanx, making sense now.

waxwing: hoho, finally get back the key

waxwing: do you remember the time you signed into the group email account

google has shown a sign-in attempt from Lamaca Cyrpus at Jan 11