1 2014-07-09 00:24:21 <anton000> anyone here familiar with bip0032 and wiling to answer a few queries?
  2 2014-07-09 00:43:15 <kschoice> I'm trying to build an android bitcoin wallet from source code to learn more.. I have https://github.com/schildbach/bitcoin-wallet and from what I understand, I need https://github.com/bitcoinj/bitcoinj as a dependancy..  Does anybody know of some document that can explain how I get the dependancy working in the wallet?
  3 2014-07-09 01:41:49 <ttgg> hello is there a newbies guide to working with the bitcoin source anywhere?
  4 2014-07-09 01:43:04 <ttgg> I want to make another cryptocoin, but with big aspirations. This one will be a very interesting one and a keystone to the future of Bitcoin mainstream adoption.
  5 2014-07-09 01:43:49 <ttgg> :) It's going to have end user experience in mind in a way Bitcoin currently does not. :3
  6 2014-07-09 01:44:12 <kazcw> are you going to make kittehcoin?
  7 2014-07-09 01:44:43 <kschoice> Lol
  8 2014-07-09 01:44:56 <ttgg> trust me, sometimes the biggest ideas have the most humble beginnings
  9 2014-07-09 01:45:15 <kazcw> I don't doubt you have a big idea
 10 2014-07-09 01:45:31 <ttgg> I don't want to talk about the IP every time I talk about my ideas on here, people run with them
 11 2014-07-09 01:45:40 <gmaxwell> This is not the channel for them, however.
 12 2014-07-09 01:46:16 <gmaxwell> ttgg: heaven forbid that the flow of value to you ever go the other direction.
 13 2014-07-09 01:46:20 <ttgg> which is why I'm looking for the best guide for a newbie trying to work with the Bitcoin source
 14 2014-07-09 01:46:57 <ttgg> I talked about the idea of side chains on irc long before it was a tangible idea
 15 2014-07-09 01:47:21 <gmaxwell> Oh so you're a fraud too? Please leave.
 16 2014-07-09 01:47:22 <ttgg> as well as an exchange that had an automated method of proving solvrncy
 17 2014-07-09 01:47:33 <berndj-blackout> ttgg, before you can run you need to learn to walk; a good way to get familiar with the bitcoin source so you can modify it one day with confidence would be things like reviewing code, especially in pull requests where you can't just trick yourself into saying "it's in the release version, it must be okay"
 18 2014-07-09 01:48:15 <ttgg> I tried reading github commits to get some ideas of the work currently being done
 19 2014-07-09 01:49:01 <gmaxwell> berndj-blackout: he isn't interested in working on bitcoin, he said he wants to create an altcoin (and apparently also claim credit for other people's ideas)
 20 2014-07-09 01:49:25 <ttgg> I want to change some fundamentals in mining permission, I'm sure a branch that requires authentication exists, or I could modify pool code, but I'm trying to learn how to walk here.
 21 2014-07-09 01:49:40 <kazcw> oh lord
 22 2014-07-09 01:50:21 <ttgg> just because I'm working on utilizing an alt doesn't mean I'm not trying to contribute to bitcoin
 23 2014-07-09 01:50:53 <ttgg> at the core of my idea is a service that the Bitcoin community needs
 24 2014-07-09 01:51:55 <gmaxwell> ttgg: please leave.
 25 2014-07-09 01:51:56 <ttgg> also are the irc chats logged anywhere gm? I can go back and show you where I talked about the side chain idea if you're sour about that claim
 26 2014-07-09 01:52:08 <gmaxwell> ttgg: yes, see the topic
 27 2014-07-09 01:55:25 <ttgg> http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/01/03
 28 2014-07-09 01:56:48 <ttgg> I was thinking about side chains as the idea I came up with when asking about taking transactions off chain and rejoining them by having nodes of people's value get put back into the chain by splitting up the private key
 29 2014-07-09 01:57:12 <berndj-blackout> if you click on one of the timestamps it'll add a #fragment to the url
 30 2014-07-09 01:57:22 <ttgg> I understand its not specific in the log, but its what I was thinking about
 31 2014-07-09 01:57:53 <ttgg> yeah its all near the bottom
 32 2014-07-09 01:58:42 <ttgg> I talked about an exchange auto proving solvency just a little while before that new Korean exchange or whatever started to do it
 33 2014-07-09 01:59:13 <ttgg> so I'm a little skeptical about laying out my ideas, i want to do this one on my own
 34 2014-07-09 02:00:21 <ttgg> if the bitcoin-dev community doesn't want to help me that's fine. I just thought you guys might know some good resources on the subject
 35 2014-07-09 02:00:41 <berndj-blackout> i can guarantee you with 99.9999% that your ideas aren't being "stolen". there are 7 billion people on earth; even good ideas emerge multiply independently. it's just that some of those people actually execute
 36 2014-07-09 02:00:41 <ttgg> I intend to read and learn :)
 37 2014-07-09 02:01:13 <gmaxwell> ttgg: Okay. Sidechains doesn't have anything to do with your question there, if your motivation was something like that you never said so there— moreover the idea was described in some detail long before that, e.g. http://download.wpsoftware.net/bitcoin/wizards/2013/12/13-12-18.log
 38 2014-07-09 02:01:35 <ttgg> thanks gmaxwell :3
 39 2014-07-09 02:02:08 <gmaxwell> (actually the prior day, http://download.wpsoftware.net/bitcoin/wizards/2013/12/13-12-17.log 19:24 < BlueMatt> are there any serious or semi-serious proposals for how to fix an altcoin 1:1 to bitcoin without a large cost to bitcoin miners given some hardfork changes to bitcoin? )
 40 2014-07-09 02:02:21 <ttgg> I shall lay no claims anymore I'm seriously just looking for some good starter help
 41 2014-07-09 02:02:23 <gmaxwell> Though thats not the earliest origin of the ideas.
 42 2014-07-09 02:02:55 <ttgg> in terms of resources to read
 43 2014-07-09 02:03:30 <gmaxwell> ttgg: also, the solvency proofs that were getting attention— it took mtgox going down to get anyone to care, but petertodd and I described the whole protocol for it in march 2013 https://people.xiph.org/~greg/bitcoin-wizards-fraud-proof.log.txt
 44 2014-07-09 02:03:56 <gmaxwell> No harm no fowl. It's an interesting space and lots of common ideas arise both good and bad.
 45 2014-07-09 02:04:04 <ttgg> ah your idea was the one probably borrowed from then
 46 2014-07-09 02:04:24 <ttgg> march is when that exchange operator started his "idea"
 47 2014-07-09 02:05:03 <gmaxwell> ttgg: At my request iwilcox wrote up a very good summary to bludgeon exchanges with https://iwilcox.me.uk/2014/proving-bitcoin-reserves it's been deployed in a number of places.
 48 2014-07-09 02:05:07 <berndj-blackout> ttgg, my recommendation stands: start by reading profusely. just get into the bitcoin source and start reading. you'll almost accidentally find something you can improve / change, even if it improves only your own idiosyncratic use cases
 49 2014-07-09 02:05:59 <ttgg> is there some guide to what files or chunks of code are for? or is it commented well enough for that?
 50 2014-07-09 02:06:31 <ttgg> like a map of the source or a legend, if you will?
 51 2014-07-09 02:07:02 <gmaxwell> ttgg: the codebase without the gui is about 30,000 lines of code.
 52 2014-07-09 02:07:08 <gmaxwell> I suggest simply reading it all twice.
 53 2014-07-09 02:07:25 <ttgg> :D K thank you gmaxwell
 54 2014-07-09 02:07:27 <gmaxwell> (the first quickly since you won't understand much)
 55 2014-07-09 02:07:33 <ttgg> Right
 56 2014-07-09 02:08:15 <ttgg> As I go along I'll construct a map of the source for any newbies who follow behind me. :3
 57 2014-07-09 02:08:57 <gmaxwell> ttgg: I'd still encourage you to not create an altcoin. Most interesting things for the ecosystem can be done without doing so, and Andy's WIP document on altcoins gives some useful background: https://download.wpsoftware.net/bitcoin/alts.pdf
 58 2014-07-09 02:09:44 <ttgg> my "alt" would be for my own internal testing anyway
 59 2014-07-09 02:10:08 <jrick> why would you create an entire other coin just for testing?
 60 2014-07-09 02:10:31 <gmaxwell> well why not? I do that all the time, perfectly reasonable.
 61 2014-07-09 02:10:46 <gmaxwell> We have a special mode in bitcoin (regtest) for basically doing that.
 62 2014-07-09 02:10:55 <ttgg> im testing some changes that I doubt anyone would want in RPC without a proof of concept
 63 2014-07-09 02:11:14 <ttgg> like, a good standalone proof
 64 2014-07-09 02:11:16 <gmaxwell> Since you can't really just test mining against the real system, or even testnet.
 65 2014-07-09 02:11:17 <jrick> right but its still essentially bitcoin, don't need to go forking off all the repos just for it
 66 2014-07-09 02:11:23 <jrick> we do the same for simnet in btcd
 67 2014-07-09 02:12:05 <ttgg> would it be easier for me to learn to use the testnet or regtest than just run a alt on my own internal network?
 68 2014-07-09 02:12:40 <ttgg> I mean if I control all nodes of my alt, I can fork it all day and not care
 69 2014-07-09 02:13:03 <gmaxwell> you need hundreds of lines of patches to make an alt, regtest is a commandline switch.
 70 2014-07-09 02:13:06 <jrick> ttgg: google testnet in a box, simnet (btcd specific) is essentially the same thing
 71 2014-07-09 02:13:10 <jrick> a private alt network
 72 2014-07-09 02:13:15 <davec_> well simnet is slightly different than regtest in that it also actively avoids typical spreading
 73 2014-07-09 02:13:28 <ttgg> alright I'll do that
 74 2014-07-09 02:13:31 <davec_> by ignoring addr, disabling inbound connections, etc
 75 2014-07-09 02:13:34 <gmaxwell> regtest is somewhat better than testnet in a box because it has block-on-demand.
 76 2014-07-09 02:13:38 <ttgg> it sounds like the better approach
 77 2014-07-09 02:13:43 <davec_> regtest is more for the testnet in a box block tester
 78 2014-07-09 02:14:11 <gmaxwell> yes, it was designed for the blocktester, but it's perfectly find for local testing of random ideas too.
 79 2014-07-09 02:14:45 <ttgg> can it be made so only authenticated miners be allowed to solve blocks?
 80 2014-07-09 02:15:28 <ttgg> I know that's not something anyone wants to entertain with the idea of decentralization, but there's a good reason I want to do it
 81 2014-07-09 02:16:44 <ttgg> also is there a way to hard limit the amount of blocks a node is allowed to submit? (this sounds silly, but I swear this has nothing to do with ghash or the stupid 51% idea)
 82 2014-07-09 02:17:10 <gmaxwell> Sure, maybe I'll be making an implementation available that uses something much like signed blocks sometime soon.
 83 2014-07-09 02:17:39 <ttgg> >;p I see what you did there
 84 2014-07-09 02:17:51 <gmaxwell> ttgg: bitcoin mining is an anonymous system the partitipants don't have identities at all. They can come and go as they please and the system has no idea if two blocks are from the same party or not.
 85 2014-07-09 02:18:30 <ttgg> is there a way I can put that functionality in? because I want to test an idea pertaining to it
 86 2014-07-09 02:18:59 <jrick> that would require patches
 87 2014-07-09 02:19:10 <gmaxwell> ttgg: well that was half tongue in cheek, one way to do a technology demo for sidechains is to replace the fancy script evaluation with multisignature. (you can generally replace any kind of fancy script evaluation with multisignature).. all stuff thats been discussed in #bitcoin-wizards in the past.
 88 2014-07-09 02:19:23 <gmaxwell> ttgg: perhaps! depends on exactly what you want.
 89 2014-07-09 02:19:50 <ttgg> can I pm you gm?
 90 2014-07-09 02:19:53 <gmaxwell> (I mean it depends on what you want if its possible to do; and also if you have the capability to write it— but the latter I couldn't even guess while knowing what you want)
 91 2014-07-09 02:20:03 <gmaxwell> ttgg: no, I might learn of some of your secret "IP". :P
 92 2014-07-09 02:20:24 <ttgg> haha I'll open source it after I make enough of it to not embarrass myself
 93 2014-07-09 02:21:11 <ttgg> I don't want any code I suggest anywhere to be garbage
 94 2014-07-09 02:21:33 <gmaxwell> For the record; anyone can feel free to PM me whenever. Just as equally though, they shouldn't be offended if I don't always have time to respond.
 95 2014-07-09 02:22:06 <ttgg> understood, as a man with 52 good commits on record I assume you're busy frequently
 96 2014-07-09 02:22:16 <gmaxwell> ttgg: oh, you'd doomed then— almost all code is garabage, certantly all of mine. :)  Someday mankind might learn to create good code, but I suspect today is not that day.
 97 2014-07-09 02:22:29 <squidicuz> xD
 98 2014-07-09 02:22:35 <ttgg> I have to go now bbl
 99 2014-07-09 02:24:35 <Emcy> very nihilistic gmax
100 2014-07-09 02:26:10 <gmaxwell> Emcy: after seeing places where there was a 20 line piece of code, formally proven correct, analyized by engineers with a cumulative 100 man years of expirence between them... still turn out to have bugs.  It's easy to be a bit jaded. :)
101 2014-07-09 02:26:52 <Emcy> sound like an interesting story
102 2014-07-09 02:29:43 <gmaxwell> I'm synthesizing there, but in general its an every day thing. Software which has ever reason to be correct is none the less not correct.
103 2014-07-09 02:30:59 <Emcy> what if machines just arnt as deterministic as we think lol
104 2014-07-09 02:31:17 <midnightmagic> Emcy: I have an XMOS multi-core here that thinks it's deterministic
105 2014-07-09 02:31:30 <Emcy> xmos?
106 2014-07-09 02:31:31 <midnightmagic> who knows if it is
107 2014-07-09 02:31:58 <midnightmagic> http://www.xmos.com/startkit
108 2014-07-09 02:43:26 <Emcy> i remember some shittng of pants over that actually, about the cern ftl neutrino caper. Like what if computers work as instructed until they dont due to unforeseen tunelling effects
109 2014-07-09 02:43:30 <Emcy> much lols
110 2014-07-09 04:01:03 <Luke-Jr> lol @ my answer seems more better XD
111 2014-07-09 06:45:07 <wumpus> @warren: btw, it seems the daily builds aren't very daily anymore :(
112 2014-07-09 06:45:59 <wumpus> warren: would be nice to have one in current state, with watchonly merged and the windows build fixed
113 2014-07-09 07:40:52 <volante> i'm trying to build the master branch and i get: configure.ac:115: required file `src/config/bitcoin-config.h.in' not found
114 2014-07-09 07:41:28 <volante> i used to be able to build master a few weeks ago, so either something has changed or i've forgotten a step
115 2014-07-09 07:46:45 <jcorgan> be sure to run ./autogen.sh, that will populate that file
116 2014-07-09 07:47:03 <jcorgan> and now master requires having libtool installed
117 2014-07-09 07:48:29 <volante> hmm, ok that generated a new configure script, and when i run it i get this error:
118 2014-07-09 07:48:32 <volante> ./configure: line 2732: syntax error near unexpected token `disable-shared'
119 2014-07-09 07:50:01 <volante> ah, looks related to libtool
120 2014-07-09 07:51:07 <volante> ok, libtool installed and its all good now.  thanks.
121 2014-07-09 07:53:51 <jcorgan> \o/
122 2014-07-09 08:42:12 <joedoe-> hello, any ways to reduce bitcoind memory usage? higher I/O would not be a problem
123 2014-07-09 09:28:36 <wumpus> joedoe-: easiest ways are reducing dbcache and max number of connections
124 2014-07-09 09:28:58 <joedoe-> second one didnt help
125 2014-07-09 09:29:13 <wumpus> oh sure it only helps if you actually get a lot of connections
126 2014-07-09 09:31:41 <joedoe-> dbcache also didnt help much
127 2014-07-09 09:39:22 <wumpus> after the initial sync the memory usage should also level off
128 2014-07-09 09:42:50 <volante> is src/qt/Makefile really supposed to be tracked in git?
129 2014-07-09 09:43:28 <wumpus> yes
130 2014-07-09 09:43:38 <volante> my makefile was modified with i ran autogen / configure, and im not sure if that's supposed to be committed or not if i commit a patch
131 2014-07-09 09:43:39 <wumpus> it's no longer generated
132 2014-07-09 09:44:11 <wumpus> it should certainly not be modified when you run autogen/configure
133 2014-07-09 09:46:17 <volante> ok, im not sure why i had a massive diff on that file.  i hard reset and then tried autogen/configure again and it left it unmodified
134 2014-07-09 09:46:51 <volante> might have been because i ran old configure scripts before running autogen
135 2014-07-09 09:48:06 <wumpus> that's likely
136 2014-07-09 09:48:30 <wumpus> ideally after checking out a new version you should at least run autogen.sh
137 2014-07-09 09:49:01 <wumpus> at least if build system files changed
138 2014-07-09 09:49:06 <volante> ahh ok. didn't realise that.
139 2014-07-09 09:53:25 <wumpus> I forget it too sometimes
140 2014-07-09 10:12:29 <volante> I am getting this potential deadlock warning on a clean master branch when syncing: http://pastebin.com/raw.php?i=SHefhuVr
141 2014-07-09 10:12:36 <volante> is that a known issue?
142 2014-07-09 10:14:52 <wumpus> yes, I've seen it before
143 2014-07-09 10:15:09 <wumpus> though I'm not sure it's the same one
144 2014-07-09 10:15:27 <wumpus> thanks for testing with debug logorder
145 2014-07-09 10:15:49 <wumpus> lockorder*
146 2014-07-09 10:19:07 <volante> should that be a concern?  i'm working on the patch to make ThreadMessageHandler fire as needed, so it will probably increase the chance of that deadlock actually happening
147 2014-07-09 10:19:18 <wumpus> yes, it is a concern
148 2014-07-09 10:33:58 <wumpus> joedoe-: another way to reduce memory usage may be to reduce the thread stack size (ulimit -s), the default on my system is 8mb per thread. Not sure what amount is safe, though.
149 2014-07-09 10:36:06 <wumpus> but I wouldn't be surprised if halving it still worked
150 2014-07-09 10:36:19 <joedoe-> yeah, I've been thinking about it and had same feeling regarding safety
151 2014-07-09 10:37:12 <joedoe-> maybe gcc should be told somehow about limited stack. I see some related settings in manual
152 2014-07-09 10:37:21 <wumpus> well the most that can happen with a stack overflow is that it just crashes with a segmentation fault, there is an unwritable guard page before it
153 2014-07-09 10:38:03 <wumpus> no, you don't need to tell gcc about it
154 2014-07-09 10:38:33 <wumpus> there have been some recent changes in master to avoid allocating some 200k buffers on the stack, that will help
155 2014-07-09 10:55:26 <wumpus> joedoe-: disabling the wallet also saves ~40MiB, possibly more if you compile without it too
156 2014-07-09 10:56:46 <joedoe-> thank you
157 2014-07-09 10:57:57 <wumpus> there is also a patch to be able to set the limit on the maximum number of orphan blocks that is stored in memory, not sure if it is merged yet
158 2014-07-09 10:58:47 <wumpus> in 0.9.2 this maximum is 750, so it can also be a substantial amount of memory, although after the initial sync it shouldn't be receiving that many orphans in the first place
159 2014-07-09 11:01:58 <wumpus> I did some heap profiling during an reindex in https://github.com/bitcoin/bitcoin/pull/4413 , the weird thing was that it only showed up to ~160 mb of heap usage, while the typical usage is much larger (a crude script parsing /proc/pid/maps shows ~490MiB for heap in my running node), so I'm not sure what the difference comes from
160 2014-07-09 11:02:53 <wumpus> anyhow if anyone is handy with these kinds of things and could help out find if there is still low-hanging fruit that could help the project a lot...
161 2014-07-09 11:04:16 <sipa> yeah, i have no good idea where we are wasting heap
162 2014-07-09 11:04:41 <sipa> mapBlockIndex should be like 40 mb
163 2014-07-09 11:05:57 <sipa> the heap spikes you noticed when we flush the coin cachre were interesting
164 2014-07-09 11:06:29 <sipa> but i would expect that using a hashmap instead would fix average heap usage too
165 2014-07-09 11:08:11 <sipa> s/fix/improve/
166 2014-07-09 11:08:14 <wumpus> yeah, those peaks are when both our code and leveldb starts allocating memory like crazy
167 2014-07-09 11:08:59 <wumpus> I profiled a reindex, maybe I should look at an up-to-date node
168 2014-07-09 11:09:13 <sipa> so, one thing i've thinking about for a while is turning it into an lru cache, rather than a reset-the-world-when-we-grow-too-large
169 2014-07-09 11:09:28 <sipa> boost has an interesting multiindex library
170 2014-07-09 11:09:50 <sipa> which allows you to construct a contain that has both a hashmap fornindexing, and a linked list, etc
171 2014-07-09 11:10:05 <wumpus> sounds like smarter behavior, also for performance
172 2014-07-09 11:10:10 <sipa> so we could have two lru lists, one for dirty and one for nondirty
173 2014-07-09 11:10:27 <wumpus> interesting
174 2014-07-09 11:10:41 <sipa> and when the relatove size of the dirty one grows too large, flush, and make everything nondirty
175 2014-07-09 11:10:49 <sipa> instead of wiping
176 2014-07-09 11:11:21 <sipa> and you could go further by keeping track of whether a cache entry was in fact created since the last flush
177 2014-07-09 11:11:21 <wumpus> exactly
178 2014-07-09 11:11:40 <sipa> so if it is deleted before the next one, you just delete it without any disk touching
179 2014-07-09 11:15:05 <sipa> in headersfirst i have an improvement for setBlockImdexValid, as it only needs to maintain better entries than the current state
180 2014-07-09 11:15:23 <sipa> i'll backport
181 2014-07-09 11:20:25 <wumpus> oh so there are still a lot of ways in which the caching could be improved
182 2014-07-09 11:20:39 <wumpus> great!
183 2014-07-09 11:22:11 <wumpus> I'm not sure about the database (well, rev file) issue that I had with headers-first, maybe I should try a new sync and see if it happens again
184 2014-07-09 11:22:54 <sipa> perhaps the selfcheck doesn't support missing blocks
185 2014-07-09 11:23:05 <sipa> that's trivial to fix
186 2014-07-09 11:23:17 <wumpus> I wouldn't be surprised if it didn't
187 2014-07-09 11:24:09 <sipa> in fact, i would be surprised if it did, it wasn't written to
188 2014-07-09 11:25:50 <sipa> also, i'm not sure if the version of the comparison tool in pulltester supports getheaders
189 2014-07-09 11:26:39 <sipa> more recent versions may, but if they rely on blocks being downloaded whenever they are announced things will fail probably
190 2014-07-09 14:01:58 <sipa> wumpus: hmm, the verification should work in headersfirst... it only verifies our active chain (which should have all fully available and connected blocks)
191 2014-07-09 14:05:45 <wumpus> strange, then
192 2014-07-09 14:06:52 <wumpus> I tried again and cannot reproduce it either
193 2014-07-09 14:59:52 <jaromil> hi all. silly question maybe if already asked sorry
194 2014-07-09 14:59:58 <jaromil> is anyone working already on this? https://bitcointalk.org/index.php?topic=600436.msg6621440#msg6621440
195 2014-07-09 15:00:31 <jaromil> the timestamp issue and that paper thingie from ucla smearing it all over the place
196 2014-07-09 15:01:59 <wumpus> ugh there it is again (with -checklevel=4 and -checkblocks=0) http://www.hastebin.com/ojejedatoh.vhdl
197 2014-07-09 15:02:55 <wumpus> this time I copied my normal blockchain+databases and ran the headers-only patch with it for a while, then did that check
198 2014-07-09 15:03:48 <wumpus> whoa never mind something is going very wrong here with the disk
199 2014-07-09 15:07:27 <wumpus> ignore the bug report, probably just a corruption issue
200 2014-07-09 15:12:37 <chichov> how come https://bitcoin.org/en/developer-guide#signature-hash-types states that SIGHASH_NONE signs all of the inputs and SIGHASH_SINGLE only the currently signed input, when there is no differentiation for that behaviour in the code? (see https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L1053)
201 2014-07-09 15:15:55 <hearn> chichov: they control the *outputs* that are signed
202 2014-07-09 15:16:28 <chichov> hearn: how do you mean that?
203 2014-07-09 15:16:36 <gmaxwell> chichov: the relevant control is https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L1062
204 2014-07-09 15:17:07 <chichov> oh, that it's about the outputs, not the inputs?
205 2014-07-09 15:17:22 <hearn> SIGHASH_SINGLE signs only the output at the same index as the input. the others can change.
206 2014-07-09 15:17:45 <chichov> "others" being the outputs?
207 2014-07-09 15:17:49 <sipa> yes
208 2014-07-09 15:18:20 <chichov> then it is a flaw in the developer guide when it states under SIGHASH_SINGLE "signs only this input"?
209 2014-07-09 15:19:56 <wumpus> yes - it should be updated to what hearn says
210 2014-07-09 15:20:21 <chichov> wumpus: thank you
211 2014-07-09 15:21:00 <chichov> I have another question, what role does the zero'd sequence number play in SIGHASH_NONE and SIGHASH_SINGLE?
212 2014-07-09 15:21:40 <hearn> nothing anymore. the original design of contracts (by satoshi) allowed you to replace transactions in the memory pool
213 2014-07-09 15:21:48 <hearn> however that feature was disabled
214 2014-07-09 15:21:55 <chichov> yea, transaction replacement is long gone
215 2014-07-09 15:22:06 <hearn> well, i still want to bring it back once we have a good solution for the resource usage issues
216 2014-07-09 15:22:14 <hearn> one day :)
217 2014-07-09 15:22:41 <chichov> just wondering, if it would still be in place, how can you exchange the transaction input if all other parts of it are signed?
218 2014-07-09 15:23:20 <hearn> the point of the sighash flags is that parts aren't signed
219 2014-07-09 15:24:03 <chichov> exactly, but in this case for example all the prevout's are signed
220 2014-07-09 15:24:56 <chichov> that's why I'm wondering how the transaction input can be replaced in this case, if at all
221 2014-07-09 15:25:11 <chichov> there must be some point I'm missing
222 2014-07-09 15:25:29 <lclc> sipa, hearn: are you going to be at the Zurich Bitcoin Meetup today?
223 2014-07-09 15:25:37 <hearn> when is it?
224 2014-07-09 15:25:52 <hearn> probably not, a friend of mine has a birthday drinks tonight. though actually he is into bitcoin too so maybe he'd like to go along later, hah :)
225 2014-07-09 15:26:07 <lclc> today, at 7
226 2014-07-09 15:26:08 <hearn> chichov: sequence numbers are always blanked out with the special sighash modes
227 2014-07-09 15:26:12 <hearn> lclc: where?
228 2014-07-09 15:26:33 <lclc> Kafi Schoffel,  Schoffelgasse 7
229 2014-07-09 15:26:54 <chichov> hearn: then there is no logical connection to the transaction replacement mechanism here. it's just a rule?
230 2014-07-09 15:27:04 <hearn> how do you mean?
231 2014-07-09 15:27:20 <hearn> lclc: oh, i was there earlier today actually. ok, i might come along for a bit. meeting my friend at 8:30 at paddy's
232 2014-07-09 15:27:35 <lclc> ok cool :)
233 2014-07-09 15:27:37 <hearn> chichov: the actual code that does the tx replacement is gone, but sequence numbers and the signing rules for them remain
234 2014-07-09 15:27:41 <chichov> I thought that it'd have some special meaning, which would allow one to e.g. replace the input
235 2014-07-09 15:27:57 <sipa> lclc: sorry, in the wrong continent :)
236 2014-07-09 15:28:34 <lclc> sipa: did you move? or holiday :)
237 2014-07-09 15:28:53 <chichov> hearn: the conundrum is the following - why set the sequence number to 0, if everything else is fixed by the signature anyway?
238 2014-07-09 15:29:06 <sipa> lclc: holiday
239 2014-07-09 15:30:08 <hearn> chichov: it's not
240 2014-07-09 15:30:16 <hearn> chichov: e.g. consider signing with SIGHASH_SINGLE
241 2014-07-09 15:30:22 <lclc> enjoy :)
242 2014-07-09 15:30:32 <hearn> chichov: other outputs are blanked. they can be changed by a new version of the transaction with a higher sequence number, without invalidating your own signature
243 2014-07-09 15:31:25 <chichov> ahhh, so it's about transaction output replacement then
244 2014-07-09 15:32:01 <chichov> hearn: nothing clears things up better than a good example, thank you!
245 2014-07-09 15:32:16 <hearn> you can also change inputs if you sign with SIGHASH_ANYONECANPAY
246 2014-07-09 15:32:28 <hearn> yeah it's a bit abstract i'm afraid because we don't have any apps that use SIGHASH_SINGLE today
247 2014-07-09 15:32:56 <chichov> hearn: alright, I'll work through ANYONECANPAY now then
248 2014-07-09 15:33:02 <chichov> it should be clear now though
249 2014-07-09 16:07:21 <michagogo> It's annoying that you can only sign one single output and that it needs to have the same index
250 2014-07-09 16:07:58 <michagogo> So you can't sign more than one output and you can't have multiple inputs (e.g. multiple people) signing the same output
251 2014-07-09 16:29:33 <gmaxwell> (as observed by Jojatekok on #monero-dev)
252 2014-07-09 16:30:16 <gmaxwell> wumpus: open bitcoin-qt go to the send dialog type in 21000000 and press and hold the down button on the value field.
253 2014-07-09 16:30:19 <gmaxwell> :P
254 2014-07-09 16:33:13 <sipa> A programmer had a problem, and thought "I know, I'll use floating point!". Now he has 1.9999997 problems
255 2014-07-09 16:36:15 <wumpus> gmaxwell: ugh
256 2014-07-09 16:37:17 <wumpus> the qt spin widget uses floating point internally, I had fixed this in the pull to use locale-specific number formatting, but we eventually decided not to do that and it was forgotten
257 2014-07-09 16:37:48 <jtimon> hearn: not 100% sure but I think colored coins may be using sighash_single for trades
258 2014-07-09 16:42:39 <michagogo> That floating point thing happens in the other direction if you go down from 10000000
259 2014-07-09 16:43:14 <michagogo> 5000000 too
260 2014-07-09 16:43:20 <michagogo> 1000000 seems to be fine, though
261 2014-07-09 16:43:30 <michagogo> erm, no, nevermind
262 2014-07-09 16:43:40 <michagogo> at 1000000 it just takes longer to happen
263 2014-07-09 16:43:42 <wumpus> maybe it's better to just make it an input field, I don't see much point in having it a spin widget at all
264 2014-07-09 16:43:54 <michagogo> +1
265 2014-07-09 16:43:59 <gmaxwell> wumpus: I'd expect it to actually happen for any number >1 but perhaps it takes a long time to be visible.
266 2014-07-09 16:44:10 <wumpus> who enters an amount and then thinks 'oh, this should be some undefined quatity more!'
267 2014-07-09 16:44:15 <michagogo> Especially counting by mBTC
268 2014-07-09 16:44:36 <wumpus> gmaxwell: yeah, the error accumulates
269 2014-07-09 16:45:01 <michagogo> Wait, what's "Third party transaction URLs" in the Display section?
270 2014-07-09 16:45:51 <wumpus> michagogo: https://github.com/bitcoin/bitcoin/pull/4092
271 2014-07-09 16:46:01 <gmaxwell> I'd missed that we merged the double spend relaying stuff.
272 2014-07-09 16:46:20 <wumpus> gmaxwell: it was pretty suddenly merged
273 2014-07-09 16:46:24 <michagogo> Ah, that's cool
274 2014-07-09 16:46:34 <michagogo> What release did it get in on? 0.9?
275 2014-07-09 16:46:47 <wumpus> michagogo: I don't think it's in a release yet, not sure though
276 2014-07-09 16:46:52 <michagogo> It's in 0.9.2
277 2014-07-09 16:46:56 <wumpus> ok
278 2014-07-09 16:47:06 <michagogo> (that's what I'm running now and I noticed it)
279 2014-07-09 16:48:05 <michagogo> Ah, yeah, it's new in 0.9.2: https://github.com/bitcoin/bitcoin/commit/40c5b939f2bff960e397da6ae3651952adc68cbe
280 2014-07-09 16:48:26 <michagogo> GH's tag sorting is annoying
281 2014-07-09 19:46:05 <ninjashogun> hi bitcoin devs
282 2014-07-09 19:46:26 <ninjashogun> I was wondering what you plans were on blockchain pruning.  It's getting a bit long. . . (big)
283 2014-07-09 19:52:05 <RBecker> can't prune the chain
284 2014-07-09 19:52:09 <RBecker> it'd break the integrity
285 2014-07-09 19:52:22 <RBecker> every block is linked to the one before and the one after it
286 2014-07-09 19:56:20 <kazcw> not necessarily, I think a soft fork requiring utxoset merkle root commitments in coinbases is the leading proposal
287 2014-07-09 19:57:10 <helo> is the seat of our pants that reliable, though?
288 2014-07-09 20:03:18 <Luke-Jr> kazcw: that just makes less-secure (trusting) bitcoin nodes possible, it doesn't prune the blockchain
289 2014-07-09 20:07:54 <sipa> RBecker: there is a difference between not seeing all blocks and not storing all blocks
290 2014-07-09 20:08:05 <RBecker> this is true
291 2014-07-09 20:08:09 <sipa> it's today perfectly possible to not keep all blocks after they've been validated
292 2014-07-09 20:08:20 <jtimon> Luke-Jr I think his point is that eventually you will be able to just validate, say, the last 3 years of blocks and trust that people haven't been mining on top on an invalid committed utxo for 3 years...
293 2014-07-09 20:08:22 <Luke-Jr> sipa: perfectly? :P
294 2014-07-09 20:08:35 <Luke-Jr> jtimon: sure, but it's not quite the same thing
295 2014-07-09 20:08:35 <sipa> the only reason we don't is because there is no good way of advertizing to peers that we don't have all blocks, in case they need some
296 2014-07-09 20:08:53 <Luke-Jr> jtimon: actually nm, it is.. since even a few months is all the security we have right now :p
297 2014-07-09 20:09:11 <Luke-Jr> sipa: well, ideally none of your peers would have *all* the blocks :p
298 2014-07-09 20:09:37 <Luke-Jr> sipa: IMO, it's best if nodes just retain the "least common" blocks from their view. The problem is getting other peers to handle this cleanly when bootstrapping..
299 2014-07-09 20:23:38 <otila> would be neat if bitcoin compiled with -std=c++11
300 2014-07-09 20:23:39 <otila> chainparams.cpp:157:40: error: ambiguous overload for ‘operator=’ (operand types are ‘std::vector<unsigned char>’ and ‘boost::assign_detail::generic_list<int>’) base58Prefixes[PUBKEY_ADDRESS] = list_of(0);
301 2014-07-09 20:23:39 <otila> chainparams.cpp: In constructor ‘CMainParams::CMainParams()’:
302 2014-07-09 20:26:09 <sipa> otila: patches welcome
303 2014-07-09 20:29:34 <ttgg> can someone explain to me how files or irrelevant data can be stored in a block?
304 2014-07-09 20:29:51 <ttgg> I'm not too clear on how people are putting extra stuff into the blocks
305 2014-07-09 20:30:07 <ttgg> just a simplified explanation will do
306 2014-07-09 20:36:41 <gwillen> ttgg: there are places in transactions and blocks where you can supply whatever data you want. E.g. there's are a couple of fields in a block taht you are supposed to just increment as required while mining. But you can also stuff data into them.
307 2014-07-09 20:36:59 <helo> ttgg: adhoc encoding schemes
308 2014-07-09 20:38:34 <ttgg> Is there a limit to the padding you can stuff in there?
309 2014-07-09 20:43:06 <sipa> yes
310 2014-07-09 20:43:39 <sipa> blocks are at most 1MB, so by definition the amount of data inside is limited
311 2014-07-09 20:43:52 <sipa> as to specifics, that depends on what method you're using for stuffing data in it
312 2014-07-09 20:45:22 <ttgg> Thanks sipa, I think that's as much as I need :)
313 2014-07-09 21:52:49 <vagoum> greetings
314 2014-07-09 22:03:34 <vagoum> I have recently dived into the cryptocurrency/anonymity world and have been overly amazed
315 2014-07-09 22:04:53 <jcorgan> the rabbit hole never ends :)  but for general discussion of that, #bitcoin is better
316 2014-07-09 22:04:53 <vagoum> I 'd love to contibute to this upcoming crypto-world by writing software
317 2014-07-09 22:05:53 <vagoum> @jcorgan thanks for response :) I just headed here because I wanted some advice about how I can start writing crypto related software
318 2014-07-09 22:06:18 <jcorgan> certainly, studying the bitcoind source code is very useful, if you are familiar with C++
319 2014-07-09 22:06:29 <jcorgan> but it all depends on your experience
320 2014-07-09 22:06:55 <vagoum> well I am mostly an academic coder, not much experience with production code
321 2014-07-09 22:07:11 <vagoum> Currently studying electrical engineering and CS, first year
322 2014-07-09 22:07:13 <jcorgan> in many ways it is more important to understand the underlying crypto/security/economic concepts first
323 2014-07-09 22:07:40 <vagoum> I think I am making substantial progress in that one
324 2014-07-09 22:08:52 <jcorgan> well, there are dozens (hundreds?) of open source projects in the bitcoin space, that live on github.com, so you have and endless variety of stuff to read about
325 2014-07-09 22:09:38 <vagoum> yeap you're right
326 2014-07-09 22:10:03 <vagoum> I guess I should read the documentation and tinker with bitcoind first
327 2014-07-09 22:10:47 <jcorgan> have fun
328 2014-07-09 22:11:50 <jcorgan> just beware there is an enormous amount of misinformation about how bitcoin and related software works, so you'll also need to hone your bullshit detector as well as your programming skills
329 2014-07-09 22:13:15 <vagoum>  Very right at that one
330 2014-07-09 22:14:12 <vagoum> @jcorgan thanks anyway!
331 2014-07-09 22:15:17 <jcorgan> feel free to come back here or #bitcoin with questions, though this channel is more for coordinating actual bitcoin core development, not support or Q&A
332 2014-07-09 22:16:31 <vagoum> thanks for clarifying, adios!
333 2014-07-09 22:28:31 <WeCluster> developing under MinGW and built headless bitcoind successfully using openssl-1.0.1h and boost_1_50_0 but now must debug crash on execution, any suggestions? :: $ bitcoind  This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
334 2014-07-09 22:38:30 <WeCluster> built using the latest version of bitcoind :: $ bitcoind --version Bitcoin Core Daemon version v0.9.99.0-ge81e2e8
335 2014-07-09 22:41:11 <kazcw> WeCluster: try an older version, like v0.9.2.1. if that works you can find the breakage with git bisect
336 2014-07-09 22:41:38 <michagogo> Also try with newer boost maybe?
337 2014-07-09 22:41:50 <michagogo> I think we currently use 54 or 55
338 2014-07-09 22:42:48 <WeCluster> newer boost (55) wouldn't build, might try 54 and rollback to previous bitcoind source. thanks for the ideas.
339 2014-07-09 22:43:08 <jcorgan> sipa: is libsecp256k1 threadsafe?
340 2014-07-09 22:43:15 <kazcw> the docs currently say boost1.50.0 in build-msw, but idk if that's outdated
341 2014-07-09 22:43:15 <michagogo> WeCluster: well, 0.9.2.1 is latest release tag
342 2014-07-09 22:43:53 <michagogo> kazcw: to see what we use, check contrib/giti(tab)-desc(tab)
343 2014-07-09 22:44:10 <michagogo> If there's a boost windows yml, see that
344 2014-07-09 22:44:19 <michagogo> If not, check deps windows
345 2014-07-09 22:44:29 <michagogo> (Check as of v0.9.2.1)
346 2014-07-09 22:45:08 <michagogo> WeCluster: btw, mingw on windows or Linux?
347 2014-07-09 22:45:50 <michagogo> Release binaries are built on Linux with mingw
348 2014-07-09 22:45:59 <WeCluster> docs currently do say to use boost 50 ... haven't seen any reason for recent changes to bitcoind to be incompatible with boost 50, but the docs currently also say to use openssl 1.0.1c which is obviously wrong.
349 2014-07-09 22:46:10 <WeCluster> mingw on Windows 7
350 2014-07-09 22:46:23 <michagogo> WeCluster: I'm not familiar with that doc... Check when it was last updated in git
351 2014-07-09 22:46:41 <michagogo> But I suspect it's outdated
352 2014-07-09 22:57:36 <WeCluster> build-msw.md has the out-of-date version numbers for openssl and boost. build-unix.md doesn't contain version numbers in the dependency list except for Berkeley db
353 2014-07-09 22:58:51 <Luke-Jr> WeCluster: except for BDB, any version should work
354 2014-07-09 22:59:07 <Luke-Jr> heck, any BDB would work too, just they're not compatible
355 2014-07-09 23:16:26 <WeCluster> building 0.9.2.1 now ... to build under mingw on windows you must modify src/Makefile to add -D_WIN32_WINNT=0x0601 -DWINVER=0x0601 and also -lz in LIBS ... is this important enough for me to file a bug report and submit a patch to fix ?
356 2014-07-09 23:18:00 <WeCluster> this is my first time working on bitcoin so I don't know what the culture is here. do we hate Windows with appropriate zeal or are we trying to help everyone who wants to contribute code regardless of their platform?
357 2014-07-09 23:22:11 <kazcw> I think we have the usual situation where most of the users use windows and most of the developers prefer reasonable operating systems, so helping with windows-specific problems is especially helpful on both the supply and demand sides of things
358 2014-07-09 23:23:24 <WeCluster> one worries about helping with the supply of code from developers who use windows ...
359 2014-07-09 23:25:13 <WeCluster> a proof-of-work test for developer competency is already built-in to the strategically-incorrect build scripts and documentation for would-be windows developers. not sure it would be a good idea to "fix" that...
360 2014-07-09 23:30:06 <Fistful_of_coins> who are you
361 2014-07-09 23:39:49 <userguy243> hi