1 2014-05-29 00:11:06 <dazedhead> gwillen: so i have a key coinbase and sequence in "vin" right? (https://github.com/conformal/btcd/wiki/JSON-RPC-API)
2 2014-05-29 00:11:51 <dazedhead> gwillen: so i only i need to ignore this "vin" and to add the values of "vout" right?
3 2014-05-29 00:12:13 <gwillen> dazedhead: that all sounds about right, yeah
4 2014-05-29 00:12:25 <dazedhead> hm... i think im doing this alraedy...
5 2014-05-29 00:12:34 <dazedhead> " Are you accounting for transactions that are to or from complex addresses that aren't just a single key? "
6 2014-05-29 00:12:43 <dazedhead> can you explain me this more detailled please?
7 2014-05-29 00:12:47 <gwillen> so honestly if you're just counting vins and vouts
8 2014-05-29 00:12:56 <gwillen> I'm not actually sure if it matters what type of address it is
9 2014-05-29 00:13:16 <gwillen> it seems like that should just work
10 2014-05-29 00:13:20 <gwillen> so perhaps you have a bug somewhere
11 2014-05-29 00:14:52 <dazedhead> can you show me a example of a complex address? maybe i know what you mean.... i already saw that the "addresses" key is an array, so its possible that there are more 1 address in the "addresses" key of "scriptPubKey"
12 2014-05-29 00:15:04 <dazedhead> ?
13 2014-05-29 00:17:16 <gwillen> dazedhead: let me look
14 2014-05-29 00:18:17 <gwillen> dazedhead: when you are working with a vout, do you do anything with the addresses? Or do you just note the bitcoins at that vout, waiting to see a corresponding vin later?
15 2014-05-29 00:18:26 <gwillen> (And the at the end, total up the vouts at each address?)
16 2014-05-29 00:18:55 <gwillen> If you don't worry about the addresses until the end, you should get a correct accounting for the vouts that only have one address, I think
17 2014-05-29 00:19:16 <gwillen> you could have multiple addresses in the case of multisig transactions, I think, where multiple people have to sign to get the coins
18 2014-05-29 00:19:33 <gwillen> but to know what the array of addresses means, you would have to understand the associated script
19 2014-05-29 00:32:51 <dazedhead> can you take a look on http://pastebin.com/ZkNcd75F
20 2014-05-29 00:32:52 <dazedhead> ?
21 2014-05-29 00:32:57 <dazedhead> gwillen:
22 2014-05-29 00:33:39 <dazedhead> i know its not btc but im testing on a small coin because there it is easy to parse the complete block chain in small time and to verify if the list is calculated correctly
23 2014-05-29 00:33:43 <gwillen> dazedhead: yeah?
24 2014-05-29 00:33:46 <gwillen> ACTION nods
25 2014-05-29 00:33:55 <gwillen> dazedhead: you could also try BTC testnet, that's probably smaller than BTC mainnet
26 2014-05-29 00:34:17 <dazedhead> ah nice to know thanks :-)
27 2014-05-29 00:34:52 <dazedhead> i wrote you for vout and vin the list of steps im doing to calculate the address balance
28 2014-05-29 00:35:04 <dazedhead> under each example
29 2014-05-29 00:35:31 <gwillen> let me look, hold on
30 2014-05-29 00:35:40 <kiddouk> dazedhead: sounds good to me
31 2014-05-29 00:36:02 <gwillen> dazedhead: I would not use addresses at all in the main process
32 2014-05-29 00:36:28 <gwillen> dazedhead: I would just store balances indexed by transaction id and vout number
33 2014-05-29 00:36:42 <gwillen> and then remove when it's spent to a vin in another transaction
34 2014-05-29 00:36:50 <gwillen> then at the very end you should have a list of vouts with balances
35 2014-05-29 00:36:53 <gwillen> THEN tally up the addresses
36 2014-05-29 00:37:13 <gwillen> this will prevent errors when dealing with types of scripts that have multiple addresses or do other odd thigns
37 2014-05-29 00:40:41 <warren> bitcoind: /home/ubuntu/install/include/boost/thread/pthread/condition_variable_fwd.hpp:81: boost::condition_variable::~condition_variable(): Assertion `!ret' failed.
38 2014-05-29 00:41:07 <warren> 0.9.2 branch bitcoind can crash if you use too many RPC's quickly.
39 2014-05-29 00:41:14 <warren> trying to narrow it down
40 2014-05-29 01:09:07 <dazedhead> gwillen: kiddouk thank you both for your nice help... it already 3am here maybe i should continue tomorrow :-\ thanks for your tips !
41 2014-05-29 01:09:17 <gwillen> dazedhead: no problem, good luck
42 2014-05-29 01:48:30 <jgarzik> fscking spammers
43 2014-05-29 01:48:34 <jgarzik> ACTION deletes some github spam
44 2014-05-29 01:48:49 <jgarzik> I cannot believe github lacks a "block asshole from project" feature
45 2014-05-29 01:49:09 <jgarzik> I can _individually_ block a spammer, but that doesn't turn them away from spamming your project
46 2014-05-29 01:49:45 <gmaxwell> jgarzik: yea, I deleted a bunch of that guys spam an also 'report user'ed him.
47 2014-05-29 01:49:56 <gmaxwell> he's still going however.
48 2014-05-29 02:38:52 <lechuga_> when a node is initially syncing and after it sends its first getblocks message what prompts it to send another
49 2014-05-29 02:39:09 <lechuga_> it looks like only when it sees a block get relayed with no parent
50 2014-05-29 02:39:49 <lechuga_> unless im missing it
51 2014-05-29 04:21:49 <G_Qu> can anyone help? i absolutely cannot sync my wallet. been days. tried bootstrap, still nothing.
52 2014-05-29 04:22:20 <w1zman> firewall ?
53 2014-05-29 04:22:29 <G_Qu> nope
54 2014-05-29 04:25:08 <G_Qu> have also updated to latest version, no change
55 2014-05-29 07:05:22 <wumpus> hmm... I just ran bitcoind with --checkblocks=0 and --checklevel=2 and got the following error
56 2014-05-29 07:05:23 <wumpus> 2014-05-29 06:53:38 ERROR: CheckBlockHeader() : block with timestamp before last checkpoint
57 2014-05-29 07:05:23 <wumpus> 2014-05-29 06:53:38 ERROR: VerifyDB() : *** found bad block at 278999, hash=0000000000000001ed51db67f98e83ac76209fe00dabc2a42c80cbc9a4ef6c45
58 2014-05-29 07:09:34 <wumpus> could be db corruption, though it's strange to get the "block with timestamp before last checkpoint" when retroactively validating
59 2014-05-29 07:12:46 <gmaxwell> Did you suspect corruption before doing that?
60 2014-05-29 07:12:55 <gmaxwell> ACTION checks his laptop
61 2014-05-29 07:13:10 <wumpus> no, I was just goofing around a bit to test a patch that adds a progress bar
62 2014-05-29 07:14:15 <wumpus> "time" : 1389046538, for that block
63 2014-05-29 07:15:59 <gmaxwell> Reproduces here.
64 2014-05-29 07:17:05 <gmaxwell> 279000 is at "time" : 1389047471,
65 2014-05-29 07:18:46 <wumpus> I get the same time for 279000
66 2014-05-29 07:19:02 <gmaxwell> but the prior checkpoint is 250000, which is 1375533383
67 2014-05-29 07:19:02 <wumpus> so 279000 should never have been made a checkpoint
68 2014-05-29 07:19:44 <wumpus> hm, right
69 2014-05-29 07:20:13 <gmaxwell> must be the checkblock logic is using the current node's height for picking the checkpoints.
70 2014-05-29 07:20:24 <wumpus> 'last checkpoint' for block 278999 should be 250000, not 279000
71 2014-05-29 07:20:26 <gmaxwell> or something like that?
72 2014-05-29 07:20:30 <gmaxwell> right.
73 2014-05-29 07:21:17 <gmaxwell> ACTION really looks forward to headers first so we can reduce the role of the kludgy and confusing checkpoint stuff.
74 2014-05-29 07:21:42 <gmaxwell> I've done --checkblocks=0 and --checklevel=X a bunch of times, so I suspect we've probably broken this recently.
75 2014-05-29 07:22:02 <wumpus> it gets triggered here https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2345 -- may have to do with the CheckBlockHeader split recently
76 2014-05-29 07:22:03 <gmaxwell> weird that it only fails at that height, using the wrong checkpoint should have made it fail right away.
77 2014-05-29 07:22:19 <gmaxwell> oh right that check runs backwards.
78 2014-05-29 07:22:48 <gmaxwell> (from current best towards 0, so it makes sense that it would fail between the last two checkpoints.)
79 2014-05-29 07:23:24 <wumpus> right, makes perfect sense
80 2014-05-29 07:23:31 <wumpus> I'm going to try with the 0.9.2 branch to see if it happens there
81 2014-05-29 07:44:46 <wumpus> no problems there
82 2014-05-29 10:16:29 <dcousens> anyone have any testnet peers? My client can't seem to find any :/, no problems with mainnet
83 2014-05-29 10:27:03 <Jouke> dcousens: 190.242.69.77 is a peer I am connected to
84 2014-05-29 10:38:40 <wumpus> there have been on-off problems with the testnet DNS seeds, best to add some known testnet node with -addnode and let it find peers from there
85 2014-05-29 11:14:08 <michagogo> dcousens: still need peers?
86 2014-05-29 11:31:01 <Diapolo> wumpus: I guess we have a problem with ordering of settings processing in the GUI.
87 2014-05-29 11:32:07 <Diapolo> wumpus: It seems we create the optionsmodel now before getting to AppInit2() which covers parameter interactions and stuff. This seems to cause problems as GUI settings are processed before these.
88 2014-05-29 11:37:27 <aschildbach> Is it possible that bitcoind testnet inherits some config value from .bitcoin/bitcoin.conf rather than only using .bitcoin/testnet3/bitcoin.conf?
89 2014-05-29 11:37:54 <aschildbach> I'm talking specifically about the maxconnections config parameter.
90 2014-05-29 11:52:20 <Diapolo> aschildbach: GetDataDir(false) / pathConfigFile seems to me the config file is not net specific, which would mean .bitcoin/bitcoin.conf is used even for testnet.
91 2014-05-29 12:03:26 <aschildbach> Diapolo: thanks, that would explain
92 2014-05-29 12:04:43 <Diapolo> aschildbach: No problem.
93 2014-05-29 12:04:43 <Diapolo> wumpus: Any thoughts on what I wrote above?
94 2014-05-29 12:14:48 <chichov> under which circumstances does settxfee return false?
95 2014-05-29 12:23:01 <skinnkavaj> What is the sorcery behind blockchain.info fast rescan of blockchain with adding privkeys in seconds. Why is this not possible with bitcoin-qt why is blockchain.info faster
96 2014-05-29 12:24:56 <tommygunner> you can use a light client like electrum and it will be faster as well
97 2014-05-29 12:25:09 <tommygunner> and you dont have to give some random website your private key
98 2014-05-29 12:33:50 <skinnkavaj> tommygunner: Is it possible to import electrum into an exchange? I am building a bitcoin exchange for spain and thought it would be a great idea to have import privkey
99 2014-05-29 12:34:41 <kiddouk> skinnkavaj: nope. And before asking for private key, you should be aware of the risk of theft you are exposing yourself to.
100 2014-05-29 12:34:59 <skinnkavaj> kiddouk: If blockchain.info can do it in seconds and sweep key
101 2014-05-29 12:35:03 <skinnkavaj> Why shouldnt an exchange be able to do it
102 2014-05-29 12:35:30 <tommygunner> make people send the coins instead of giving you the private key
103 2014-05-29 12:35:41 <kiddouk> It doesn't prevent you to be exposed to the risk of theft. It exposes you a lower amount of time, but it exposes you anyway.
104 2014-05-29 12:43:02 <wumpus> aschildbach: there is no specific configuration file for testnet
105 2014-05-29 12:43:11 <wumpus> aschildbach: that's always been the case
106 2014-05-29 12:47:57 <dcousens> michagogo: nup, thanks :)
107 2014-05-29 12:49:53 <wumpus> (you can specify one with -conf=..., of course)
108 2014-05-29 12:58:08 <Luke-Jr> skinnkavaj: importing privkeys is not safe. you want to sweep.
109 2014-05-29 13:08:15 <kjj> I would say that the unsafe part is accepting a private key as payment
110 2014-05-29 13:10:40 <hearn> skinnkavaj: it requires giant databases that are expensive to build and maintain
111 2014-05-29 13:11:48 <wumpus> right, it would need output-based indexes, which is not rocket science but importing privkeys is just not a use-case to be optimized for bitcoin-qt
112 2014-05-29 13:12:01 <sipa> nor should it be, imho
113 2014-05-29 13:12:04 <wumpus> right
114 2014-05-29 13:12:20 <wumpus> I'm sure there is other software for you if you really need to do that
115 2014-05-29 13:16:05 <sipa> wumpus: have't had the time to check, but the checkheaders failure... are we sure the checkpoint's timestamp is later than any of its predecessor blocks?
116 2014-05-29 13:16:17 <sipa> if it isn't, that eould explain the error
117 2014-05-29 13:18:10 <wumpus> sipa: well it got added in this pull, a few people including you checked it before it was merged https://github.com/bitcoin/bitcoin/pull/3551 :)
118 2014-05-29 13:18:39 <sipa> yes, i believe i did check it
119 2014-05-29 13:19:30 <wumpus> also the error doesn't happen in 0.9.2, just master, so it is caused by a more recent change
120 2014-05-29 13:19:35 <sipa> ok
121 2014-05-29 13:19:41 <wumpus> (although it could have been that it became stricter...)
122 2014-05-29 13:19:58 <sipa> the logic shouldn't have changed
123 2014-05-29 13:20:05 <sipa> if it did, that's a bug
124 2014-05-29 15:15:34 <coryfields> sipa / wumpus: around?
125 2014-05-29 15:15:44 <sipa> yes
126 2014-05-29 15:16:16 <wumpus> yes
127 2014-05-29 15:16:26 <coryfields> sipa: i'm PR'ing my gpg key for gitian signing. I see some are ascii, some are binary. Any preference?
128 2014-05-29 15:16:59 <sipa> dontcare :)
129 2014-05-29 15:17:03 <wumpus> I don't mind either
130 2014-05-29 15:17:08 <coryfields> roger
131 2014-05-29 15:17:24 <coryfields> wasn't sure if any of the scripts prefered one form over another
132 2014-05-29 15:17:47 <wumpus> the scripts don't import the keys for you
133 2014-05-29 15:22:59 <embicoin> Hello, I realized that the bitcoin core qt wallet has a bad cosmetic behaviour into mac osx systems, when you click on the bitcoin icon in the dock, it is expected that the bitcoin window comes to foreground, but currently this is not working as expected...
134 2014-05-29 15:23:06 <embicoin> you click on the dock icon and it does nothing
135 2014-05-29 15:23:47 <embicoin> i looked for some info, i found a blog commenting about this problem, it seems common in qt software
136 2014-05-29 15:23:48 <embicoin> http://th30z.blogspot.com.es/2008/08/qt4-mac-dock-icon-click_2711.html
137 2014-05-29 15:24:31 <embicoin> is just a cosmetic bug, but I would like to fix it, so, where do you recommend to do the tests? into the macdockiconhandler.mm???
138 2014-05-29 15:24:51 <embicoin> or directly into bitcoingui file?
139 2014-05-29 15:25:03 <minium> where can I see the comments attached in e.g. move and sendtoaddress commands?
140 2014-05-29 15:25:30 <sipa> in their implementation
141 2014-05-29 15:27:19 <embicoin> it seems that the fixing code is this:
142 2014-05-29 15:27:21 <embicoin> #ifdef Q_WS_MAC // Install Reopen Application Event (Dock Clicked) m_appleEventProcessorUPP = AEEventHandlerUPP(appleEventProcessor); AEInstallEventHandler(kCoreEventClass, kAEReopenApplication, m_appleEventProcessorUPP, (long) this, true); #endif
143 2014-05-29 15:27:38 <embicoin> obviously adapted to the bitcoin code...
144 2014-05-29 15:28:05 <sipa> embicoin: patches welcome :)
145 2014-05-29 15:28:43 <embicoin> np sipa, this is not very important, but sometimes can be a hassle to mac users...
146 2014-05-29 15:29:18 <embicoin> i will try to work in a patch, but my knowledge is limited somehow :P
147 2014-05-29 15:38:34 <skinnkavaj> kjj: If you let users import priv key but have to wait an hour before balance is credited to the exchange account shouldnt it be safe?
148 2014-05-29 15:38:45 <skinnkavaj> hearn: Why do you need a large database?
149 2014-05-29 15:39:43 <skinnkavaj> Luke-Jr: So there must be a way to import a privkey to an exchange account if the users wait until we sweep the key.
150 2014-05-29 15:40:28 <sipa> skinnkavaj: to find transaction outputs that credit that key
151 2014-05-29 15:40:54 <Luke-Jr> skinnkavaj: what? why?
152 2014-05-29 15:41:06 <Luke-Jr> skinnkavaj: private keys are NOT a reasonable medium of exchange.
153 2014-05-29 15:41:15 <jcorgan> skinnkavaj: the node must scan the entire blockchain for transactions outputs that match the address corresponding to the private key. This can take a long time unless the blockchain is already indexed on addresses.
154 2014-05-29 15:41:50 <Luke-Jr> skinnkavaj: and merely waiting an hour is not sufficient; you'd need to send it to a new secure key (this is what sweeping means)
155 2014-05-29 15:41:51 <skinnkavaj> jcorgan: So blockchain.info is very heavy and expensive to run?
156 2014-05-29 15:42:01 <jcorgan> yes
157 2014-05-29 15:42:02 <skinnkavaj> Luke-Jr: Why not use green addresses?
158 2014-05-29 15:42:06 <lianj> also if you and the exchange have the privkey now, then the exchange cant trust it and has to move the funds anyway
159 2014-05-29 15:42:08 <Luke-Jr> skinnkavaj: â¦â¦â¦
160 2014-05-29 15:42:13 <Luke-Jr> skinnkavaj: you just love bad ideas today? :D
161 2014-05-29 15:42:39 <skinnkavaj> Luke-Jr: I just really want to import a privkey to an exchange, when I import from cold storage I have to first import to bitcoin-qt and then send to an exchange
162 2014-05-29 15:42:43 <Luke-Jr> skinnkavaj: I believe https://en.bitcoin.it/wiki/Green_address#Criticism covers most of that topic
163 2014-05-29 15:42:43 <skinnkavaj> Think it should be built in
164 2014-05-29 15:43:04 <wumpus> Luke-Jr, skinnkavaj, please move this discussion to #bitcoin, it seems to revolve around misconceptions about bitcoin itself
165 2014-05-29 15:43:05 <Luke-Jr> skinnkavaj: private keys should not be used for cold storage.
166 2014-05-29 15:43:10 <Luke-Jr> wumpus: +1
167 2014-05-29 15:43:31 <dazedhead> Does anybody know some documentation links about how to implement "Proof of Stake"?
168 2014-05-29 15:43:47 <skinnkavaj> Luke-Jr: you are too paranoid, is it really possibe that storing on a single address and private key is dangerous? Is there any documentation that support it?
169 2014-05-29 15:44:04 <dazedhead> in relation to calculate the balance of each address of a coin
170 2014-05-29 15:44:08 <sipa> skinnkavaj: the exchange can't know you won't move the funds from under them
171 2014-05-29 15:44:24 <sipa> skinnkavaj: it does not guarantee they become the sole owner
172 2014-05-29 15:44:42 <skinnkavaj> sipa: The exchange could sweep the key and the user would have to wait
173 2014-05-29 15:44:45 <skinnkavaj> I see no problem with that
174 2014-05-29 15:44:56 <sipa> that's exactly what people are telling you here
175 2014-05-29 15:45:05 <sipa> only bitcoin-qt is not the right tool for it
176 2014-05-29 15:45:23 <skinnkavaj> sipa: But it's better to do with electrum?
177 2014-05-29 15:45:31 <sipa> no clue
178 2014-05-29 15:45:40 <lianj> its best not to do at all
179 2014-05-29 15:45:46 <skinnkavaj> Someone here must be familiar with electrum
180 2014-05-29 15:46:00 <jcorgan> skinnkavaj: the "proper" way to move funds out of cold storage is the create a signed transaction to a new address in a hot wallet, or in your case, to a deposit address for the exchange
181 2014-05-29 15:46:00 <sipa> i wouldn't encourage direct-private-key expose to end users
182 2014-05-29 15:46:25 <jcorgan> skinnkavaj: but let's take this to #bitcoin
183 2014-05-29 15:47:41 <Luke-Jr> skinnkavaj: "is it really possibe that storing on a single ⦠private key is dangerous? Is there any documentation that support it?" <-- there have been 2 possible ways to exploit this discovered to date; I would not be shocked if there were more discovered going forward
184 2014-05-29 15:48:36 <sipa> dazedhead: PoS as replacement for PoW is considered broken... it may be useful in combination with it, though
185 2014-05-29 15:53:06 <Belxjander> sipa: Proof Of Stake?
186 2014-05-29 15:53:15 <sipa> yes
187 2014-05-29 15:53:33 <Apocalyptic> it's beyond considered, it really is
188 2014-05-29 15:54:56 <helo> there are still plenty of believers... it will be nice once one of them launches an implementation
189 2014-05-29 15:55:33 <sipa> it works as long as everyone in the system plays by the rules
190 2014-05-29 15:59:26 <tyr1ck> what does the scriptSig depend on in a tx?
191 2014-05-29 15:59:34 <lifty> Hi folks, does anyone know of an open source piece of software that maintains an index of the blockchain based on addresses? My goal is to be able to make queries and return all the transactions for a specific address. Cant find anything that does this besides services like blockchain.info
192 2014-05-29 15:59:51 <tyr1ck> or rather what processes take place before arriving at the scriptSig
193 2014-05-29 16:00:27 <sipa> tyr1ck: in typical transactions, it's a script that pushes onto the stack the public key and signature
194 2014-05-29 16:00:43 <tyr1ck> ahhh sorry
195 2014-05-29 16:00:46 <tyr1ck> I see that
196 2014-05-29 16:00:49 <tyr1ck> I meant the signature
197 2014-05-29 16:01:05 <sipa> the signature signs a special hash of the spending transaction (excluding the scriptSig itself, of course), which also includes parts of the transaction being spent
198 2014-05-29 16:01:18 <tyr1ck> gotcha
199 2014-05-29 16:01:37 <tyr1ck> and the special hash is?
200 2014-05-29 16:02:02 <tyr1ck> double sha256?
201 2014-05-29 16:02:21 <tyr1ck> or is it simple the hash of the spending transaction?
202 2014-05-29 16:02:24 <sipa> yes, but the hard part is what is hashed :)
203 2014-05-29 16:02:25 <tyr1ck> simply*
204 2014-05-29 16:02:39 <tyr1ck> If it is just the hash of the tx, then I am good
205 2014-05-29 16:02:44 <sipa> no, it can't be
206 2014-05-29 16:02:48 <tyr1ck> I see
207 2014-05-29 16:02:56 <sipa> you'd need to know the scriptSig before you could compute the signature in that case
208 2014-05-29 16:03:13 <sipa> there are several modifications made to the signing transaction before being fed to the hashfunction
209 2014-05-29 16:03:37 <sipa> including replacing some parts with pieces of the transactions whose outputs are being spent
210 2014-05-29 16:03:42 <tyr1ck> I have tons of questions =/
211 2014-05-29 16:03:46 <tyr1ck> maybe I'll skip to another
212 2014-05-29 16:03:51 <tyr1ck> looking at : OP_DUP OP_HASH160 c812a297b8e0e778d7a22bb2cd6d23c3e789472b OP_EQUALVERIFY OP_CHECKSIG
213 2014-05-29 16:04:01 <andytoshi> lifty: i don't think there's anything out there, sorry
214 2014-05-29 16:04:08 <tyr1ck> c812a297b8e0e778d7a22bb2cd6d23c3e789472b is the recipient's public key correct?
215 2014-05-29 16:04:16 <sipa> tyr1ck: no, its hash
216 2014-05-29 16:04:22 <tyr1ck> right
217 2014-05-29 16:04:24 <sipa> lifty: abe does that afaik, but is very resource heavy
218 2014-05-29 16:04:29 <tyr1ck> but it isn't the bitcoin public address
219 2014-05-29 16:04:36 <sipa> it is
220 2014-05-29 16:04:37 <tyr1ck> do how does one get that?
221 2014-05-29 16:04:46 <tyr1ck> I thought bitcoin addresses start with a 1
222 2014-05-29 16:04:47 <sipa> it's the raw data encoded inside the address
223 2014-05-29 16:04:55 <sipa> which is base58 encoded with version number and checksum
224 2014-05-29 16:05:00 <tyr1ck> ahhh
225 2014-05-29 16:05:01 <lifty> ok cool, thx guys
226 2014-05-29 16:05:14 <tyr1ck> I see, so I can always base58 decode after stripping the checksum
227 2014-05-29 16:05:21 <tyr1ck> and get that value
228 2014-05-29 16:05:27 <lifty> I might have to implement something like that myself
229 2014-05-29 16:05:33 <sipa> assuming it's a v1 transaction, yes
230 2014-05-29 16:05:39 <tyr1ck> great!
231 2014-05-29 16:05:46 <sipa> eh, v1 address
232 2014-05-29 16:06:03 <tyr1ck> hm
233 2014-05-29 16:06:09 <tyr1ck> I thought all tx were v1?
234 2014-05-29 16:06:12 <tyr1ck> as of now
235 2014-05-29 16:06:17 <sipa> v1 address
236 2014-05-29 16:06:21 <tyr1ck> okay
237 2014-05-29 16:06:22 <tyr1ck> I see
238 2014-05-29 16:08:23 <tyr1ck> So in the case of having the above scriptPubKey, my scriptSig will require the public key and a signature, which is magic...
239 2014-05-29 16:08:55 <sipa> there's plenty of documentation out there on how to compute the signature hash
240 2014-05-29 16:10:00 <michagogo> sipa: v0 address, no?
241 2014-05-29 16:10:28 <michagogo> The address version byte is 0
242 2014-05-29 16:10:42 <tyr1ck> I guess I am also interested in the OP_CHECKSIG script
243 2014-05-29 16:11:06 <tyr1ck> off the top of your head, you know where it is in the code?
244 2014-05-29 16:11:48 <sipa> script.cpp, CTransactionSignatureSerializer
245 2014-05-29 16:11:58 <tyr1ck> thx thx th
246 2014-05-29 16:12:10 <sipa> michagogo: right
247 2014-05-29 16:12:25 <jrick> with latest git: http://sprunge.us/OPaW
248 2014-05-29 16:12:31 <jrick> is that really necessary?
249 2014-05-29 16:13:24 <sipa> wth, how did that get in?
250 2014-05-29 16:13:29 <michagogo> jrick: some context?
251 2014-05-29 16:13:38 <michagogo> Line numbers? Git blame?
252 2014-05-29 16:14:06 <michagogo> -nC10 or so passed to grep?
253 2014-05-29 16:14:27 <jrick> that's in the rpc help text
254 2014-05-29 16:14:45 <michagogo> (But yeah, what sipa said)
255 2014-05-29 16:14:51 <sipa> ACTION fixes
256 2014-05-29 16:15:06 <michagogo> sipa: what's the git-blame?
257 2014-05-29 16:15:17 <sipa> a6099ef3
258 2014-05-29 16:15:20 <michagogo> ACTION isn't at a computer atm
259 2014-05-29 16:15:24 <jrick> a6099ef3 (sje 2013-10-29 22:29:44 +1100 1450)
260 2014-05-29 16:15:55 <michagogo> ACTION hopes github.com/bitcoin/bitcoin/commit/a6099ef3 is the right link
261 2014-05-29 16:21:23 <michagogo> Er, are you sure that's the commit that added it?
262 2014-05-29 16:21:45 <jrick> no, could be moved from somewhere else
263 2014-05-29 16:21:50 <michagogo> I tried searching that commit and the PR's changes tab for blockchain.info
264 2014-05-29 16:21:56 <michagogo> It's not there
265 2014-05-29 16:21:56 <sipa> yes
266 2014-05-29 16:22:01 <sipa> it's not moved
267 2014-05-29 16:22:20 <michagogo> ACTION is confused
268 2014-05-29 16:22:51 <sipa> the diff of that commit shows the string blockchain.info only in added lines, and not in deleted lines
269 2014-05-29 16:23:13 <michagogo> I searched for "blockchain" and for "info" on the page I linked myself to above
270 2014-05-29 16:23:27 <michagogo> Didn't seem to be there
271 2014-05-29 16:23:36 <harding> michagogo: I searched that page you linked and found them.
272 2014-05-29 16:23:43 <michagogo> Odd.
273 2014-05-29 16:23:51 <michagogo> Mobile interface being weird?
274 2014-05-29 16:24:17 <michagogo> Anyway, looks like the blame target is wumpus here
275 2014-05-29 16:24:51 <sipa> it was added in #3246, which is a rebase of #3184
276 2014-05-29 16:25:53 <sipa> bah, that's even in 0.9.1
277 2014-05-29 16:26:29 <michagogo> ACTION hands wumpus a conical hat
278 2014-05-29 16:32:25 <jrick> there appears to be another reference to bc.i in doc/bootstrap.md, but not sure if that falls under the same category of speedy purging
279 2014-05-29 16:32:59 <wumpus> huh/
280 2014-05-29 16:36:54 <wumpus> I haven't added them, but yes the references to bc.i should probably be removed
281 2014-05-29 16:47:46 <michagogo> wumpus: you appear to have rebased and merged them in
282 2014-05-29 16:51:34 <wumpus> michagogo: yes...
283 2014-05-29 16:51:54 <wumpus> like 95% of the stuff that makes it into bitcoin core
284 2014-05-29 16:52:47 <michagogo> wumpus: isn't review expected before merging? :P
285 2014-05-29 16:54:06 <wumpus> not only by me
286 2014-05-29 16:54:45 <wumpus> and yes, I reviewed it, but it's not necessarily wrong
287 2014-05-29 16:55:11 <wumpus> it's not nice to refer to a centralized service, but I'm sure the submitter of that pull meant no harm with it
288 2014-05-29 16:55:50 <wumpus> anyhow, it's gone now
289 2014-05-29 16:55:56 <wumpus> thanks sipa
290 2014-05-29 16:55:59 <michagogo> Great
291 2014-05-29 16:58:01 <michagogo> (If it wasn't clear: I was just kidding with the whole blame and hat thing. I didn't intend any offense or insult or anything and I hope you didn't take it that way... If you did, I'm sorry.)
292 2014-05-29 16:59:18 <coryfields> michagogo: are you able to do the osx gitian build?
293 2014-05-29 17:03:50 <michagogo> coryfields: not near my computer tonight
294 2014-05-29 17:04:14 <michagogo> Sorry
295 2014-05-29 17:04:55 <coryfields> ok, np
296 2014-05-29 17:05:58 <michagogo> Did we end up switching the afk?
297 2014-05-29 17:06:01 <michagogo> SSL?
298 2014-05-29 17:06:05 <michagogo> SDK?
299 2014-05-29 17:09:50 <wumpus> michagogo: oh you were trolling! :p
300 2014-05-29 17:10:18 <michagogo> wumpus: maybe :P
301 2014-05-29 17:11:49 <wumpus> yes, we switched the SDK
302 2014-05-29 17:12:10 <wumpus> it's based on the 10.7 SDK now
303 2014-05-29 17:13:39 <wumpus> and we don't have a platform independent way to extract the SDK from the xcode package yet, so if you don't have access to a mac you'll need to convince someone to send it to you
304 2014-05-29 17:14:11 <michagogo> wumpus: I think I do have access to a Mac
305 2014-05-29 17:14:22 <coryfields> i'm confident that there's a way to handle that, i just didn't want to focus on that part until the new SDK build actually worked
306 2014-05-29 17:14:30 <wumpus> (which is no problem, I'm willing to send it)
307 2014-05-29 17:14:33 <michagogo> Not too happy about the (assumed) several-GB download, though
308 2014-05-29 17:14:34 <coryfields> hopefully we'll have all the wrinkles taken care of for the next release
309 2014-05-29 17:14:43 <coryfields> michagogo: iirc it's ~1.1
310 2014-05-29 17:14:54 <michagogo> Ah, smaller than the other one?
311 2014-05-29 17:15:56 <wumpus> there is also a version of the 10.7 SDK someone put on github, but alas it doesn't work with the qt build, I've tried (see https://github.com/bitcoin/bitcoin/pull/4229)
312 2014-05-29 17:16:47 <coryfields> wumpus: i've thought about it some, and i'm not sure how any of the sdk could be non-redistributable
313 2014-05-29 17:16:58 <coryfields> considering that its purpose is to end up in released binaries
314 2014-05-29 17:17:04 <coryfields> worth looking into, imo
315 2014-05-29 17:17:27 <wumpus> coryfields: I'm not sure either, wouldn't mind distributing it in some form either way, the only issue is trust
316 2014-05-29 17:17:53 <coryfields> wumpus: well if it's redistributable, i can create a relocatable toolchain and try to get it pushed up to debian/ubuntu
317 2014-05-29 17:18:09 <wumpus> only if you download from apple and extract it yourself you can be sure it's the real one
318 2014-05-29 17:19:55 <coryfields> sure, but you can say the same about linux's glibc
319 2014-05-29 17:20:41 <coryfields> (my point being that the headers/libs have to come from somewhere initially)
320 2014-05-29 17:20:50 <wumpus> right, if you can get it in ubuntu/debian upstream, then it's implicitly trusted
321 2014-05-29 17:21:11 <coryfields> i suppose that's what i was trying to say, yea :)
322 2014-05-29 17:21:16 <wumpus> we implicitly trust the rest of ubuntu for the gitian build already, same could indeed be said for the w32 sdk in mingw
323 2014-05-29 17:23:46 <gavinandresen> jgarzik sipa: RE: save/restore memory pool being dangerous: ideas on how to mitigate? Could just not save transactions that have been hanging around more than 25 blocks....
324 2014-05-29 17:24:18 <gavinandresen> (25 blocks is the limit for how far the estimate code records history)
325 2014-05-29 17:24:53 <wumpus> gavinandresen: sounds sensible, especially if those transactions aren't used for the estimation anyway
326 2014-05-29 17:25:45 <Luke-Jr> wumpus: meh, even for centralised services, bc.i is especially bad since it sews misinformation everywhere
327 2014-05-29 17:25:47 <gavinandresen> What's that status of the mempool janitor pull? That's relevant, too....
328 2014-05-29 17:26:18 <sipa> i like the general idea of a janitor but not its current implementation
329 2014-05-29 17:27:08 <sipa> the problem is that it's an unenforcable policy... people may keep resubmitting their transactions
330 2014-05-29 17:27:27 <wumpus> but if people resubmit their transaction there isn't a problem is there?
331 2014-05-29 17:27:40 <wumpus> I thought it's there to clean up tranactions no one cares about anymore
332 2014-05-29 17:27:49 <sipa> not necessary the people who might want to see them expire
333 2014-05-29 17:27:55 <sipa> so providing any guarantees on mempool lifetime (in either direction) is very hard
334 2014-05-29 17:28:07 <denisx> Iam running a bitcoin in ipv6 only mode, but it tests only two ipv6 adresses after start per second. is there a way to speed that up?
335 2014-05-29 17:28:07 <wumpus> no guarantees are possible
336 2014-05-29 17:28:12 <denisx> node
337 2014-05-29 17:28:18 <gmaxwell> e.g. coinbase for a while was agressively retransmitting every txn in their mempool every time there was a block on the network.
338 2014-05-29 17:28:30 <gmaxwell> (they may still be)
339 2014-05-29 17:28:46 <wumpus> a miner may still take the transaction privately and mine it into a block, even after it has expired from the mempool for long
340 2014-05-29 17:29:09 <sipa> ultimately, the mempool and many other non-normative resources should just be resource-limit (set a memory usage limit)
341 2014-05-29 17:29:32 <wumpus> a resource limit makes sense
342 2014-05-29 17:30:01 <sipa> but before that point becomes relevant/possible/implemented, i prefer not to extend the current implicit behaviour of essentially infinite mempool transactions
343 2014-05-29 17:33:07 <gavinandresen> sipa: ACK on a memory-limited mempool. But "better is better"
344 2014-05-29 17:33:25 <wumpus> although the eviction order in that case has to be chosen carefully, if , to not make it predictably possible to flood all transactions from the mempool
345 2014-05-29 17:34:43 <gavinandresen> I'll make three changes to the mempool save/restore code after lunch: 1) limit recursion for unconfirmed (to⦠uh⦠three? eleven?) 2) only save transactions we received in the last 25 blocks. 3) sanity-check data as it comes in (belt-and-suspenders for a corrupt mempool.dat)
346 2014-05-29 17:35:31 <gavinandresen> ("comes in" meaning when restoring from disk)
347 2014-05-29 17:35:57 <sipa> gavinandresen: with the current low ratio between fee-needed-for-relay / fee-needed-for-reasonably-fast-inclusion-in-block, i think there's some decent risk of making mempools grow too fast, and removing the ability to restart your node to fix it sounds bad
348 2014-05-29 17:36:04 <sipa> gavinandresen: ack on only saving recent transactions
349 2014-05-29 17:36:23 <gavinandresen> sipa: recovery is easy: rm mempool.dat and restart.
350 2014-05-29 17:36:54 <gavinandresen> sipa: I thought of adding a command-line switch, but that seems like overkill when you can just 'rm' with no ill effects (except you lose fee estimation history)
351 2014-05-29 17:37:25 <gavinandresen> mmm⦠I could save fee estimate data separately from mempool.dat⦠that is probably the right thing to do
352 2014-05-29 17:43:57 <wumpus> hmm, would it be possible to make the fee estimate data so that you don't need the actual saved mempool?
353 2014-05-29 17:46:16 <wumpus> I suppose not, as you don't know when the data can be discarded (when the transaction or a conflicting one makes it into a block) when you don't have the transaction itself anymore...
354 2014-05-29 17:46:31 <sipa> wumpus: syntax error
355 2014-05-29 17:46:53 <wumpus> huh?
356 2014-05-29 17:47:02 <sipa> well, no, it makes sense gramatically, but i have no idea what you want to make it
357 2014-05-29 17:47:34 <wumpus> well I mean storing data for fee computation separately from the mempool
358 2014-05-29 17:47:51 <sipa> ah, for storing locally
359 2014-05-29 17:47:56 <wumpus> restore some historical statistics but not the mempol itself
360 2014-05-29 17:47:57 <wumpus> yes
361 2014-05-29 18:03:24 <hearn> hey there
362 2014-05-29 18:04:44 <hearn> sipa: i was looking at the disparity between what relays and what mines yesterday. seems most miners haven't upgraded to 0.9 because they simply aren't paying attention. there's no features in there for them, and 0.8.x works, so why change things?
363 2014-05-29 18:04:51 <hearn> at least that's the answer i got from the one pool operator i asked :)
364 2014-05-29 18:05:23 <hearn> i think a lot of people have a mindset that the only reason to upgrade bitcoin is for new features. other things that are done don't seem to register
365 2014-05-29 18:05:34 <hearn> perhaps we need more of a splash around releases with more marketing. like a landing page on the website.
366 2014-05-29 18:06:00 <sipa> but iirc the fee for decent fast inclusion is even more than the default relay fee in 0.8
367 2014-05-29 18:06:08 <gmaxwell> The website may not be the best tool for marketing to an audience of ~3 people.
368 2014-05-29 18:07:09 <wumpus> even in features miners seem hardly interested, most pull requests aimed at miners hardly get any review/testing reports
369 2014-05-29 18:07:21 <hearn> sipa: nah. the old default fee always works fine. but some people pay more in fees anyway, not sure why.
370 2014-05-29 18:07:32 <hearn> sipa: some just haven't upgraded. they still pay the fees that were default >1 year ago.
371 2014-05-29 18:07:50 <sipa> wumpus: yeah, to them, upgrading is just a burden often
372 2014-05-29 18:08:02 <hearn> pools don't even list their policies on their web pages
373 2014-05-29 18:08:19 <hearn> it's really sad, the state of mining. literally the only thing that seems to matter to most is getting the block reward
374 2014-05-29 18:08:39 <hearn> not much we can do about it though, i guess, short of thinking up cool stuff that miners would want and putting it into releases
375 2014-05-29 18:08:40 <sipa> well, that's what pays the bill :)
376 2014-05-29 18:09:10 <gmaxwell> I mean, it took days to get some major pools to deploy a trivial three line patch to block the malleability flooding a few months ago, while the network was being attacked, and that was with me offering personal tech support and backporting to any version they wanted.
377 2014-05-29 18:09:54 <wumpus> yes :/
378 2014-05-29 18:10:36 <hearn> at least you know how to contact them :) i was stymied by the completely worthless ghash.io front page
379 2014-05-29 18:10:43 <hearn> not even an email address
380 2014-05-29 18:10:51 <hearn> oh well. i guess we have to muddle on through regardless.
381 2014-05-29 18:12:32 <gavinandresen> Well, if I had infinite time I'd port p2pool to C++, make it really, really, really easy to install and run and then market to miners "DECENTRALIZED MUCH LOWER FEE"
382 2014-05-29 18:13:08 <hearn> gavinandresen: i thought that too. then i noticed ghash.io has zero fee
383 2014-05-29 18:13:13 <sipa> i doubt many would use it
384 2014-05-29 18:13:19 <hearn> i'm not sure how they make money. presumably cross subsidised by cex.io or something else
385 2014-05-29 18:13:27 <sipa> as it limits the variance decrease significantly if popular
386 2014-05-29 18:13:29 <hearn> it's probably why they keep getting close to 51%
387 2014-05-29 18:13:43 <gmaxwell> hearn: I think the model is the public users eat their stale losses (their hardware is super latent)
388 2014-05-29 18:14:06 <hearn> well, that limits their losses, but they still have some costs, presumably
389 2014-05-29 18:14:30 <hearn> especially as one other reason for their popularity appears to be that they just have lots of features and are generally appealing as a pool
390 2014-05-29 18:15:13 <gmaxwell> well, for example if your own hardware results in a stale rate of 10% and you can get on another equal rate of users that are 1% stale and you pay them all equally...
391 2014-05-29 18:15:26 <maaku> not to mention that a significant subet of miners think choosing the largest pool is an optimal strategy
392 2014-05-29 18:15:46 <gmaxwell> hearn: hm? until somewhat recently it was basically impossible to figure out how to make an account even (you had to go to an unrelated domain and use an undocumented featureâ¦)
393 2014-05-29 18:16:05 <hearn> oh, ok. i'm just parroting what i read on the interwebs, really i know nothing about the modern mining scene
394 2014-05-29 18:16:18 <gmaxwell> the largest pool has always had kissing-majority problems, presumably due to what maaku says.
395 2014-05-29 18:16:36 <hearn> and yes i see what you mean now. they're mining on their own pool with bad (?) hardware and are willing to pay the costs of the extra users to offset their expensive mistake
396 2014-05-29 18:17:12 <gmaxwell> hearn: yes, â well thats some speculation which apparears to be supported by the limited supporting data available.
397 2014-05-29 18:17:19 <gavinandresen> We should crowdfund a lottery reward for people running p2pool. E.g. p2pool miner that finds the next p2pool block after some date gets an extra 10BTC .....
398 2014-05-29 18:17:44 <gavinandresen> ⦠but only if they're running 0.9.2...
399 2014-05-29 18:18:12 <gavinandresen> Anyway, I'm sure we could figure out a way of incentivizing good behavior
400 2014-05-29 18:18:56 <gmaxwell> p2pool itself even has a lottery thing built in, e.g. load http://127.0.0.1:9332/patron_sendmany/10 and the output is a sendmany commandline to send 10 btc to recent p2pool miners hashpower-proportionally.
401 2014-05-29 18:19:29 <gavinandresen> I actually think rewarding somebody at random would be a bigger incentive. Makes it more of a game
402 2014-05-29 18:19:46 <sipa> ... while pools exactly exist to make mining less of a game
403 2014-05-29 18:20:09 <gavinandresen> good point
404 2014-05-29 18:20:54 <maaku> when p2pool first started there were significant subsidies given out by random people using the sendmany feature
405 2014-05-29 18:21:07 <gmaxwell> that particular cgi takes an extra argument which is the minimum amount to pay someone.
406 2014-05-29 18:21:15 <maaku> iirc ROI on using p2pool was 120% the expected solo mining return
407 2014-05-29 18:21:22 <hearn> actually i think i started that
408 2014-05-29 18:21:27 <hearn> i subsidised p2pool miners for a while
409 2014-05-29 18:21:38 <gmaxwell> It takes all the amounts less than that threshold and makes them into a single output given to one of the owed parties with odds proportional to their hashrate.
410 2014-05-29 18:21:38 <hearn> back when it was brand new
411 2014-05-29 18:21:47 <hearn> but in the end it didn't shift the needle much. they got left behind by the asic race
412 2014-05-29 18:22:04 <gavinandresen> I think I tried to run p2pool once, and gave up because I was in python dependency hell. Haven't tried recently
413 2014-05-29 18:22:28 <sipa> i created a block using p2pool :P
414 2014-05-29 18:22:36 <sipa> (i'm sure gmaxwell has many though...)
415 2014-05-29 18:22:38 <gmaxwell> hm. on fedora it runs out of the box.
416 2014-05-29 18:22:47 <hearn> lots of miners are on windows, i guess
417 2014-05-29 18:22:49 <gmaxwell> sipa: yea, one last week, in fact.
418 2014-05-29 18:22:54 <hearn> python was perhaps not the best choice for ease of deployment
419 2014-05-29 18:22:56 <gmaxwell> windows p2pool is easy, there is a binary.
420 2014-05-29 18:22:59 <hearn> (not that java is amazing either :-)
421 2014-05-29 18:23:03 <hearn> oh, ok. good to know
422 2014-05-29 18:23:09 <wumpus> on windows it's pretty easy to create an exe from python
423 2014-05-29 18:23:17 <gmaxwell> There is a tool to 'compile' python to an exe for windows thats used.
424 2014-05-29 18:23:23 <wumpus> yes
425 2014-05-29 18:23:26 <gavinandresen> mmm. OSX loses out again....
426 2014-05-29 18:23:26 <hearn> right, that bundles the runtime
427 2014-05-29 18:23:36 <hearn> i doubt many miners use macs
428 2014-05-29 18:23:43 <wumpus> OSX is the most frustrating platform to distribute software again :p
429 2014-05-29 18:23:49 <hearn> they're a bit expensive to tie up on feeding work to miners
430 2014-05-29 18:23:57 <gmaxwell> yea, I think OSX is the confluence of bad there, no magic binary and no all-python-prereqs preinstalled.
431 2014-05-29 18:24:53 <gmaxwell> in any case, p2pool suffers from both the belief that the biggest pool pays more _and_ high variance due to being small, the mixture is particular deadly, since if you didn't really believe that you'd make as much and it takes three days to solve a block.. sadness.
432 2014-05-29 18:25:14 <maaku> py2app?
433 2014-05-29 18:25:22 <gmaxwell> P2Pool's expected time to a block now is about 18 hours, so three day runs without blocks happen.
434 2014-05-29 18:25:44 <hearn> i used to think asics would make people worry about variance less, because you're in it for the long term
435 2014-05-29 18:25:55 <hearn> i guess the upgrade cycles are still short enough that people don't think that way
436 2014-05-29 18:26:33 <gmaxwell> hearn: people are just weird, I've seen plenty of people complaining about variance, and then an hour later say something else that made it clear that they took their mining income and put played it on a gambling site as soon as they got it.
437 2014-05-29 18:26:51 <hearn> hah, brilliant
438 2014-05-29 18:27:20 <gmaxwell> p2pool lets you turn _up_ your share difficulty, so if you want to gamble, it's built in! :P but seems people don't think that way.
439 2014-05-29 18:27:24 <maaku> well, they want to gamble every day not every 3 days :P
440 2014-05-29 18:28:00 <sipa> we should relabel p2pool as "Ultimate Bitcoin Mining Casino"
441 2014-05-29 18:28:10 <hearn> PoolDice
442 2014-05-29 18:28:23 <sipa> The Dice Pool!
443 2014-05-29 18:28:25 <hearn> JustSatoshiPoolDiceBones
444 2014-05-29 18:28:39 <hearn> sipa: ooh the logo just draws itself :)
445 2014-05-29 18:28:43 <gmaxwell> I'd commented before that it would be nice if mining software did some fun stuff to show you your best share found so far, perhaps let you commit some vanity string in it and output a little certificate text file.
446 2014-05-29 18:29:19 <gmaxwell> (miners have since added a little best share display)
447 2014-05-29 18:30:44 <belcher> i guess most people are salaried, rather than running a business where income is are more sporadic
448 2014-05-29 18:31:04 <belcher> a paycheck on the same date each month feels nice
449 2014-05-29 18:31:23 <belcher> its not how the world works though
450 2014-05-29 18:41:18 <gmaxwell> heads up, bc.i is erroniously claiming there was a 78 block reorg a few days ago and the internets are starting to freak out without questioning it.
451 2014-05-29 18:42:45 <hearn> i wonder what's going on over there. has ben left? he used to run a tight ship and it's just been falling to pieces there lately, and i didn't hear much from him lately.
452 2014-05-29 18:46:21 <gmaxwell> their stats have always been a bit lossy.
453 2014-05-29 18:46:40 <gmaxwell> enough that there is a pinned thread in the mining subforum telling people to not believe it when it shows something freaky. :)
454 2014-05-29 18:47:09 <waxwing> random question, but has it been considered to put bitcoin core binary signatures,hashes into the blockchain?
455 2014-05-29 18:48:42 <denisx> waxwing: anybody can put stuff there, what would it help?
456 2014-05-29 18:49:23 <waxwing> my thought was that, while pgp signatures are great and all, there is always an issue of trust in where they are posted. e.g. ssl certs of the website and so on.
457 2014-05-29 18:49:34 <sipa> ...
458 2014-05-29 18:49:43 <tyr1ck> for a CTransaction tx, how can I convert a string to the uint256 needed in tx.vin[0].prevout.hash
459 2014-05-29 18:49:57 <sipa> how is data in the blockchain more trusted than a website?
460 2014-05-29 18:49:59 <belcher> print out the hashes in huge letters and display them at bitcoin conferences
461 2014-05-29 18:50:17 <sipa> tyr1ck: ParseHex
462 2014-05-29 18:50:30 <tyr1ck> that returns a vector of unsigned chars
463 2014-05-29 18:50:35 <waxwing> sorry i'm not being very careful .. it's really keyserver vs blockchain, isn't it.
464 2014-05-29 18:50:42 <sipa> actually, uint256 may even have a SetHex
465 2014-05-29 18:51:02 <sipa> waxwing: no, the signatures would still be pgp signed of course
466 2014-05-29 18:51:10 <sipa> so it is blockchain vs website
467 2014-05-29 18:51:34 <tyr1ck> Where is SetHex
468 2014-05-29 18:51:40 <wumpus> yes, it has a SetHex
469 2014-05-29 18:51:48 <sipa> in uint256...
470 2014-05-29 18:51:55 <hearn> waxwing: blockchain timestamps stuff. it doesn't really help establish trust.
471 2014-05-29 18:52:49 <tyr1ck> perfect, thx
472 2014-05-29 18:53:41 <waxwing> hearn, sipa right.
473 2014-05-29 18:57:17 <michagogo> In theory, you could (for example) timestamp the sha256sums file
474 2014-05-29 18:58:16 <michagogo> Which would prove Gavin didn't decide to (e.g.) replace the setup.exe with a different one
475 2014-05-29 18:58:34 <sipa> no
476 2014-05-29 18:58:51 <michagogo> sipa: replace
477 2014-05-29 18:58:54 <michagogo> Meaning, later
478 2014-05-29 18:59:04 <sipa> right
479 2014-05-29 19:02:21 <hearn> it doesn't even do that
480 2014-05-29 19:02:31 <hearn> to use a timestamp in the block chain you must be able to find it
481 2014-05-29 19:02:35 <hearn> that means you have to follow a pointer to the right place
482 2014-05-29 19:02:39 <hearn> where is that pointer? on the website
483 2014-05-29 19:02:53 <hearn> timestamping with twitter would be more reliable than putting something in the block chain
484 2014-05-29 19:03:16 <waxwing> the pointer could be a public address gavin controls?
485 2014-05-29 19:03:37 <waxwing> (although i'm not sure i understood what michagogo was proposing)
486 2014-05-29 19:03:39 <hearn> and how do you learn that address?
487 2014-05-29 19:03:55 <waxwing> hearn, yes you have that prob with pgp keys too
488 2014-05-29 19:04:06 <hearn> indeed
489 2014-05-29 19:04:40 <waxwing> i was more interested in the blockchain as a "transport layer" than the nature of the key doing the signing
490 2014-05-29 19:04:59 <waxwing> but you're probably right. mainly i'm a bit confused. just a bit suspicious there might be *some* useful trick somewhere.
491 2014-05-29 19:06:00 <sipa> you seem to suffer from the hammer-and-nail syndromr
492 2014-05-29 19:06:21 <sipa> blockchains are such cool technology thatnsomehow people assume they can solve every problem on earth
493 2014-05-29 19:06:33 <waxwing> sipa, probably. or maybe i just think it would be cool if bitcoin was used to increase its own security :)
494 2014-05-29 19:06:46 <sipa> i don't see how it would add anynsecurity
495 2014-05-29 19:06:51 <hearn> if i had a bitcoin for every time i heard "... but on the block chain" i'd be a rich guy :)
496 2014-05-29 19:07:24 <sipa> except for the case where an attacker could bloxk your ability to access the site, but not block your ability to download the blockchain
497 2014-05-29 19:07:50 <waxwing> sipa, well, that case is hardly unthinkable, eh
498 2014-05-29 19:08:45 <sipa> and only for tje case where the keys are already compromised
499 2014-05-29 19:09:11 <sipa> widespread use of gitian verification would be far more valuable
500 2014-05-29 19:09:28 <waxwing> how many people are doing gitian builds?
501 2014-05-29 19:09:32 <sipa> as it removes the need in trusting one or a few specific keys much more effectively
502 2014-05-29 19:09:35 <sipa> too few
503 2014-05-29 19:09:48 <waxwing> i am doing quite a lot. just not of bitcoin :)
504 2014-05-29 19:10:12 <sipa> (and i haven't done thrm in a long time, so no finger pointing from me - jusy observation)
505 2014-05-29 19:18:10 <michagogo> sipa: did we find a way to strip code signing from Apple/MS deterministically?
506 2014-05-29 19:18:45 <michagogo> (I mean, strip the signing and recover the original file(s))
507 2014-05-29 19:19:10 <hearn> gavinandresen: do you remember why bip70 signs the entire PaymentRequest message and not just the PaymentDetails?
508 2014-05-29 19:22:51 <denisx> michagogo: the signing is not part of the binary AFAIK
509 2014-05-29 19:23:10 <michagogo> denisx: it's part of the file
510 2014-05-29 19:23:38 <michagogo> The setup.exe is produced deterministically from gitian
511 2014-05-29 19:23:54 <denisx> michagogo: I meant the apple part
512 2014-05-29 19:24:12 <michagogo> Gavin takes that .exe and signs it with the certificate in the name of the Foundation
513 2014-05-29 19:24:25 <michagogo> denisx: ah, I have no idea how that works
514 2014-05-29 19:24:49 <michagogo> (Except for the whole ".apps are actually folders" thing)
515 2014-05-29 19:25:35 <denisx> michagogo: exactly, and there is another folder insie called â_CodeSignatureâ
516 2014-05-29 19:40:16 <coryfields> michagogo: yes, i have a PR coming up
517 2014-05-29 19:40:26 <azariah4> Hi, would this testnet output script also be mined on mainnet by most nodes; is it considered standard? http://blockexplorer.com/testnet/tx/866cbe1e7ee2cc38b65f7584a72fcb60e0f41a3b15a0934a72c63c52bee48ef2#o0
518 2014-05-29 19:40:54 <coryfields> michagogo: but it goes the other way around. We sign the binaries, detach the signatures, then pass them to gitian for reattaching for final builds
519 2014-05-29 19:41:31 <coryfields> denisx: the signature is indeed part of the binary
520 2014-05-29 19:43:41 <kadoban> azariah4: IIUC that is not standard. You can kinda do the same thing and have it be standard if you use P2SH though for multisig