1 2015-04-11 00:07:23 <lechuga_> anyone count recently how close we are to 75% v3 block majority?
 2 2015-04-11 00:13:03 <sipa> lechuga_: http://bitcoin.sipa.be/ver-50k.png
 3 2015-04-11 00:13:09 <sipa> updated hourly
 4 2015-04-11 00:13:16 <lechuga_> ah sweet thx
 5 2015-04-11 02:07:04 <gmaxwell> lechuga_: 0.10.1 will be out quite soon, which may give it a bump.
 6 2015-04-11 02:27:25 <phantomcircuit> sipa, it's not inefficient enough for me to really care very much
 7 2015-04-11 02:30:12 <Luke-Jr> 
ACTION should finish v3 block support for Eloipool

 8 2015-04-11 02:33:55 <phantomcircuit> just enough to leave a comment for later
 9 2015-04-11 02:34:04 <phantomcircuit> sipa, (also i'd like to not make this pr any larger)
10 2015-04-11 02:34:20 <phantomcircuit> which is why im not #define'ing the constants used
11 2015-04-11 02:34:31 <phantomcircuit> which can be trivially reviewed
12 2015-04-11 03:16:59 <gmaxwell> Interesting contrast between the comments here and the usual thinking; https://bitcointalk.org/index.php?topic=1019656.0
13 2015-04-11 12:53:16 <CidonaBoy> Hey everyone!
14 2015-04-11 12:53:17 <CidonaBoy> A question for ye, if ye don't mind: There are some bitcoin wallets out there that keep track of your balance without downloading the blockchain. Can I ask how they do that? Do they connect to some central service that keeps running totals? Looking at the protocol spec (https://en.bitcoin.it/wiki/Protocol_specification) there doesn't appear to be any command that retrieves the balance of an...
15 2015-04-11 12:53:19 <CidonaBoy> ...address.
16 2015-04-11 12:54:28 <sipa> CidonaBoy: that, or they use SPV
17 2015-04-11 12:54:45 <sipa> see the bitcoin whitepaper + bip 37 for details
18 2015-04-11 12:55:11 <CidonaBoy> Will take a look, thanks. :)
19 2015-04-11 12:55:40 <sipa> also, addresses do not exist at the protocol level
20 2015-04-11 12:56:08 <sipa> and they certainly do not have a balance - that is a local abstraction provided by wallets
21 2015-04-11 14:42:54 <phantomcircuit> CidonaBoy, to be clear not all "bitcoin" wallet software is actually bitcoin wallet software
22 2015-04-11 14:43:12 <phantomcircuit> some of them are just tracking a central ledger
23 2015-04-11 15:03:44 <Eliel> (which tend to be kept up to date with the bitcoin ledger, but you have to trust the provider on that on those cases)
24 2015-04-11 15:23:20 <andytoshi> sipa: with libsecp256k1 commit a9b6595 (introduce explicit contexts) the whole lib is now threadsafe?
25 2015-04-11 15:25:10 <andytoshi> is in, all data used is local?
26 2015-04-11 15:48:29 <DanMAbraham> moarrr: Is it dangerous to sign your Public Bitcoin Key with your Private Bitcoin Key? [ECDSA]
27 2015-04-11 15:51:49 <andytoshi> moarrr: no
28 2015-04-11 15:52:15 <moarrr> andytoshi: it is not dagenrous to sign a raw public key 1....etc.. with the corresponding private key? :)
29 2015-04-11 15:52:16 <moarrr> thanks
30 2015-04-11 15:52:19 <moarrr> i should be ok then
31 2015-04-11 15:52:28 <andytoshi> moarrr: it is not dangerous (in the cryptographic sense, not in the real-life "having your signature on random things" sense) to sign anything which an attacker could have access to
32 2015-04-11 15:52:46 <andytoshi> which for a digital signature includes the pubkey, even tho in bitcoin this is usually not exposed
33 2015-04-11 15:53:32 <andytoshi> basically, everything except the private key and (non-constant) functions of the private key are OK
34 2015-04-11 15:54:47 <andytoshi> ...and even then, since the data is run through a hash function which is modelled as a random function, you'd be ok, but this is outside of the security property for the signature
35 2015-04-11 15:55:45 <moarrr> Ok, was just worried someone might derive my Private Key from the signature
36 2015-04-11 15:55:50 <moarrr> I should be ok so I am happy :)
37 2015-04-11 16:01:29 <Luke-Jr> moarrr: from multiple signatures (of anything), there could be a risk, though
38 2015-04-11 16:01:43 <moarrr> oh ok Luke-Jr
39 2015-04-11 16:01:53 <moarrr> so I shouldnt sign the same thing with the same key multiple times?
40 2015-04-11 16:02:16 <moarrr> 
ACTION signed his public key with his private key and posted it publicly on facebook

41 2015-04-11 16:02:40 <Luke-Jr> it'd be better not to make a habit of it. if you're careful and the software isn't buggy, you'll *probably* be okay though
42 2015-04-11 16:03:07 <Luke-Jr> it's not as bad as address reuse, at least, if you're just signing messages
43 2015-04-11 16:04:35 <moarrr> hehe it was blockchain.info - doesnt have the best rep
44 2015-04-11 16:04:42 <moarrr> some r number worrysomeness i heard about on reddit
45 2015-04-11 16:04:56 <moarrr> i reuse the same address for anything i do in public ...
46 2015-04-11 16:05:06 <moarrr> but i try not to use it too many times to transact with
47 2015-04-11 16:05:16 <moarrr> i can always use paper wallets, etc...
48 2015-04-11 16:05:29 <moarrr> i lost all my computer equipment so I am stuck with not much in terms of being able to run bitcoin-qt
49 2015-04-11 16:06:50 <phantomcircuit> * moarrr signed his public key with his private key and posted it publicly on facebook
50 2015-04-11 16:06:51 <phantomcircuit> wat why
51 2015-04-11 16:07:19 <moarrr> phantomcircuit: uhm, its somewhat complicated, but I wanted a proof that I was the owner of the public address in question
52 2015-04-11 16:07:36 <moarrr> i tend to sign things like song lyrics, etc, with the private key
53 2015-04-11 16:07:42 <moarrr> so its somewhat like my identity :)
54 2015-04-11 16:08:08 <moarrr> like a GPG key
55 2015-04-11 16:12:12 <moarrr> whats the worst thign that can happen re-using the same address for everything (mostly everything) ?  [im at 1EW6G5DfewxJtAintR1pwVR6TpEYHFfwdZ)
56 2015-04-11 16:15:13 <Luke-Jr> worst thing? someone 51% attacks the network to take all past funds it has ever received; not very likely though
57 2015-04-11 16:27:37 <paulo_> hello
58 2015-04-11 16:27:48 <paulo_> what is you opinion of EdDSA?
59 2015-04-11 16:27:58 <paulo_> (Edward's curve DSA)
60 2015-04-11 16:28:09 <phantomcircuit> paulo_, ##crypto
61 2015-04-11 16:28:22 <paulo_> i mean, in bitcoin context
62 2015-04-11 16:28:27 <paulo_> everyone approves of it there
63 2015-04-11 16:29:05 <Luke-Jr> it doesn't exist in Bitcoin context; #bitcoin-wizards perhaps
64 2015-04-11 19:17:26 <sipa> andytoshi: should be, yes
65 2015-04-11 20:30:59 <kanzure> do we do scheduling for testnet hardforks?
66 2015-04-11 20:31:25 <kanzure> or do we treat testnet the same way as mainnet re: breaking channges
67 2015-04-11 20:48:17 <sipa> kanzure: bip34 and bip66 apply the same way to testnet, but with lower thresholds
68 2015-04-11 20:49:07 <sipa> wrt hardforks: we had bad experiences with that, and instead just created a new testnet twice
69 2015-04-11 22:57:11 <Krellan> Opcode question: I want to experiment with adding a new script opcode (perhaps for an altcoin), is there a range where it's preferred
70 2015-04-11 22:57:39 <Krellan> to do this?  Or should I just take any opcode which appears to be unused (probably in the 0xB0 to 0xEF range)?
71 2015-04-11 23:01:34 <andytoshi> Krellan: fyi those are all synonyms for OP_RETURN in bitcoin ... but if you are creating an entirely separate system you can do whatever you want
72 2015-04-11 23:04:53 <Krellan> Thanks, this wouldn't be used for Bitcoin itself, just an experimental altcoin.
73 2015-04-11 23:05:30 <Krellan> I read that 0xB? are deliberately OP_NOP and 0xF? are reserved for use by the internal parser,
74 2015-04-11 23:05:48 <Krellan> so does this mean that 0xC? 0xD? 0xE? are completely unallocated and available for use?
75 2015-04-11 23:06:41 <andytoshi> huh? i said they are synonyms for OP_RETURN, and i'm not sure what "unallocated" is supposed to mean
76 2015-04-11 23:07:55 <Krellan> Nothing's using them (except as a synonym for OP_RETURN aka "This script is false")
77 2015-04-11 23:14:34 <Krellan> The idea was to choose an unused opcode in the most Bitcoin-friendly way, to avoid future conflicts with Bitcoin changes
78 2015-04-11 23:14:54 <gmaxwell> All those are already in conflict.
79 2015-04-11 23:15:27 <gmaxwell> as those opcodes cannot happen in the bitcoin network (can never be spent)
80 2015-04-11 23:15:37 <Krellan> True
81 2015-04-11 23:17:54 <Krellan> This would be for an altcoin, not on the Bitcoin network (I know, "No altcoin support")
82 2015-04-11 23:18:21 <Krellan> but wanted to pick an opcode in the most forward compatible way, instead of just throwing darts,
83 2015-04-11 23:19:42 <Krellan> and wondering if there's a preference. I want to avoid the OP_NOP range because I want the script to fail, not continue running, if client too old.
84 2015-04-11 23:20:09 <gmaxwell> uh......
85 2015-04-11 23:20:19 <gmaxwell> that means the network will fork
86 2015-04-11 23:25:35 <Krellan> Yes, good point.  The opcode has side effects, though, probably unavoidable... if it didn't cause fork immediately, it would later, down the road.
87 2015-04-11 23:28:23 <xecoscar_> email accounts used case sensative html in 2006, how can I retrieve lost emails from then?
88 2015-04-11 23:29:24 <theorb> Forking the chain isn't neccessarly a problem for an altcoin, though.  It'd be handy to be able to have minimal divergance on the protocol, though, because you do less wheel-reinventing -- code from the two projects are easier to port across.
89 2015-04-11 23:31:28 <andytoshi> discussion of forking to #bitcoin please
90 2015-04-11 23:32:12 <xecoscar_> protocol
91 2015-04-11 23:33:28 <xecoscar_> was imbeded into the network in 2006
92 2015-04-11 23:34:19 <xecoscar_> ^embeded into the network