1 2015-04-25 06:22:23 <priidu> under which circumstances does the core client issue a 'walletnotify' notification?
2 2015-04-25 06:22:41 <priidu> is it only about new transactions or something else as well?
3 2015-04-25 06:25:52 <warren> priidu: new transaction owned by the wallet, and again when it reaches 1 conf iirc
4 2015-04-25 06:26:15 <warren> priidu: just test it on testnet to be sure. there's lots of duplicate notifications for the same txid.
5 2015-04-25 06:26:31 <priidu> yeah
6 2015-04-25 06:26:45 <priidu> that's why wanted to ask
7 2015-04-25 07:37:53 <ajweiss> ACTION sighs
8 2015-04-25 08:26:04 <wumpus> <jtimon> we may want a libconsesign or something later though <- I think a C++ library for transaction manipulation and signing, modularized from bitcoin core, could be useful, but please don't use the word (or part of) 'consensus' anywhere in the name. It has nothing to do with that :)
9 2015-04-25 08:27:52 <wumpus> what we're doing with the consensus work is dilineate very strictly what is part of 'consensus', not muddle it further
10 2015-04-25 08:31:33 <wumpus> did anyone find any new issues with 0.10.1rc3? if not, I'm going to tag it as final today
11 2015-04-25 08:43:50 <jtimon> wumpus sure libconsesign was just a stupid name, libbitcoinsign or something else would be better, note that libconsensus++ is something different
12 2015-04-25 08:44:30 <wumpus> right
13 2015-04-25 10:13:13 <jtimon> sipa answered in #5975
14 2015-04-25 11:46:39 <s7r> can i test p2sh in testnet network/
15 2015-04-25 11:47:09 <dhill_> yes
16 2015-04-25 11:48:07 <s7r> i have one fast question. reading contracts page on bitcoin.it... down at #4 - External State (oracle script)
17 2015-04-25 11:48:08 <s7r> <hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG
18 2015-04-25 11:48:27 <s7r> can I have <hash> OP_DROP 2 <sons pubkey> <son's sister pubkey> <oracle pubkey> CHECKMULTISIG
19 2015-04-25 11:48:30 <s7r> e.g. 2/3 ?
20 2015-04-25 11:49:27 <s7r> I know this will somehow make the oracle useless, because the 2 parties can unlock the coins without the need of the oracle validation, but in my threat model one party is 100% honest, so it explains it
21 2015-04-25 11:51:46 <s7r> oh yes, I can .
22 2015-04-25 11:51:59 <s7r> nevermind, out of stupidity didn't read the full page
23 2015-04-25 13:00:16 <cfields_> jtimon: ah, is that your reason for re-opening/closing PRs so often?
24 2015-04-25 13:01:31 <jtimon> well, not always I have open more than appropriate by mistake and I'm sorry about that separately, but that's fixed just closing them and waiting for them to make sense independently or just forgetting about them
25 2015-04-25 13:02:44 <jtimon> but with "dependent" branches, (like 5995) I force push often to get builds in other plattforms, yes
26 2015-04-25 13:02:57 <cfields_> jtimon: well, it just dawned on me that you're using it to test combined PRs
27 2015-04-25 13:03:02 <jtimon> of course I can stop doing that
28 2015-04-25 13:03:15 <cfields_> jtimon: for that, i have some changes pending that will let you get test results without PRing them
29 2015-04-25 13:03:31 <cfields_> each person will be able to have their own travis test-runner
30 2015-04-25 13:03:42 <jtimon> oh, that's very cool
31 2015-04-25 13:04:06 <cfields_> see: https://travis-ci.org/theuni/bitcoin/builds/59502038
32 2015-04-25 13:04:18 <cfields_> it's pending a few upstream travis PRs and bugfixes
33 2015-04-25 13:05:33 <cfields_> maybe that'll help you out so that you can be confident that your big-picture changes are in good shape?
34 2015-04-25 13:06:18 <jtimon> yes, that would be great
35 2015-04-25 13:06:51 <jtimon> I mean, I also build locally but sometimes travis catches errors building without gui or in windows or something
36 2015-04-25 13:07:14 <cfields_> sure, i'm sorry i didn't pick up on what you were doing sooner
37 2015-04-25 13:08:04 <jtimon> no worries, I've been too impatient and that has ended up slowing things down
38 2015-04-25 13:12:57 <jtimon> I just lacked something to show that could make sense to people as a whole, 5768 was too much, 5946 and then 5995 were still unreadable, I'll just wait for 6051 and hopefully things will be clearer later (or people can just compare from that point, much better with most moves at the beginning)
39 2015-04-25 13:17:26 <jtimon> so 6051 is now redable and has its little "dependencies" cleanly separated
40 2015-04-25 13:18:15 <jtimon> my plan is to wait for that to be merged, rebasing as its little parts get merged
41 2015-04-25 13:18:45 <cfields_> sounds good
42 2015-04-25 13:18:50 <jtimon> and only then reopen 5995 as a dependent PR
43 2015-04-25 13:19:17 <sipa> jtimon: i don't watch the open pulls all that much, i mostly check my mailbox for changes to them, and all opens/closes send a mail to subscribers :)
44 2015-04-25 13:19:37 <sipa> so close+open is more "spam" :)
45 2015-04-25 13:19:56 <cfields_> yea, my current gmail PRs label is about 50% jtimon :)
46 2015-04-25 13:20:00 <jtimon> well, in fact, I could reopen it just after moving the the hheader part
47 2015-04-25 13:20:35 <jtimon> oh, I didn't remember that open/close mails you too
48 2015-04-25 13:20:41 <jtimon> sorry about that
49 2015-04-25 13:21:39 <cfields_> jtimon: and adding to that, from wumpus's POV, he's required to do a ton of homework/research to find out the current state of things, due to all the opening/closing
50 2015-04-25 13:22:52 <cfields_> so the dependent PRs really do more harm than good, i think. If anyone wants to see/discuss your big-picture work, that can all just happen in branches of your own repo
51 2015-04-25 13:22:59 <jtimon> yes, sorry, so there place to look at right now is 6051
52 2015-04-25 13:23:43 <jtimon> do you think that 6051 being open is harmful?
53 2015-04-25 13:24:33 <jtimon> (btw I added #6061 and #6063 to it as dependencies)
54 2015-04-25 13:24:58 <cfields_> having 1 open seems reasonable enough. But if it's going to be constantly churning, changing in scope, and rebasing, then it'll start to become a distraction
55 2015-04-25 13:25:32 <jtimon> no, no that won't change in scope, I promise
56 2015-04-25 13:26:21 <jtimon> I've learned my lesson, reducing the scope of a PR doesn't necessarily accelerate it
57 2015-04-25 13:26:52 <jtimon> and increasing it never does
58 2015-04-25 13:27:33 <cfields_> heh, ok
59 2015-04-25 13:40:21 <signor777> hey I have a question: is it possible to see in the blockchain which private key signed a spending transaction from a P2SH address? E.g. if alice and bob have a 2-of-2 P2SH address together and someday, the bitcoins are gone, can I later check if Alice or Bob signed the transaction that spent the bitcoins?
60 2015-04-25 13:41:23 <sipa> signor777: you can see which public keys digned
61 2015-04-25 13:41:25 <sipa> *signed
62 2015-04-25 13:43:31 <signor777> sipa: ah sorry I meant a 1-of-2 P2SH address. Is it still possible to prove *which* private key was used to sign the transaction?
63 2015-04-25 13:43:50 <sipa> signor777: which public key
64 2015-04-25 13:44:04 <sipa> or rather, the private key corresponding to which public key, yes
65 2015-04-25 13:44:19 <signor777> sipa: yes that's what I meant
66 2015-04-25 13:44:25 <sipa> (and the p2sh part does not matter)
67 2015-04-25 13:46:45 <sinetekVI> ok i have a git question. i have a banch in a PR, and want to rewrite history to undo the last commit
68 2015-04-25 13:46:58 <sinetekVI> basically to replace the commit with another
69 2015-04-25 13:47:30 <sinetekVI> i could do a revert, but that will spam the commit chain
70 2015-04-25 13:48:10 <sipa> you can rewrite pr branches, and force push them to github
71 2015-04-25 13:48:14 <sipa> the pr will be updated
72 2015-04-25 13:48:17 <jtimon> you can just add a new commit and label it with "SQUASHME" or something of the sort in the title
73 2015-04-25 13:48:28 <sinetekVI> yes, but how do i point HEAD to HEAD^
74 2015-04-25 13:48:30 <jtimon> and then squash it
75 2015-04-25 13:48:44 <sinetekVI> oh that's good
76 2015-04-25 13:48:59 <sinetekVI> so revert, then another commit, then squash all 3
77 2015-04-25 13:49:04 <sipa> signor777: git reset --hard HEAD^
78 2015-04-25 13:49:07 <jtimon> you can just git rebase -i name_of_the_base_branch_or_commit_id
79 2015-04-25 13:49:51 <jtimon> and with the interactive rebase you can squash, reword, move around or even edit
80 2015-04-25 13:50:16 <jtimon> I mean, there's more ways to use it but I find that one very simple
81 2015-04-25 13:51:39 <jtimon> the squashme commits are useful if you don't want to change the commit id that people have reviewd or tested already
82 2015-04-25 13:53:24 <jtimon> so you can ask people what they think about the latest change, when you're ready you squash locally and force push
83 2015-04-25 13:56:42 <cfields_> sinetekVI: in your case, just 'git reset HEAD^', fixup, and re-commit
84 2015-04-25 13:57:03 <cfields_> soft reset is what you're after here
85 2015-04-25 13:57:14 <sinetekVI> you need another commit though, otherwise it doesn't want to push
86 2015-04-25 13:57:25 <cfields_> sinetekVI: when you re-commit, it'll have a new commit id
87 2015-04-25 13:57:36 <sinetekVI> that's fine, its a PR
88 2015-04-25 13:58:09 <cfields_> sinetekVI: right, "it'll have a new commit id" means that you'll have something to push
89 2015-04-25 13:58:43 <cfields_> git reset HEAD^; fixup file; git commit file -m "message"; git push -f origin branch
90 2015-04-25 13:58:58 <sinetekVI> ok
91 2015-04-25 14:03:43 <jtimon> what's the difference between git reset HEAD^ and git reset HEAD~1 ?
92 2015-04-25 14:05:12 <cfields_> nothing, ^ is just short-hand for ~1
93 2015-04-25 14:05:16 <cfields_> HEAD^^ is HEAD~2
94 2015-04-25 14:05:29 <jtimon> oh, thanks
95 2015-04-25 14:06:40 <jtimon> another question: what's the criterion for when to edit a commit like this and when to keep the old ones and just add more on top waiting for a lter squash?
96 2015-04-25 14:06:49 <jtimon> s/lter/later
97 2015-04-25 14:07:22 <jtimon> and, in the later case, when is the right moment to do the squash?
98 2015-04-25 14:08:02 <jtimon> I feel I've made wrong decisions about this in the past
99 2015-04-25 14:08:08 <sipa> i almost always squash immediately
100 2015-04-25 14:08:10 <cfields_> i always squash locally as i go
101 2015-04-25 14:08:29 <sipa> unless it is a really large patchset, that people have reviewed in detail
102 2015-04-25 14:08:34 <cfields_> i just leave SQUASHMEs on PRs to avoid the need for re-ack's on reviewed code
103 2015-04-25 14:08:38 <cfields_> haha
104 2015-04-25 14:08:53 <cfields_> what he said :)
105 2015-04-25 14:09:27 <sipa> in moveonly commits, i would not squash if people have done actual moveonly verification
106 2015-04-25 14:09:35 <sipa> otherwise, just squash
107 2015-04-25 14:10:03 <sipa> the value of the review is almost always just "i agree with a change like this"
108 2015-04-25 14:10:24 <sipa> which is easily verified that it still holds after a squash
109 2015-04-25 14:10:58 <jtimon> ok, then I guess it's just that I change my mind too fast and too often
110 2015-04-25 14:11:30 <jtimon> yep, but what people test are commits ids
111 2015-04-25 14:11:34 <cfields_> jtimon: you can also use "fixup! foo" in commit messages, then 'git rebase --autosquash'
112 2015-04-25 14:11:55 <jtimon> oh, great!
113 2015-04-25 14:12:50 <jtimon> so s/SQUASHME:/fixup!/ in everything!
114 2015-04-25 14:13:24 <cfields_> that'd probably match your workflow, yea
115 2015-04-25 14:13:28 <jgarzik> jtimon, The general principle is always to create a set of logical changes, each of which will pass tests and properly bisect
116 2015-04-25 14:13:34 <jgarzik> jtimon, so don't over-squash
117 2015-04-25 14:14:03 <jgarzik> git bisect is your friend
118 2015-04-25 14:14:25 <jtimon> thanks jgarzik
119 2015-04-25 14:14:39 <jtimon> ACTION goes google git bisect
120 2015-04-25 14:15:51 <cfields_> git bisect is incredibly powerful. much like git itself, it's hard to imaging bisecting without it
121 2015-04-25 14:16:35 <sipa> jtimon: git bisect is useful, but ig uess what jgarzik means is: after every commit your code should compile and test, and not introduce any regressions or bugs
122 2015-04-25 14:17:10 <Luke-Jr> jtimon: git commit --fixup=commithash âº
123 2015-04-25 14:17:32 <sipa> jgarzik: jtimon's question is more about whether existing commits should be modified, or new one's added; rather than about having many or few commits in the first place
124 2015-04-25 14:17:50 <sipa> Luke-Jr: ooh, i did not know about that
125 2015-04-25 14:18:21 <cfields_> ah, me either. nice!
126 2015-04-25 14:18:41 <Luke-Jr> it basically just formats the commit message, but yeah it's handy
127 2015-04-25 14:18:51 <sipa> oh, ok
128 2015-04-25 14:19:05 <sipa> i hoped it would instantly modify that commit
129 2015-04-25 14:19:08 <Luke-Jr> lets you do squashing across commits too
130 2015-04-25 14:19:29 <Luke-Jr> eg, you can --fixup=HEAD^^ and rebase will automatically move it
131 2015-04-25 14:19:45 <jtimon> yes, all commits should always compile independently I always try to respect that, if it doesn't, I put ERROR: at the beginning
132 2015-04-25 14:19:55 <Luke-Jr> helps if you have a complex change that should be multiple commits ;)
133 2015-04-25 14:20:03 <jtimon> sorry, I have to eat, will read you later
134 2015-04-25 14:20:55 <sipa> jtimon: eating at 4pm? you muat be spanish
135 2015-04-25 14:21:08 <sipa> (i say this, just having finished lunch)
136 2015-04-25 14:23:09 <Luke-Jr> ACTION is still early enough in the day he thinks "eat? oh, maybe I should think about that today"
137 2015-04-25 14:25:22 <cfields_> Luke-Jr: i just keep a pile of Clif bars nearby so I don't have to think about that 'til dinner
138 2015-04-25 14:26:27 <Luke-Jr> cfields_: you don't have to eat those?
139 2015-04-25 14:26:42 <cfields_> one of those at some point while my code's compiling and i'm good for the day
140 2015-04-25 14:26:47 <cfields_> hmm?
141 2015-04-25 14:30:46 <Luke-Jr> ACTION wonders how he is swapping with Bitcoin-Qt the #1 memory user :/
142 2015-04-25 14:47:14 <aschildbach> Hey guys, I'm currently at an Intel Hackathon for the Edison and I'm trying to compile bitcoind on the Edison.
143 2015-04-25 14:47:18 <Starduster_> ACTION applauds for the great git tips ... (and the channel in general, although that's obvious)
144 2015-04-25 14:49:31 <sinetekVI> aschildbach: enough ram?
145 2015-04-25 14:55:38 <cfields_> aschildbach: compiling on it just for the hell of it? or with the aim of actually running bitcoind?
146 2015-04-25 14:56:05 <cfields_> if it's the latter, cross-build seems more useful?
147 2015-04-25 14:58:22 <cfields_> looks like the official x86 release binary should work fine on it
148 2015-04-25 15:02:21 <aschildbach> sinetekVI: It has 1 GB
149 2015-04-25 15:02:35 <aschildbach> cfields_: Well I don't know much about hell (-:
150 2015-04-25 15:02:42 <aschildbach> cfields_: I intend to run it, yes.
151 2015-04-25 15:03:12 <cfields_> aschildbach: i mean: what's your goal? to get it running and play with it? or hack on changes for it?
152 2015-04-25 15:03:58 <aschildbach> cfields_: I'm not much of a C++ coder, so I will probably just run it. But maybe I'll code a script for the APIs that shows things like the block height on a display
153 2015-04-25 15:04:13 <cfields_> aschildbach: ok. wget https://bitcoin.org/bin/bitcoin-core-0.10.1/test/bitcoin-0.10.1rc3-linux32.tar.gz
154 2015-04-25 15:04:19 <aschildbach> The kit contains dozens of sensors, for example an alocohol sensor (-:
155 2015-04-25 15:04:41 <aschildbach> cfields_: Ah I'd like to run current master, because of the pruning
156 2015-04-25 15:04:52 <aschildbach> cfields_: I only have about 1.5 Gigs of storage
157 2015-04-25 15:05:37 <cfields_> aschildbach: ah, ok. i'll build you one from master real quick
158 2015-04-25 15:05:49 <cfields_> but you might want to mount some nfs scratch space anyway?
159 2015-04-25 15:06:35 <aschildbach> I'm already compiling, but yeah it's painfully slow (-:
160 2015-04-25 15:07:42 <aschildbach> I installed Ubilinux, I think its 32 bits.
161 2015-04-25 15:07:44 <aschildbach> Linux ubilinux 3.10.17-yocto-standard-r2 #7 SMP PREEMPT Thu Feb 26 09:57:06 UTC 2015 i686 GNU/Linux
162 2015-04-25 15:08:12 <priidu> sorry for reasking a question, but maybe someone can give me more exact info
163 2015-04-25 15:08:24 <priidu> the question is - under which circumstances does the core client issue a 'walletnotify' notification?
164 2015-04-25 15:08:26 <sinetekVI> 1GB is a bit shot for compiling bitcoin..
165 2015-04-25 15:08:36 <sinetekVI> my box with 2GB is swapping all the time when compiling
166 2015-04-25 15:08:47 <priidu> is it "new transactions" + "transaction reaches 1 confirmation"?
167 2015-04-25 15:08:49 <sinetekVI> short*
168 2015-04-25 15:08:59 <priidu> or is there something else?
169 2015-04-25 15:09:33 <cfields_> aschildbach: you have a linux workstation handy?
170 2015-04-25 15:10:03 <dgenr8> priidu: only new transactions
171 2015-04-25 15:10:16 <aschildbach> Yes but it's 64 bits
172 2015-04-25 15:10:33 <cfields_> aschildbach: make -C depends HOST=i686-pc-linux-gnu NO_QT=1 && ./autogen.sh && ./configure --prefix=`pwd`/depends/i686-pc-linux-gnu && make
173 2015-04-25 15:10:49 <priidu> dgenr8: I've seen it rebroadcast the same txId quite often, that's why I'm wondering about the exact conditions
174 2015-04-25 15:10:57 <cfields_> that'll build you a 32bit bitcoind. after that, just hack as usual and 'make' to rebuild. then you can scp your binary over
175 2015-04-25 15:11:13 <aschildbach> I'll try that, thanks
176 2015-04-25 15:11:14 <priidu> dgenr: seems like there's something more to it then just new transactions
177 2015-04-25 15:11:30 <Luke-Jr> priidu: #bitcoin
178 2015-04-25 15:11:58 <priidu> Luke-Jr: right
179 2015-04-25 15:13:48 <cfields_> aschildbach: https://bitcoincore.org/cfields/bitcoind-32bit-1623f6e33 if you want it
180 2015-04-25 15:13:57 <cfields_> headed out for a bit, bbl
181 2015-04-25 15:14:33 <sinetekVI> the edisson is pretty cool
182 2015-04-25 15:14:44 <sdaftuar> cfields_: when you get a chance, is there any reason hooking up travis to our own public forks of bitcoin wouldn't work now? i've been doing it for a while with mine and haven't found any concrete problems
183 2015-04-25 15:15:24 <cfields_> sdaftuar: it works, it just takes ages to build because of the lack of caching. That should be fixed in the next week or two i hope
184 2015-04-25 15:15:52 <sdaftuar> cfields_: ah okay, thanks!
185 2015-04-25 15:16:49 <aschildbach> cfields_:
186 2015-04-25 15:16:53 <aschildbach> ./bitcoind-32bit-1623f6e33: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoind-32bit-1623f6e33)
187 2015-04-25 15:16:53 <aschildbach> ./bitcoind-32bit-1623f6e33: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by ./bitcoind-32bit-1623f6e33)
188 2015-04-25 15:17:15 <aschildbach> But never mind, I guess my compile will be finished at some point.
189 2015-04-25 15:17:16 <cfields_> aschildbach: blah, sec
190 2015-04-25 15:17:31 <sinetekVI> compile with gcc-musl
191 2015-04-25 15:17:44 <sinetekVI> statically i guess
192 2015-04-25 15:18:00 <cfields_> no
193 2015-04-25 15:18:04 <sinetekVI> ACTION wonders if it does work
194 2015-04-25 15:18:20 <cfields_> ./configure --enable-glibc-back-compat
195 2015-04-25 15:18:38 <cfields_> yes, musl builds/works fine with bitcoind
196 2015-04-25 15:20:18 <cfields_> aschildbach: https://bitcoincore.org/cfields/bitcoind-32bit-1623f6e33-r2
197 2015-04-25 15:21:12 <dgenr8> priidu: you're right, you get notified when it's seen in a block, or reorged out of the chain
198 2015-04-25 15:23:12 <aschildbach> cfields_: thanks, still: ./bitcoind-32bit-1623f6e33-r2: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by ./bitcoind-32bit-1623f6e33-r2)
199 2015-04-25 15:24:55 <aschildbach> cfields_: Out of curiosity, what kind of system do you use that can build Bitcoin Core in like 2 minutes?
200 2015-04-25 15:24:56 <cfields_> aschildbach: mm, indeed. clock_gettime. Looks like we'll need to solve that for master
201 2015-04-25 15:24:58 <cfields_> good to know!
202 2015-04-25 15:25:38 <cfields_> aschildbach: just a standard i7 machine. but ccache/ramfs/depends setup for quick build cycles
203 2015-04-25 15:25:44 <priidu> dgenr8: thans
204 2015-04-25 15:25:53 <sinetekVI> would it not make more sense to built statically for distribution?
205 2015-04-25 15:26:04 <sinetekVI> possibly with musl for size and speed
206 2015-04-25 15:26:23 <sinetekVI> hrm.
207 2015-04-25 15:26:30 <cfields_> sinetekVI: we link libstdc++ static. glibc really can't be used statically, so we maintain a set of back-compat modules for it
208 2015-04-25 15:27:09 <sinetekVI> but musl can
209 2015-04-25 15:27:45 <theymos> [1163063.985837] bitcoin-net[3700]: segfault at f80f6ba4 ip b6c7bfbd sp a37edd80 error 7 in libc-2.19.so[b6c05000+19c000]
210 2015-04-25 15:27:45 <theymos> My bitcoind crashed, and I see the following error in dmesg. Anything to worry about? I compiled this bitcoind myself, though I think the code is unmodified 0.10.0.
211 2015-04-25 15:28:40 <cfields_> yes. But it's not used nearly as much in practice with bitcoind as glibc, and devs hardly ever build/run against it. So it'd be a stretch to push out completely untested binaries as "official"
212 2015-04-25 15:28:50 <cfields_> theymos: got a stack-trace to go with it?
213 2015-04-25 15:29:35 <sinetekVI> Sounds fair.
214 2015-04-25 15:30:03 <cfields_> sinetekVI: if you're curious to try, musl has a toolchain wrapper that makes it easy to build against
215 2015-04-25 15:30:25 <sinetekVI> I'm more on the BSD side this month
216 2015-04-25 15:31:01 <cfields_> btw, the much more interesting thing to poke at there imo is libc++ as a replacement for libstdc++
217 2015-04-25 15:31:38 <theymos> cfields_: I didn't see one anywhere.
218 2015-04-25 15:31:48 <sinetekVI> cfields_: there's ellcc for that
219 2015-04-25 15:31:59 <cfields_> ellcc ?
220 2015-04-25 15:32:07 <sinetekVI> it's going to be a bit buggy however, I wouldn't really recommend retooling everything for that
221 2015-04-25 15:32:09 <sinetekVI> ellcc.org
222 2015-04-25 15:32:47 <sinetekVI> basically llvm/clang + libc++ + musl
223 2015-04-25 15:32:56 <sinetekVI> in a static package
224 2015-04-25 15:33:22 <cfields_> ah, neat
225 2015-04-25 15:34:37 <cfields_> well with the next bump for osx we'll likely switch to libc++, so we can test in pieces
226 2015-04-25 15:35:02 <cfields_> er actually, we might've done that already
227 2015-04-25 15:35:44 <cfields_> yikes, really got to go now. cya
228 2015-04-25 15:36:03 <sinetekVI> bye
229 2015-04-25 15:36:42 <sinetekVI> freebsd might be free of libstdc++ already
230 2015-04-25 15:36:48 <sinetekVI> not suse
231 2015-04-25 15:36:49 <sinetekVI> sure
232 2015-04-25 15:40:56 <aschildbach> cfields_: finished compiling (-:
233 2015-04-25 15:45:47 <dgenr8> priidu: hm. you also get a notify for every unconfirmed tx at startup, even watchonly
234 2015-04-25 15:51:24 <priidu> dgenr8: ok, great to know
235 2015-04-25 15:53:23 <Jimmy_> Hi, probably I'm not good enough to search the right answer, but I'm stuck in the signature of a transaction. I can't pull out a double SHA256 which has the same result of the various step-by-step guides. Which format should be used? Hex or string?
236 2015-04-25 15:53:42 <Jimmy_> thanks in advance for any link/input that can address me!
237 2015-04-25 15:59:31 <harding> Jimmy_: there's python code and a description of the most common problem (hash order reversal) here: https://bitcoin.org/en/developer-reference#hash-byte-order
238 2015-04-25 16:04:05 <Jimmy_> great! Reading this part then. Thanks a lot :)
239 2015-04-25 16:05:44 <harding> Jimmy_: my pleasure. :-)
240 2015-04-25 16:21:10 <Jimmy_> @harding unfortunately I'm still stuck: I can't get the same SHA256 of the online tests. I'm talking about the "step 14" of the simple "redeem raw tx" guide. I'm sure that the transaction is the same of the diagram, but once I apply the double sha to the string I got wrong results
241 2015-04-25 16:21:45 <Jimmy_> which format should I use? Binary, string, hex? What is the correct form that the double sha256 has to compute?
242 2015-04-25 16:21:51 <Jimmy_> which is*
243 2015-04-25 16:25:55 <harding> Jimmy_: let's switch to #bitcoin as that's better aimed towards these sort of issues. Once you're in that room, can you send me a link to the guide you're following?
244 2015-04-25 16:26:08 <Jimmy_> sure! Thanks again :)
245 2015-04-25 16:29:51 <harding> Jimmy_: ok, the answer to your question from the other room is that you should convert the raw transaction string you have (which is in hex) into binary. The pyhon code from the bitcoin.org dev ref I sent you earlier had a hex-to-binary conversion built in.
246 2015-04-25 16:31:12 <Jimmy_> I'll rush trying it now
247 2015-04-25 16:32:53 <harding> Jimmy_: (I just tried it myself, and I get the txid from the link you sent.)
248 2015-04-25 16:34:08 <harding> Gah; I switched back to #bitcoin-dev without realizing it. Sorry everyone.
249 2015-04-25 18:02:33 <belcher> the following txhex http://pastebin.com/Bx3kYjaP produces error 64: non-mandatory-script-verify-flag (No error) (code -26) when broadcast
250 2015-04-25 18:03:38 <belcher> any ideas what happened? its a regtest tx, i could upload regtest/ if required
251 2015-04-25 18:04:23 <belcher> its produced and signed by the pybitcointools library
252 2015-04-25 19:26:04 <phantomcircuit> belcher, you're just pushing data
253 2015-04-25 19:26:07 <phantomcircuit> why you doing that
254 2015-04-25 19:28:02 <phantomcircuit> belcher, non-null dummy argument to OP_CHEKMULTISIG ?
255 2015-04-25 19:29:02 <belcher> i am not phantomcircuit
256 2015-04-25 19:29:10 <belcher> just spending a normal pay to pub key hash
257 2015-04-25 19:29:50 <phantomcircuit> oh maybe non standard der encoding
258 2015-04-25 19:29:55 <phantomcircuit> (ie it's BER not DER)
259 2015-04-25 19:30:01 <belcher> ok
260 2015-04-25 19:30:30 <belcher> i opened an issue on github of the library that made this so its presumably their bug
261 2015-04-25 19:31:47 <phantomcircuit> belcher, those are all SIGHASH_SINGLE i think
262 2015-04-25 19:31:52 <phantomcircuit> is that what you were going for?
263 2015-04-25 19:32:20 <belcher> are they really?
264 2015-04-25 19:32:29 <belcher> i left it as the default, SIGHASH_ALL
265 2015-04-25 19:33:17 <phantomcircuit> "asm" : "3046022100e1153d33e20a2203a379883ed8be9d0155b102fe5d26d0b2fd89ba3cfb3ba454022100ce227b56b6b13ff286e37820d2818410da92c7e9cbb5ef10c8e4793a68148a9e01 0312a3424c47dd9cc87e50ae0f9993f4811fb84e80fa8b6f2cfedff144a01c94df"
266 2015-04-25 19:33:32 <phantomcircuit> oh wait last byte not first
267 2015-04-25 19:33:34 <phantomcircuit> derp
268 2015-04-25 19:34:06 <phantomcircuit> yeah they're SIGHASH_ALL
269 2015-04-25 19:34:07 <phantomcircuit> sorry
270 2015-04-25 19:34:41 <phantomcircuit> belcher, there's a null in there that shouldn't be there i think
271 2015-04-25 19:34:59 <phantomcircuit> 3046022100e1153d33e20a2203a379883ed8be9d0155b102fe5d26d0b2fd89ba3cfb3ba454022100ce227b56b6b13ff286e37820d2818410da92c7e9cbb5ef10c8e4793a68148a9e
272 2015-04-25 19:35:29 <belcher> what are you using to decode?
273 2015-04-25 19:36:24 <phantomcircuit> belcher, bitcoin-cli decoderawtransaction
274 2015-04-25 19:36:48 <phantomcircuit> 30 46 02 21 00e1153d33e20a2203a379883ed8be9d0155b102fe5d26d0b2fd89ba3cfb3ba454022100ce227b56b6b13ff286e37820d2818410da92c7e9cbb5ef10c8e4793a68148a9e
275 2015-04-25 19:36:53 <phantomcircuit> see the leading 00
276 2015-04-25 19:36:54 <sipa> signature looks DER to me
277 2015-04-25 19:36:55 <phantomcircuit> that's the problem
278 2015-04-25 19:36:59 <sipa> that leading 00 is correct
279 2015-04-25 19:37:34 <sipa> R would be a negative number otherwise
280 2015-04-25 19:37:55 <phantomcircuit> hmm
281 2015-04-25 19:43:59 <phantomcircuit> huh so something where CScriptCheck failed but returned SCRIPT_ERR_OK
282 2015-04-25 19:44:00 <belcher> does regtest use debug.log ? that file has just two lines in it for me
283 2015-04-25 19:44:00 <phantomcircuit> belcher, check debug.log for "VerifySignature failed"
284 2015-04-25 19:44:12 <belcher> wait hold on, this must be it
285 2015-04-25 19:45:45 <phantomcircuit> yeah it's in the regtest directory though
286 2015-04-25 19:46:00 <belcher> 2015-04-25 19:44:39 ERROR: CScriptCheck(): 951a38b33df011e92584deed5e67ce57ab9a0c1dba9e3c4b97fcb1cb4734a0ce:3 VerifySignature failed: Non-canonical DER signature
287 2015-04-25 19:47:25 <phantomcircuit> sipa, :P
288 2015-04-25 19:47:34 <phantomcircuit> maybe it's not the 00 but it's something
289 2015-04-25 19:52:29 <aschildbach> Is it a good or bad idea to put the -datadir on an old 8 GB SD card?
290 2015-04-25 19:52:55 <Luke-Jr> aschildbach: compared to a 100 GB hard drive, it's a bad idea
291 2015-04-25 19:53:14 <aschildbach> Luke-Jr: I'm using an Intel Edison, so a hard drive is no option
292 2015-04-25 19:53:27 <Luke-Jr> well, mention your other options :p
293 2015-04-25 19:53:41 <aschildbach> Well, buy a new modern SD card
294 2015-04-25 19:54:10 <Luke-Jr> quality is more important than age I think
295 2015-04-25 19:54:16 <aschildbach> Or optimize the 4 GB built-in memory to get the max out of it. Currently it's partitioned badly
296 2015-04-25 19:54:27 <Luke-Jr> high quality old 8 GB SD card may beat low quality new SD card
297 2015-04-25 19:54:45 <aschildbach> You're thinking of data loss?
298 2015-04-25 19:54:52 <Luke-Jr> speed mainly
299 2015-04-25 19:54:55 <aschildbach> ok
300 2015-04-25 19:55:36 <aschildbach> I'll let master download the blockchain with pruning on
301 2015-04-25 19:55:52 <PRab> aschildbach: Is 8GB too small? My datadir is currently ~40 GB.
302 2015-04-25 19:55:58 <PRab> Ah pruning.
303 2015-04-25 19:56:11 <aschildbach> Yes
304 2015-04-25 20:56:16 <aschildbach> Does a node with pruning enabled still contribute to the network?
305 2015-04-25 20:57:00 <Eliel> aschildbach: The only thing it can't do is help other new full nodes bootstrap.
306 2015-04-25 20:57:15 <aschildbach> (It will probably not accept connections though. Only connect itself.)
307 2015-04-25 20:57:25 <aschildbach> Ok cool
308 2015-04-25 21:03:47 <sipa> aschildbach: it also doesn't relay blocks (for now), or advertize NODE_NETWORK
309 2015-04-25 21:03:54 <sipa> aschildbach: so to SPV nodes, it is currently useless
310 2015-04-25 21:22:17 <michagogo> PRab: so you're using the right .yml files
311 2015-04-25 21:22:34 <PRab> for gitian?
312 2015-04-25 21:22:38 <michagogo> Yeah
313 2015-04-25 21:23:12 <michagogo> You pass gbuild what version of the source to pull in and make available to the build script
314 2015-04-25 21:23:25 <PRab> I think so. I just copy/pasted the commands from https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md
315 2015-04-25 21:23:35 <michagogo> But the build script itself comes from the yml file
316 2015-04-25 21:24:08 <michagogo> So wherever you're getting the yml file from, you need to check out the file that corresponds to the version you're building
317 2015-04-25 21:25:04 <PRab> That happens when I run "git checkout v${VERSION}", right?
318 2015-04-25 21:25:07 <michagogo> PRab: you were asking why you need to checkout the version you want to build before gbuilding, when you give gbuild the version in the --commit option
319 2015-04-25 21:25:10 <michagogo> Right
320 2015-04-25 21:25:37 <PRab> Ah, I thought there was something wrong with my pull request.
321 2015-04-25 21:25:59 <PRab> Couldn't gbuild to the checkout for you?
322 2015-04-25 21:26:03 <michagogo> You don't actually technically need to have the repo cloned. You just need to be able to get the yml files for the right version and point gbuild at that
323 2015-04-25 21:26:09 <michagogo> PRab: no
324 2015-04-25 21:26:26 <michagogo> Basically, you give gbuild a yml file with the build parameters
325 2015-04-25 21:27:03 <michagogo> That file (which contains the instructions to gbuild, including the build script) is just a file
326 2015-04-25 21:27:08 <PRab> I guess I have never actually looked at the contents of the yml file.
327 2015-04-25 21:27:26 <michagogo> Basically, gbuild isn't necessarily bitcoin-specific
328 2015-04-25 21:27:40 <michagogo> The yml file tells it what to build
329 2015-04-25 21:27:54 <PRab> I see. Does that also mean that gbuild isn't git specific either?
330 2015-04-25 21:28:08 <michagogo> For example, which files it needs to have, which packages it needs to install, etc
331 2015-04-25 21:28:13 <michagogo> PRab: well, sort of
332 2015-04-25 21:29:08 <michagogo> One of the things that the yml can say is "require this git repo"
333 2015-04-25 21:29:33 <michagogo> and when it says that, you use --commit to tell it which commit of that git repo to pull in
334 2015-04-25 21:30:00 <michagogo> So from that perspective, yes, it's built for use with git
335 2015-04-25 21:30:23 <michagogo> But you could have a yml that only uses inputs/cache
336 2015-04-25 21:31:17 <PRab> I think I understand.
337 2015-04-25 21:32:24 <PRab> I guess I there could be a wrapper script that ran both the git checkout and gbuild, but at some point if you are trusting the scripts too much, it defeats the point of doing gitian builds anyway.
338 2015-04-25 21:34:05 <michagogo> PRab: yeah, you could definitely make a script that does all that
339 2015-04-25 21:34:37 <michagogo> But like I said, you actually don't really even need to clone the repo and checkout that tag
340 2015-04-25 21:35:04 <michagogo> You just need to somehow get your hands on the yml files (build descriptors) for that version
341 2015-04-25 21:35:04 <PRab> Are the yml files provided anywhere else?
342 2015-04-25 21:35:27 <michagogo> Well, you could just download them directly from GH
343 2015-04-25 21:35:53 <michagogo> But yeah, cloning the repo is the easiest way
344 2015-04-25 21:36:26 <PRab> Just looking at the history of the yml files. Looks like they don't change much.
345 2015-04-25 21:36:29 <jj> |hi, anyone know where I can find cumulative (total) difficulty for a Bitcoin block? (I've been looking around and haven't found much)
346 2015-04-25 21:36:33 <michagogo> Erm, in my message from x:34:37, s/really/technically/
347 2015-04-25 21:36:41 <michagogo> jj|: what do you mean?
348 2015-04-25 21:36:58 <michagogo> PRab: well, it's mostly around big changes to the build system
349 2015-04-25 21:37:23 <michagogo> For example, from 0.8 to 0.9 to 0.10
350 2015-04-25 21:37:41 <sipa> jj|: in debug.log it's printed
351 2015-04-25 21:37:42 <jj> |say difficulty at block 1,2,3 is 10,20,30. cumulative difficulty at block3 would be 60 (10+20+30)
352 2015-04-25 21:37:45 <PRab> Anyway, I got all 3 rc's built and my gitian sigs submitted in a pull request.
353 2015-04-25 21:38:01 <michagogo> PRab: yeah, saw that, was just reading backlog
354 2015-04-25 21:38:08 <PRab> gotcha
355 2015-04-25 21:38:16 <michagogo> And saw that your question hadn't been answered
356 2015-04-25 21:38:26 <PRab> I appreciate the answer.
357 2015-04-25 21:39:18 <jj> |sipa: thanks i will look at debug.log. surprised it isn't around online with all the different explorers out there
358 2015-04-25 21:39:59 <sipa> 2015-04-25 16:56:17 UpdateTip: new best=00000000000000000f745df11926d17bf9e61e3bcfb27dcbccd03263486e1d18 height=353671 log2_work=82.680959 tx=66694927 date=2015-04-25 16:55:49 progress=0
359 2015-04-25 21:40:03 <sipa> .999999 cache=8326
360 2015-04-25 21:40:12 <sipa> that log2_work, is the 2-logarithm of the cummulative work
361 2015-04-25 21:40:24 <sipa> work is defined as 2^256 / target, for each block
362 2015-04-25 21:40:44 <sipa> or difficulty=1 equals 4295032833 work
363 2015-04-25 21:46:44 <jj> |sipa: i am trying to piece together the numbers to figure out what you're saying
364 2015-04-25 21:48:37 <sipa> if log2_work is X
365 2015-04-25 21:48:57 <sipa> that means that the sum of all difficulties of all blocks in the chain is 2^X * 4295032833
366 2015-04-25 21:49:24 <sipa> sorry, 2^X / 4295032833
367 2015-04-25 22:26:24 <jj> |sipa: thanks got it. i'm going to compute it as you wrote [i also did in a roundabout way to follow the math. log2_work = ln(CW) / ln(2); CW = e ^ (log2_work * ln(2) ); CD = CW / 4295032833]
368 2015-04-25 22:26:52 <sipa> now, why do you want the cummulative difficulty in the first place?
369 2015-04-25 22:38:00 <sipa> jj|: you should understand that "difficulty" is a human concept, only introduced to make the concept of work more readable
370 2015-04-25 22:38:14 <sipa> jj|: internally, everything is integer arithmetic using 'work'
371 2015-04-25 22:38:20 <rgenito> sipa, i love your explanations.
372 2015-04-25 22:38:39 <sipa> rgenito: yw :)
373 2015-04-25 22:38:51 <jtimon> thanks again jgarzik git bisect is my friend big time! no more full edit interactive rebase to stop and build at every stage. Now it feels embarrasing to not have thought about binary search for bugs in my own code...
374 2015-04-25 22:39:13 <sipa> jj|: you should definitely not ever use floating point code in consensus critical systems (rounding behaviour may differ across platforms etc)
375 2015-04-25 22:39:39 <rgenito> sipa soooo, would you also say to NEVER use floating point code in ANY financial software?
376 2015-04-25 22:39:45 <sipa> rgenito: yes
377 2015-04-25 22:39:52 <sipa> rgenito: well, for currency amounts
378 2015-04-25 22:39:59 <rgenito> ya -.- i'm battling that right now with my company's software
379 2015-04-25 22:40:07 <jtimon> jj| sipa maaku at most you use rational numbers
380 2015-04-25 22:40:13 <rgenito> like day 1 (or day 0) i'm like, "helllooooo we need to use integers >["
381 2015-04-25 22:40:42 <rgenito> and NOW they see some issues that they're not happy with. just minor stuff, at least we're not multiplying by these floating points many times and getting more and more inaccurate :D
382 2015-04-25 22:41:49 <jj> |i agree i want to use integers. so how to get cumulative work as int?
383 2015-04-25 22:42:23 <sipa> jj|: work is an integer (2^256 / target), just add it together :)
384 2015-04-25 22:42:33 <sipa> that's an integer division
385 2015-04-25 22:42:47 <sipa> jj|: and target is also an integer
386 2015-04-25 22:43:24 <jtimon> although rational numbers are safe, they introduce unwanted dependencies (until someone implements a libsecp-like gmp)
387 2015-04-25 22:43:25 <jj> |hmm log2_work=82.680959 is float
388 2015-04-25 22:43:42 <sipa> jj|: yes, because we took a log2 of it to print it...
389 2015-04-25 22:43:51 <sipa> jj|: humans don't like looking at 256 bit integers
390 2015-04-25 22:44:01 <sipa> internally, everything is 256 bit integers
391 2015-04-25 22:44:38 <jtimon> yep, humans are what we implement those ToString functions/methods for, no?
392 2015-04-25 22:44:45 <sipa> yes
393 2015-04-25 22:44:47 <jtimon> s/what/why
394 2015-04-25 22:45:04 <sipa> what ... for, or why ...
395 2015-04-25 22:46:06 <jj> |can i get log2_work=82.680959 as work displayed in hex (or decimal) without recompiling on my own?
396 2015-04-25 22:46:12 <sipa> no
397 2015-04-25 22:46:47 <jj> |ok thanks ;)
398 2015-04-25 22:47:44 <jtimon> oh yeah what for was correct, thanks
399 2015-04-25 23:10:36 <robbak> Anyone have any ideas why current git on FreeBSD should be failing with internal compiler error on clang and seg fault on gcc?
400 2015-04-25 23:11:34 <robbak> I did bisect it, but it has been doing it for a while, and there were other faults that masked it, so I cuoldn'ttrack it down.
401 2015-04-25 23:12:08 <robbak> (thankfully, no problems with 10.1rc3.)