00:18:44Guest39617:Guest39617 is now known as maaku
00:33:47kanzure:"existing ratio incentives on private trackers are vulnerable to collusion" http://www.cis.poly.edu/~ross/papers/private_incentive.pdf
00:45:06kanzure:< user_> yeah i think in the limit, the only way to resist a sybil attack is to abandon the idea of a consensus; you assign resources based on your trust of local people and someone else with a different set of local people is going to make the same resource assignment differently and that's just how it has to be
01:27:22wallet42:wallet42 is now known as Guest46579
01:27:22wallet421:wallet421 is now known as wallet42
01:56:24wallet42:wallet42 is now known as Guest83927
01:56:24wallet421:wallet421 is now known as wallet42
03:13:36sipa:Luke-Jr: for?
03:17:16Luke-Jr:sipa: I forget. I had something to ask you :x
03:22:05sipa:ol
03:22:17sipa:* sipa .sleep(long long);
03:28:12phrackage:Before I go making up my own DB - is there any online service or API that allows me to get the fiat equivalent of historical blockchain transactions (for a couple of popular exchanges)?
03:28:39kanzure:aren't you just repeating your questions over and over?
03:30:03phrackage:kanzure: yes, this is the first repeat... sometimes people come and go on these channels
03:32:21kanzure:yes but those people are jerks and ignorable
03:32:36phrackage:the best response so far is to use the summary information from bitcoincharts... it's not quite exact, since it's homogenised data rather than ticks, but it would do... the glue would have to correlate it afterwards. To do it in any scalable way you'd have to get all the historical data, import it, and then carry on polling their service. I think the API handles historical prices only, so that live service would have to be a
03:32:36phrackage:separate call too
03:33:13kanzure:what does this have to do with wizardry?
03:33:48phrackage:my experience in the past is that the wizards are broader thinkers. -dev is more about modifying bitcoin core. What channel would you suggest?
03:48:44maaku:phrackage: this channel is more about more academic research and long-term bitcoin development
03:49:01maaku:i doubt you'll find an answer to that here, but i don't know where to send you either
04:00:10phrackage:thanks anyway
05:02:54zzyzx:zzyzx is now known as roidster
05:03:24roidster:roidster is now known as Guest83206
08:40:05c0rw|sleep:c0rw|sleep is now known as c0rw1n
10:32:06Luke-Jr:are we seriously shedpainting date formats? :x
11:29:42wumpus:Luke-Jr: sheesh, indeed, I didn't expect someone to disagree on *this*
11:30:54wumpus:Luke-Jr: let's just change the dates to ISO 8601 and be done with it
11:49:52Emcy:dd mm yy
13:26:38Guest67709:Guest67709 is now known as [Tristan]
15:00:50petertodd:Emcy: d1m1 d2y1 m2y2 is my preferred format - like how old vaxen compromised between little endian and big endian to create middle endian
15:02:45Emcy:its not 1974 any more gramps
15:03:35sipa:braindead endian, you mean?
15:07:47petertodd:sipa: the politically correct term is greymatter impaired
15:12:11sipa:how about "intellectually challenged" ?
15:13:11petertodd:sipa: well, you did imply said greymatter was dead, not mearly defective
15:14:10sipa:fair enough
17:05:11guy123:hi
17:07:38guy123:I have an interesting puzzle I've been thinking of
17:07:49guy123:is there a way to break the fact that private keys imply what public key they belong to?
17:08:34guy123:like with a nonce or anything else - would it be possible for a private key to still decrypt what a public key encrypts, sign something that a public key can verify --- BUT you would have to test it on every public key to know which one it's for?
17:08:44guy123:you can't just 'derive' the public key from the private key. Is that possible?
17:11:27Emcy:i dont think so?
17:12:52guy123:OK
17:13:24guy123:btw I was thinking about how there's no Memo functionality in transactions. (unlike wire transfers). Due to the size - the blockchain would grow too big if everyone could include memos/messages
17:13:40guy123:but couldn't you include a tiny field for a HASH of a memo. Then it could be indisputable what the transaction was actually for. (e.g. legally)
17:14:19sipa:neither belongs there
17:14:23guy123:Like if I send you $1,000,000 and it includes the hash of the memo "For payment for the contract signed on 5/4/2014 in London, UK between ___ and ___ and witnessed by ____". the blockchain would mean that it is indisputable.
17:14:35guy123:whereas if you have to communicate the purpose through an offline memo, then the transaction itself doesn't incldue that
17:14:37sipa:the blockchain is there for data that the world needs to validate that no cheating goes on
17:14:47guy123:"Oh, that $1M. No that's just for an old debt. It has nothing to do with any contract."
17:14:48sipa:memos are private communication between sender and receiver
17:14:53guy123:yes
17:14:57sipa:there's no point to burden the entire world with it
17:14:59Emcy:there are already thing for stuffing the chain full of arbitrary shit
17:14:59guy123:but the memo could describe the purpose
17:15:03sipa:just send it to the receiver directly
17:15:08guy123:but that's not proof
17:15:11sipa:no need for it to be part of the transaction
17:15:24guy123:the receiver could say, "Actually the sender told me that this is for an old debt. It's not a payment for anything"
17:15:31guy123:the receiver could fabricate such an email, for example.
17:15:37guy123:but the hash of the email wouldn't be in the transaction.
17:15:37sipa:there are ways around that
17:15:46guy123:what is the way around that?
17:16:02sipa:i first send you the memo along with a non-signed version of the transaction
17:16:15sipa:the receiver's identity signs that, with a note "accepted for payment"
17:16:22sipa:only then you give the fully signed transaction
17:16:53sipa:without the acceptance note, he doesn't get the money
17:17:03sipa:and with it, there is no way to afterwards claim the opposite
17:17:29guy123:that is true
17:17:32guy123:but it requires interactivity
17:17:43sipa:every payment does
17:17:55sipa:they need to tell you what address to pay to, for starters
17:18:21sipa:there are some ways to avoid that (like stealth addresses) which are useful for anonymous payments
17:18:33sipa:but those don't have need for private communication between sender and receiver either
17:18:56guy123:You could run an advertisement with a stealth address on TV saying, "Send 0.005 btc to (stealth address) with your email in the memo, to sign up for our newsletter, and verify by confirming on bitcoinmemos.com" or whatever, some outside channel where they can communicate the transaction ID and the memo
17:19:14gmaxwell:sipa: he wants pay to contract.
17:19:26sipa:meh
17:19:48guy123:or just some way for the intent to be coded into the memo
17:19:59guy123:into the transaction*
17:20:04gmaxwell:guy123: there is no guarentee anyone saw your 'intent'
17:20:04guy123:even as a 20-byte sha-1 hash
17:20:09guy123:that's true
17:20:15guy123:but the receiver could always ask
17:20:17Emcy:theres already a thing for sticking 40 bytes of hash into the chain
17:20:20gmaxwell:"Here is 1 btc for your house, kthnx"
17:20:27guy123:"Hey, I don't know what memo this hash is. What is it?"
17:20:36guy123:And fi they don't get an answer from you they can just send you the money back.
17:20:43sipa:imho all these tricks people come up with to avoid bidirection communication for transactions leads to far more problems then they solve
17:20:54sipa:email also requires bidirectional communication between servers
17:21:03gmaxwell:guy123: outputs are distinctive, it's none of your business what some output not paying you is. OP_RETURN is not a memo field.
17:21:04guy123:Emcy - what does that 40 byte trick use? (Whcih is plentyh for a hash)
17:21:21gmaxwell:guy123: what you sould probably do in your case is just get a sign message from the recieving key in advance.
17:21:23Emcy:its not a trick, its "officially sanctioned"
17:21:46guy123:exactly, the positive about "here is 1 btc for your house, kthnx" is that if you memo'd "return small debt" then you couldn't later claim it was part of a contract.
17:22:02guy123:Emcy - what is that hash for?
17:22:03gmaxwell:Emcy: it is a "trick" but its a seperate output, and it's absolutely NONE of the recivers business whats in a different output from the one paying them.
17:22:11guy123:and what does it use? Why isn't it used for hashing a memo?
17:22:24Emcy:you can put anything you want in it
17:22:35guy123:ah okay
17:22:39guy123:so actually it already exists
17:22:43gmaxwell:guy123: Did you see: 10:21 < gmaxwell> guy123: what you sould probably do in your case is just get a sign message from the recieving key in advance.
17:22:47guy123:it c ould be used for what i'm talking about
17:22:59guy123:gmaxwell - I get what you're saying
17:23:08gmaxwell:That does precisely what you want.
17:23:10guy123:I'm asking about without anything prior from the receiver
17:23:15guy123:like a memo field on a bank transfer
17:23:24sipa:guy123: read the payment protocol
17:23:28guy123:if you know someone's IBAN and BIC/SWIFT code in banking, you can send them any amount with any memo.
17:23:37sipa:bitcoin transactions are not the equivalent of bank transfers
17:23:41gmaxwell:guy123: but a memo is not a binding agreement.
17:23:51sipa:they are the equivalent of a coin in someone's wallet moving to someone else's
17:24:00Emcy:you know back in the stone age when IP-IP txn existed, you could zap a little message right to your recipient
17:24:08sipa:we need to protocols on top to represent "payments" rather than just individual coin movements
17:24:09gmaxwell:Otherwise, give me your SWIFT code and I'll be taking your house with a "Here is $1 in payment for your house/wife/kids, kthnx" :)
17:24:14sipa:the payment protocol does that
17:24:18sipa:and it adds a memo field
17:24:26Emcy:cool
17:24:38Emcy:payment protocol it is then
17:25:13sipa:in the payment protocol, you indeed need bidirectional communication, but almost always you already have that anyway in a merchant situation
17:25:29sipa:but you do end up with a signed message accepting your transaction with the memoy
17:25:43Emcy:the PP works on any channel right not just p2p
17:25:47Emcy:so bluetooth etc
17:25:49sipa:yes
17:25:56sipa:it's designed to, at least
17:27:00Emcy:i wonder if guy123 ever heard of bitmessage
17:29:35guy123:Emcy, no lol:) I was just goiung on the bitcoin client I'm using and what it supports
17:30:31sipa:#bitcoin-dev, please
17:30:46guy123:btw the big difference is when you hand someone some money physically you can say, "Here, this is for the bananas". If you could include a hashed message, you could do the same thing over PM in some out of band channel. I think it should be supported
17:31:53guy123:you could write to someone 'I just sent you 0.n bitcoins (hash "Here, this is for the bananas")'
17:32:17guy123:anyway it's not important, and as you guys say it's been done :)
17:32:58gmaxwell:guy123: if you're just trying to identify what it's for, the preocedure virtually every business uses is finding out first before you give the reciever the address to pay. This is what the payment protocol does. If you don't do this you can't learn things like where to refund funds.
17:33:27gmaxwell:And its utterly important that transactions be as small as technically possible for scalablity reasons because bitcoin is a global broadcast mechenism.
17:33:31guy123:gmaxwell - oh. I thought you automatically knew who sent you funds, so you would automatically know where to refund funds.
17:33:47gmaxwell:guy123: No, you have no clue.
17:33:48guy123:gmaxwell that makes sense
17:33:56guy123:yes :)
17:34:00gmaxwell:haha
17:34:07gmaxwell:sorry, didn't mean to sound like that!
17:34:11guy123:it's fine :)
17:34:16guy123:I just installed my first client today
17:34:30guy123:and it's not even a full client, just electrum
17:34:38sipa:#bitcoin or #bitcoin-dev, please
17:34:45sipa:this has nothing to do with post-bitcoin development
17:34:51guy123:OK
17:45:31guy123:does someone want to PM me the basic idea behind the implementation of stealth addresses - i.e. how it's possible to break the symmetry and let senders produce a new address by themselves, without knowing all the other ones that have been produced?
17:45:48guy123:I've read some of http://sourceforge.net/p/bitcoin/mailman/message/31813471/ but it's a bit technical
17:47:56Emcy:yeah i wish i could find an explanation-for-morons of that too
17:48:06gmaxwell:guy123: the sender generates a random value. Other people don't know the random value. How is actually works is technical... go read up on diffie hellman key exchange.
17:49:29Emcy:DH requires contact tho
17:50:11guy123:yeah I don't see how it can be DH if it's one-way
17:50:14guy123:I understand DH
17:50:24gmaxwell:then you don't understand DH.
17:50:42guy123:they both have to choose a secret
17:50:58gmaxwell:You do have 'contact' when you pay someone you recieve their address, you send their payment. DH doesn't require anything be synchronous, it works fine async.
17:51:06Emcy:i probably only understand it in context of TLS session setup or something
17:51:08Emcy:thanks wikipedia
17:51:09guy123:I'm wondering how a sender can just view a Stealth Address and use it to generate something that everyone else viewing the Stealth Address can't know about, but will still be immediately visible to the recipient
17:51:25gmaxwell:by using diffie hellman.
17:51:27guy123:gmaxwell, I'm asking int he context of stealth payments
17:52:11guy123:gmaxwell, so if I have your stealth address.. what do I do next that lets me generate a working recipient address that goes to you, but that no one else can know goes to you even if they watch the whole blockchain?
17:52:24guy123:and also if you're watching the blockchain, you do know it goes to you
17:52:47Emcy:why cant it just be magic?
17:54:47guy123:Emcy are you really that put off by an explanation making it into this channel
17:54:50andytoshi:guy123: please, "what is DH" is probably OT here but it is too basic. this channel is for research, and is read in its entirety by several researchers, so we try to keep it both on-topic and low-volume.
17:55:12Emcy:um no not at all
17:55:12andytoshi:oops, by OT i meant ontopic :}
17:55:33guy123:I don't need an explanation of DH...
17:55:53sipa:apparently you do :)
17:55:57guy123:anyway I guess you can keep this channel extremely low-volume if you want.
17:57:48Emcy:i think this place is more for discussing how we are going to bitcoin 10+ years out
18:06:02kanzure:the "memo" idea is also broken because the payer can just lie, and then the lie gets stored in the blockchain. in general third parties wont be able to tell the truthfulness of the memo messages found on the blockchain.
18:36:50guy123:kanzure - it's about not having to decouple the communication so much from the transaction. Of course I can lie and leave you a $5 on your desk with a note saying, "This is for your house" :)
19:51:32gmaxwell:guy123: As was explained to you earlier, bitcoin is not a communications channel, and there are very important reasons that it can't tolerate a bunch of extra capacity to send extra data. Moreover, the rest of the world get along fine. In the US it is _unlawful_ to write note on money when you make payments.
19:52:01gmaxwell:If you want to give someone a note with a payment, hand them the payment and your note over your own communications channel with them. This is what the payment protocol does.
19:55:23guy123:gmaxwell - curious about that reference on law you just quoted
19:55:55guy123:gmaxwell - in a sense payment is a communications channel, as you do not have to actively poll or ask about a transaction before being informed you've just received some money.
19:56:23sipa:#bitcoin-dev please
20:14:21justanot1eruser:Does anyone have a link to a thread describing the history grinding attack used on Peercoin?
20:15:04gmaxwell:it was discussed on the forum but I dunno where the thread is.
20:15:48justanot1eruser:Any other discussions or explanations I can find?
20:41:05warren_2:warren_2 has left #bitcoin-wizards
21:49:43wallet421:wallet421 is now known as wallet42
22:57:24forrestv:maaku, can you explain more why you can't trust the midstate? it seems to me that if there is a valid commitment at the end of the coinbase transaction, it doesn't matter whether it's in a larger pushdata or not
22:58:55forrestv:is it only relevant when miners are validating commitments and blocks have the option of having no commitments?
23:47:12ghtdak:ghtdak has left #bitcoin-wizards
23:54:13maaku:forrestv: yes, it's only relevant when miners are validating commitments, but that is where this is headed