1 2013-10-06 00:13:22 <jgarzik> Luke-Jr, baby bedtime @ home
2 2013-10-06 00:14:44 <Luke-Jr> o
3 2013-10-06 01:08:59 <jgarzik> gmaxwell, That's an interesting side problem. Is there any way for p2pool-like system to buffer funds, paying less now, and more in the future without a centralized SPOF holding funds?
4 2013-10-06 01:09:15 <jgarzik> I often wonder what a network of bots, run by trustec members of the community, could do
5 2013-10-06 01:09:45 <jgarzik> oracles on TPM run by trusted community members, for e.g. holding funds until a condition is met, behaving as a neutral third party
6 2013-10-06 01:10:30 <jgarzik> a network of cross-validating agents is the only solution I can come up with, but surely there is a fancy-math way for p2pool to do it without oracles
7 2013-10-06 01:39:18 <boycey> Hi. the steps to convert 64 byte public key to 20 byte key: RIPEMD160(SHA256(pubkey)) â¦.. right ??
8 2013-10-06 01:40:24 <boycey> why it no work for me :(
9 2013-10-06 01:44:15 <berndj> boycey, how exactly are you calculating it?
10 2013-10-06 01:44:29 <berndj> are you using the right endianness?
11 2013-10-06 01:46:22 <boycey> berndj: do i have to convert it before i do the hashing ?
12 2013-10-06 01:47:14 <boycey> i think its already little endianâ¦.. i just copied the key from the blockchain raw tx
13 2013-10-06 02:54:55 <tim-tams> anyone here?
14 2013-10-06 03:16:11 <gavinandresen> tim-tams: no, nobody.
15 2013-10-06 03:16:27 <tim-tams> hey
16 2013-10-06 03:18:25 <tim-tams> All I want to do is display total_received for an address in html/javascript. How on earth can I query that from an API and display BTC not satishis? It sounds so simple but I'm blanking
17 2013-10-06 03:18:45 <tim-tams> Right now I'm iframing the Blockchain.info api, but that uses satoshis not btc
18 2013-10-06 03:19:50 <gavinandresen> blockchain.info has a JSON API, I think. Shouldn't be hard to write some javascript that calls it then converts satoshis to BTC.
19 2013-10-06 03:20:34 <tim-tams> I know, but I know nothing about javascript/json
20 2013-10-06 03:20:39 <tim-tams> or anything really
21 2013-10-06 03:20:51 <gavinandresen> ⦠although I've forgotten most of what I used to know about javascript coding, so there might be cross-origin issues...
22 2013-10-06 03:20:54 <tim-tams> it should take like 3-4 line but like I said, I know nothing
23 2013-10-06 03:20:57 <tim-tams> lines**
24 2013-10-06 03:21:43 <gavinandresen> tim-tams: a javascript channel might be a better place to ask. This channel is for working on bitcoin itself.
25 2013-10-06 03:22:22 <gavinandresen> tim-tams: or, actually, the bitcoin stackexchange site might be good place to ask
26 2013-10-06 11:49:50 <swulf--> is anyone working on proof of sacrifice-related contributions?
27 2013-10-06 11:54:31 <jgarzik> swulf--, yes
28 2013-10-06 11:55:00 <jgarzik> swulf--, as part of the decentralized identity protocol https://en.bitcoin.it/wiki/Identity_protocol_v1
29 2013-10-06 11:56:38 <swulf--> ah, neat
30 2013-10-06 11:56:47 <swulf--> thanks for the link
31 2013-10-06 12:09:19 <swulf--> jgarzik: is an implementation of that identity protocol something that would be welcome in the bitcoin reference implementation?
32 2013-10-06 12:10:14 <jgarzik> swulf--, it would need a use case
33 2013-10-06 12:11:39 <jgarzik> swulf--, as much as I think the identity protocol is critical to a decentralized future cannot add it to Bitcoin-QT without a relevant use. Right now, there is not much use at all for identity in the reference client -- but there is /much/ need for decentralized identity in the surrounding ecosystem: bitcoin websites, pools, ...
34 2013-10-06 12:11:53 <swulf--> right
35 2013-10-06 12:11:56 <jgarzik> swulf--, so my approach is to add support for SINs to various libraries
36 2013-10-06 12:12:07 <swulf--> I suppose that makes sense at this point
37 2013-10-06 12:12:24 <swulf--> wouldn't identity be useful in the new payment requests code?
38 2013-10-06 12:12:27 <jgarzik> swulf--, patches to add SIN to python-bitcoinlib and picocoin would be merged immediately, for example and we need more test vectors
39 2013-10-06 12:12:33 <jgarzik> swulf--, IMO yes
40 2013-10-06 12:12:59 <swulf--> I mean, it sounds like the payment requests will be relying on SSL/X.509, which is centralized
41 2013-10-06 12:13:18 <jgarzik> swulf--, yes, SIN could be a decentralized alternative used in the payment protocol
42 2013-10-06 12:13:30 <swulf--> but "later" I presume?
43 2013-10-06 12:13:36 <jgarzik> payment protocol is intentionally flexible, permitting more than just SSL CAs
44 2013-10-06 12:13:54 <swulf--> that's good
45 2013-10-06 12:14:34 <jgarzik> swulf--, it could be "now" -- but just needs someone to code it up and use it. cannot make "add SIN support to Bitcoin-QT payment protocol" the first step, but one of the last
46 2013-10-06 12:14:52 <jgarzik> thus a tested use case -> easy to justify inclusion in bitcoin/bitcoin.git
47 2013-10-06 12:15:13 <jgarzik> BitPay is using SINs a bit internally
48 2013-10-06 12:15:19 <swulf--> are they?
49 2013-10-06 12:15:21 <swulf--> cool
50 2013-10-06 12:16:02 <swulf--> I suppose a simple use-case would be to identify the owner of an address to a SIN
51 2013-10-06 12:16:17 <swulf--> "yes, it was indeed *I* that paid you"
52 2013-10-06 12:16:20 <jgarzik> well, let me qualify -- I think it is fine to go ahead and create a SIN support patch for bitcoind. Just expect that it will not be merged for months, due to above constraints.
53 2013-10-06 12:16:31 <jgarzik> swulf--, yes
54 2013-10-06 12:16:32 <swulf--> which means constant rebasing
55 2013-10-06 12:16:52 <jgarzik> swulf--, not so much most of the code would be in new files, with just a little bit of patched in glue
56 2013-10-06 12:17:05 <swulf--> fair enough
57 2013-10-06 12:20:24 <swulf--> this wouldn't be too difficult to code up into bitcoind, but I think there'd be some UI requirements to manage identities, no?
58 2013-10-06 12:24:07 <jgarzik> swulf--, probably yes
59 2013-10-06 12:24:26 <jgarzik> swulf--, the first step is simply to get bitcoind-level library routines into the codebase
60 2013-10-06 12:24:41 <swulf--> and associated rpc calls to work with ti
61 2013-10-06 12:25:04 <jgarzik> swulf--, store identities in the wallet (they require keeping private keys safe, after all), add RPC support sign/verify message
62 2013-10-06 12:25:30 <swulf--> right
63 2013-10-06 12:27:32 <swulf--> SIN records don't have an immediately obvious place to go currently
64 2013-10-06 12:28:00 <swulf--> I suppose they could also be in a transaction in the form of a special scriptPubKey
65 2013-10-06 12:28:10 <jgarzik> swulf--, correct. My weak idea was a namecoin namespace "sin/" or whatever: http://dot-bit.org/Namespace
66 2013-10-06 12:28:28 <jgarzik> rationale: namecoin is there right now, even if it's not great
67 2013-10-06 12:28:54 <jgarzik> swulf--, would need to add SIN verification, to make sure SIN record updates are digitally signed
68 2013-10-06 12:29:05 <swulf--> naturally
69 2013-10-06 12:29:42 <swulf--> yeah, people could build some really cool stuff by combining bitcoin+bitmessage+namecoin
70 2013-10-06 12:30:04 <jgarzik> namecoin is a bit ailing, but it has network strength because it's easy income for merged miners, so it is stronger than any chain I would set up from scratch
71 2013-10-06 12:31:07 <swulf--> would it be terrible to use specially formatted transactions for sin records?
72 2013-10-06 12:31:08 <jgarzik> bitmessage could just use SINs for identities. if you had a SIN that was generated with a sacrifice, you can bootstrap some trust based on that, rather than just raw proof-of-work, in some cases.
73 2013-10-06 12:31:23 <swulf--> good point
74 2013-10-06 12:31:29 <conman> finding a use for namecoin would be nice
75 2013-10-06 12:31:31 <jgarzik> swulf--, not sure what you mean. on the namecoin chain, bitcoin chain, or other?
76 2013-10-06 12:31:45 <conman> it refuses to die
77 2013-10-06 12:31:53 <swulf--> publishing SIN records in the bitcoin chain via scriptPubKey
78 2013-10-06 12:32:00 <jgarzik> swulf--, meh
79 2013-10-06 12:32:18 <swulf--> or a similar method to mastercoin
80 2013-10-06 12:32:37 <swulf--> maybe SINs would be best in something like mastercoin anyway
81 2013-10-06 12:32:40 <jgarzik> swulf--, would prefer to avoid that sort of thing. your SIN record might contain some image data
82 2013-10-06 12:32:57 <swulf--> yeah, definitely, just thinking of the possibilities out loud :)
83 2013-10-06 12:33:05 <jgarzik> swulf--, you can certainly /timestamp a hash/ on the main chain. that is the critical part.
84 2013-10-06 12:33:12 <jgarzik> once timestamped, the data may be presented out-of-band
85 2013-10-06 12:33:14 <swulf--> yea
86 2013-10-06 12:33:55 <jgarzik> so on the main chain, you could timestamp your own SIN records, as perhaps an alternative to namecoin
87 2013-10-06 12:34:15 <jgarzik> you can also store it in an DHT, provided there is a protocol to track signature chains
88 2013-10-06 12:35:12 <jgarzik> i.e. store the "initial SIN record" in namecoin, then prove with an out-of-band signature chain updates to the SIN record. It is not globally consistent (you might present different chains to different people), but it is provable.
89 2013-10-06 12:35:34 <swulf--> could work
90 2013-10-06 12:36:18 <swulf--> jgarzik: thanks for the info.. I'm heading out for a brew
91 2013-10-06 12:36:20 <swulf--> :)
92 2013-10-06 13:29:57 <heeventuli> hey guys :) just to make sure i got this right: after mining a block in testnet, it needs 120 other blocks to make the mined coins spendable, right? currently, there are 2-3 blocks mined per hour in testnet..so it will take ~1.5 days before i can actually test me send-to method?
93 2013-10-06 13:56:22 <skinnkavaj> Hello anyoe good with wordpress and want to earn 10 euros for a job i think takes 5 min? i need to fix so that the "contact" page in wordpress forwards all messages to an email.
94 2013-10-06 14:16:33 <flatfly> what randomness source does bitcoin-qt use on windows? cryptgenrandom?
95 2013-10-06 14:19:53 <grau> skinnkavaj: LOL offering euros on bitcoin-dev
96 2013-10-06 14:23:08 <Diapolo> perfmon data, CPU performance counter and RAND_screen() from OpenSSL on init + OpenSSLs way of gathering entropy
97 2013-10-06 14:30:02 <flatfly> Diapolo: thanks
98 2013-10-06 14:33:41 <flatfly> VanityGen also uses the OpenSSL RNG - does anyone know if it is also the case for Armory?
99 2013-10-06 14:33:46 <Diapolo> you're welcome
100 2013-10-06 14:35:09 <flatfly> nvm, i'll have a look at Armory's source code
101 2013-10-06 15:35:41 <Belxjander> jgarzik: do you ever go to #bitcoin-tech?
102 2013-10-06 16:49:36 <gmaxwell> sipa: http://bitcoin.sipa.be/speed-lin-2k.png You're off-scale again.
103 2013-10-06 16:53:12 <_dr> set autoscale yfixmax
104 2013-10-06 16:54:17 <_dr> if autoscale doesn't work as intended
105 2013-10-06 16:55:12 <gmaxwell> _dr: I think the issue is that we don't want it changing willynilly from reload to reload.
106 2013-10-06 16:58:07 <_dr> gmaxwell: yeah, i thought so. in some cases yfixmax worked for me when autoscaling didn't. it will extend the y-axis to the highest y-value encountered.
107 2013-10-06 16:58:51 <grau> wow, 30day estimate for growth implies difficulty doubling in 30 days.
108 2013-10-06 17:06:05 <orion> Hi. The FreeBSD port net-p2p/bitcoin does not compile.
109 2013-10-06 17:06:35 <_dr> grau: yeah. that's the consequence of ~30% increases
110 2013-10-06 17:07:30 <orion> http://pastebin.com/ADK1rzZD
111 2013-10-06 18:04:03 <jgarzik> Belxjander, no, way too many channels as it is :)
112 2013-10-06 19:29:01 <Vinnie_win> sup peeps
113 2013-10-06 20:17:56 <saivann> I plan to merge the new innovation page tomorrow on bitcoin.org
114 2013-10-06 20:17:57 <saivann> https://github.com/bitcoin/bitcoin.org/pull/224
115 2013-10-06 20:18:05 <saivann> More reviews and proofreading are welcome
116 2013-10-06 20:18:33 <saivann> Though this page might be improved by TD soon after the merge
117 2013-10-06 22:15:41 <sphered> hi
118 2013-10-06 22:16:52 <sphered> process of testing a sha coin. i have successful created the Merkel hash having some issue with genesis blocks any ideas?