1 2014-03-22 00:00:32 <sipa> the orphan pool has stricter requirements though
  2 2014-03-22 00:00:44 <linagee> if I had to depend upon only one node feeding me the blockchain, could I still trust it? (after a few blocks, wouldn't it be insane to assume they're feeding me false data with all of the hash power required to forge data?)
  3 2014-03-22 00:00:46 <sipa> it only keeps small transactions and a limit number of them
  4 2014-03-22 00:01:02 <sipa> linagee: define 'false data' ?
  5 2014-03-22 00:01:12 <sipa> linagee: as a full node, you validate everything, so they can't send you an invalid chain
  6 2014-03-22 00:01:29 <sipa> linagee: you can of course be fed a side chain, or a chain with less work than the 'real' one
  7 2014-03-22 00:01:44 <sipa> which is a sybil attack
  8 2014-03-22 00:01:58 <linagee> sipa: don't wallets know what the difficulty is supposed to be?
  9 2014-03-22 00:02:03 <sipa> no, how could they?
 10 2014-03-22 00:02:33 <linagee> hrm. I guess if the aparent difficulty dropped off from the previous block? *shrug*
 11 2014-03-22 00:02:46 <maaku> linagee: you are assuming your current view of the chain is correct
 12 2014-03-22 00:02:55 <sipa> linagee: that's a validity rule
 13 2014-03-22 00:03:01 <midnightmagic> it looks like it's just a straight buffer and other tx are bumped out of it as new orphans fill it up; currently sized at a hard 10,000 tx.
 14 2014-03-22 00:03:02 <sipa> linagee: so yes, they can't send you an invalid chain
 15 2014-03-22 00:03:14 <sipa> linagee: but they can send you the *wrong* chain as long as it is valid
 16 2014-03-22 00:04:01 <linagee> sipa: I'm doing thought experiments about whether a one-way blockchain radio service is feasible. (whether using wifi with UDP packets, or something like it.)
 17 2014-03-22 00:04:10 <midnightmagic> orphan tx size max in my copy of the source ( d6e0e171ab2ca23be33b440d7c007d360de29c48 ) is 5000 bytes.
 18 2014-03-22 00:04:13 <sipa> linagee: sure
 19 2014-03-22 00:04:45 <linagee> sipa: if multiple independant people were saying the same thing, I guess it becomes more believable...
 20 2014-03-22 00:05:01 <sipa> linagee: that's not relevant really
 21 2014-03-22 00:05:07 <arubi> you would also need the same genesis block for everyone
 22 2014-03-22 00:05:08 <sipa> linagee: all you need is one person telling the truth
 23 2014-03-22 00:05:18 <arubi> before the sync starts
 24 2014-03-22 00:05:26 <linagee> arubi: this is assuming the people listening would already have bitcoind and a full blockchain.
 25 2014-03-22 00:05:42 <linagee> arubi: (and bitcoind already has those "anchor points" in code)
 26 2014-03-22 00:05:53 <arubi> well, I'm saying the genesis is what counts
 27 2014-03-22 00:05:57 <sipa> linagee: whether one or 1500 peers tell you the same thing doesn't make it more believable
 28 2014-03-22 00:06:08 <sipa> linagee: as if it is invalid, you will detect it
 29 2014-03-22 00:06:30 <sipa> linagee: and if there's a better chain, one peer telling you about it is enough, despite 1500 claiming otherwise
 30 2014-03-22 00:07:37 <linagee> sipa: so - what is the point for the average full node connecting to 8 peers then? just so it can repeat blocks?
 31 2014-03-22 00:08:13 <sipa> linagee: to be sure there's at least one honest one
 32 2014-03-22 00:08:31 <maaku> linagee: graph connectivity
 33 2014-03-22 00:08:46 <sipa> that too, but incoming connections are more important for that
 34 2014-03-22 00:09:06 <maaku> well, if everyone only made one connection...
 35 2014-03-22 00:09:27 <sipa> yeah, every incoming connection is an outogoing one elsewhere of course
 36 2014-03-22 00:36:05 <jgarzik> Summary of transaction outputs, past 2 years, version 4:
 37 2014-03-22 00:36:08 <jgarzik> http://0bin.net/paste/47w1-XaxWFHR-+a5#MQ7eaYMiNI3+VovT4snUoBj/0PUykcmptjc1MiR6PVg=
 38 2014-03-22 00:36:26 <jgarzik> justanotheruser, ^
 39 2014-03-22 00:37:15 <justanotheruser> Error
 40 2014-03-22 00:37:15 <justanotheruser> jgarzik: ?
 41 2014-03-22 00:37:16 <justanotheruser> Could not decrypt data (Wrong key ?)
 42 2014-03-22 00:38:27 <jgarzik> justanotheruser, very odd, works here.
 43 2014-03-22 00:38:49 <justanotheruser> oops, deleted the ending =
 44 2014-03-22 00:39:09 <justanotheruser> jgarzik: interesting. I expected more
 45 2014-03-22 00:42:19 <warren> Is pywallet not able to read everything from 0.9's wallet.dat yet?
 46 2014-03-22 00:42:58 <justanotheruser> I mean counterparty burned a few thousand bitcoins, I would expect more than 0.008 to be burned in the better way.
 47 2014-03-22 00:59:40 <lianj> jgarzik: http://webbtc.com/stats also Script Types
 48 2014-03-22 01:04:29 <arubi> ^^ blockchain size : 15.7GB ... more like 19gb :(
 49 2014-03-22 01:05:44 <lianj> arubi: not if you only take mainchain
 50 2014-03-22 01:06:35 <arubi> is there 3gb+ of garbage in the chain?
 51 2014-03-22 01:07:25 <lianj> on your disk, seems like it :D
 52 2014-03-22 01:07:31 <sipa> the block chain: 16G
 53 2014-03-22 01:07:40 <sipa> undo data: 2.1G
 54 2014-03-22 01:07:53 <sipa> chainstate 0.4G
 55 2014-03-22 01:08:21 <arubi> :) man I love this channel
 56 2014-03-22 01:19:20 <Guest3080_> Me too @arubi
 57 2014-03-22 01:21:08 <Guest3080_> Me too @arubi
 58 2014-03-22 01:48:31 <petertodd> Luke-Jr: you should clarify exactly what you disagree with with regard to my statement on coiledcoin
 59 2014-03-22 01:50:21 <jgarzik> lianj, nod.  I wanted to get (a) deeper information on multisig usage, and (b) a -recent- snapshot of numbers, not just numbers for all time
 60 2014-03-22 01:58:49 <Luke-Jr> petertodd: don't play dumb
 61 2014-03-22 01:59:02 <petertodd> Luke-Jr: no I'm quite serious.
 62 2014-03-22 02:07:10 <petertodd> Luke-Jr: in particular, what exactly are you saying you did here and how does that differ from my statement? https://bitcointalk.org/index.php?topic=56675.msg678006#msg678006
 63 2014-03-22 03:03:54 <jgarzik> CodeShark, what is CodeClasses license, specifically HD wallet stuff?  I'm looking to steal code for my MIT-licensed C library
 64 2014-03-22 03:04:09 <CodeShark> CodeClasses is MIT licensed
 65 2014-03-22 03:04:21 <CodeShark> err
 66 2014-03-22 03:04:25 <CodeShark> CoinClasses
 67 2014-03-22 03:04:37 <CodeShark> CoinQ and CoinDB are GPL
 68 2014-03-22 03:06:32 <CodeShark> jgarzik: if you could add secure buffer allocators to CoinClasses' hdkeys it would be great :)
 69 2014-03-22 03:06:43 <CodeShark> but yeah, feel free to use CoinClasses
 70 2014-03-22 03:09:25 <jgarzik> CodeShark, heh note I said "C"
 71 2014-03-22 03:09:39 <jgarzik> CodeShark, it will be heavily butchered
 72 2014-03-22 03:09:55 <jgarzik> CodeShark, https://github.com/jgarzik/picocoin/
 73 2014-03-22 03:11:17 <CodeShark> isn't C++ to C conversion mostly just explicitly expressing the first parameter to methods as an object pointer? :)
 74 2014-03-22 03:11:33 <jgarzik> CodeShark, heh
 75 2014-03-22 03:40:16 <jgarzik> JavaScript block scan: 23 minutes
 76 2014-03-22 03:40:21 <jgarzik> C block scan: < 2 minutes
 77 2014-03-22 03:41:26 <justanotheruser> jgarzik: why are you using javascript for that in the first place?
 78 2014-03-22 03:42:52 <jgarzik> justanotheruser, ease of coding
 79 2014-03-22 04:46:23 <Guest3080_> QUESTION: Hello guys! How can I gain status of maintainer or reviewer in https://www.transifex.com/organization/bitcoin/dashboard ? Thank you.
 80 2014-03-22 04:46:54 <felipelalli> Repeating the question with my real nick:
 81 2014-03-22 04:46:56 <felipelalli> QUESTION: Hello guys! How can I gain status of maintainer or reviewer in https://www.transifex.com/organization/bitcoin/dashboard ? Thank you.
 82 2014-03-22 04:47:28 <felipelalli> I'd like to configure the description, logo etc. of project Bitcoin inside Transifex
 83 2014-03-22 04:48:15 <felipelalli> Also I want to be able to make review in Portuguese BR. My Portuguese is perfect, I studied the grammar several years and I am native speaker.
 84 2014-03-22 04:55:22 <justanotheruser> Noob question: Why can't I find main in init.cpp?
 85 2014-03-22 05:04:17 <phantomcircuit> justanotheruser, because it's in main.cpp
 86 2014-03-22 05:04:35 <justanotheruser> phantomcircuit: ... "he main() entry point to the program is in init.cpp. Do not go looking in main.cpp for main() - you will not find it."
 87 2014-03-22 05:04:50 <justanotheruser> freaking bitcoin.it paywalls
 88 2014-03-22 05:09:15 <Luke-Jr> justanotheruser: do you want to edit?
 89 2014-03-22 05:09:57 <justanotheruser> Luke-Jr: no, just understand
 90 2014-03-22 05:10:06 <Luke-Jr> ?
 91 2014-03-22 05:10:14 <Luke-Jr> if it's wrong, please fix it :P
 92 2014-03-22 05:10:20 <Luke-Jr> SomeoneWeird: *summon*
 93 2014-03-22 05:10:35 <justanotheruser> Luke-Jr: Oh, I thought you were talking about the bitcoin source. Yes, if the wikis wrong I would like to edit it.
 94 2014-03-22 05:11:15 <justanotheruser> But I can't find main() in either init or main.
 95 2014-03-22 05:12:31 <Luke-Jr> src/qt/bitcoin.cpp src/bitcoind.cpp and src/bitcoin-cli.cpp
 96 2014-03-22 05:12:33 <Luke-Jr> have mains
 97 2014-03-22 05:12:53 <justanotheruser> Cool, thanks
 98 2014-03-22 05:14:37 <justanotheruser> Luke-Jr: Does bitcoin.it not require 0.001btc to edit anymore?
 99 2014-03-22 05:15:06 <justanotheruser> Or whatever it was, 0.01
100 2014-03-22 05:15:18 <Luke-Jr> justanotheruser: SomeoneWeird can bypass it for people
101 2014-03-22 07:50:02 <shripadk> hello all :)
102 2014-03-22 07:50:28 <shripadk> i'm having a hard time compiling bitcoin v0.9 on osx.
103 2014-03-22 07:51:07 <shripadk> the build completes but when I run bitcoind i get a "pointer being freed was not allocated" error
104 2014-03-22 08:13:24 <fanquake> shripak can you upload an error log somewhere?
105 2014-03-22 08:46:47 <quaz0r> /usr/lib64/libmemenv.a(memenv.o): relocation R_X86_64_32S against `.rodata' can not be
106 2014-03-22 08:46:49 <quaz0r> used when making a shared object; recompile with -fPIC
107 2014-03-22 08:46:51 <quaz0r> /usr/lib64/libmemenv.a: error adding symbols: Bad value
108 2014-03-22 08:47:01 <quaz0r> anybody else get this?
109 2014-03-22 08:47:47 <wumpus> my guess: you're trying to link a static library that is not compiled with -fPIC into a position independent executable
110 2014-03-22 08:48:22 <quaz0r> shrug
111 2014-03-22 08:48:35 <quaz0r> im just trying update stuff
112 2014-03-22 08:48:55 <wumpus> easiest would be to find a dynamic library version of libmemenv
113 2014-03-22 08:49:30 <wumpus> (or disable -pie to not build a position independent executable)
114 2014-03-22 08:49:33 <quaz0r> from what i gather googling it sounds like its from leveldb
115 2014-03-22 08:49:55 <wumpus> hmm
116 2014-03-22 08:50:12 <wumpus> try nuking everything in your build directory and starting from scratch
117 2014-03-22 08:50:21 <wumpus> maybe some old libmemenv.a is still around
118 2014-03-22 08:51:53 <aschildbach> Luke-Jr: do you plan to update http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html ?
119 2014-03-22 08:51:54 <wumpus> it's strange that it tries to use the library in /usr/lib64 though, it should use the embedded leveldb
120 2014-03-22 08:52:22 <wumpus> (which does get build with -fPIC if --enable-hardening)
121 2014-03-22 10:06:42 <XtR123> Hello i dont know why my wallet doesn`t download the block chain it stucks 10 days ago and it showing me 8 active connection to the network
122 2014-03-22 10:06:49 <XtR123> v0.9.0.0-g92d25e4-beta (64-bit)
123 2014-03-22 10:06:57 <XtR123> this is my version
124 2014-03-22 10:25:37 <olalonde> gmaxwell: is there a signature scheme for HD wallet extended keys?
125 2014-03-22 10:28:11 <olalonde> I guess I could just sign a message with the non extended private key and publish the extended public key?
126 2014-03-22 10:28:50 <cbeams_> I'm attempting to build v0.9.0 following the instructions at doc/build-osx.md. brew install, autogen, configure all complete error-free. make fails quickly with the following: https://gist.github.com/anonymous/9704573. Ideas?
127 2014-03-22 10:42:45 <cbeams> Is there a better forum in which to ask build-related questions? (as I just did, logged at http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/03/22#l1395484130)
128 2014-03-22 10:48:33 <fanquake> cbeams still here?
129 2014-03-22 10:48:41 <cbeams> yes.
130 2014-03-22 10:49:28 <fanquake> Ill tell you how to fix that. One sec.
131 2014-03-22 10:50:42 <fanquake> cbeams You should try installing boost from source.
132 2014-03-22 10:51:00 <cbeams> I installed with brew.
133 2014-03-22 10:51:01 <fanquake> Pretty certain I had the exact same problem, building from source seemed to fix it.
134 2014-03-22 10:51:09 <fanquake> No problem. Just do
135 2014-03-22 10:51:21 <fanquake> brew install boost --HEAD
136 2014-03-22 10:51:48 <cbeams> running now thanks.
137 2014-03-22 10:52:01 <cbeams> ftr, had to `brew unlink boost` prior.
138 2014-03-22 11:09:44 <ielo> where is genjix
139 2014-03-22 11:09:52 <ielo> whoops
140 2014-03-22 11:14:22 <gmaxwell> XtR123: as you've probably noticed by now, it probably continued again after the next block on the network.
141 2014-03-22 11:26:26 <halfcab123> Hello
142 2014-03-22 12:07:09 <cbeams> fanquake: /usr/local/Cellar/boost/HEAD: 10482 files, 444M, built in 29.5 minutes
143 2014-03-22 12:07:14 <cbeams> (building Boost from HEAD solved the problem, thanks.)
144 2014-03-22 12:07:28 <cbeams> Pull request at https://github.com/bitcoin/bitcoin/pull/3936
145 2014-03-22 13:05:09 <testicletoucher> is there a clear guide to how a json transaction gets converted into hex?
146 2014-03-22 13:08:16 <cbeams> testicletoucher (really?): not necessarily a precise answer to your question, but this document may help, if you're not already familiar: http://bitcoindev.us.to/en/developer-guide#transactions
147 2014-03-22 13:11:22 <ribasushi> there is this multicoin client fork of the main client back in 2011
148 2014-03-22 13:11:25 <ribasushi> seems to have died
149 2014-03-22 13:11:27 <ribasushi> why is this?
150 2014-03-22 13:11:27 <testicletoucher> oh it got updated from last time
151 2014-03-22 13:11:45 <ribasushi> is there no interest in multi-network daemons?
152 2014-03-22 13:13:29 <Akima> ribasushi: I'd prefer to have multiple daemons and a multi-daemon client
153 2014-03-22 13:13:55 <Akima> inline with UNIX philosophy: smalls tools that do one job very well
154 2014-03-22 13:14:57 <Akima> not big (bloated) tools that try to do many jobs well and through their large size and inherent complexity tend to work badly
155 2014-03-22 13:16:01 <ribasushi> well, by this logic having a UI + rpc + wallet + p2p node in one tool is exceedingly bloated as well :)
156 2014-03-22 13:16:26 <cbeams> ribasushi: I think most core devs these days would agree.
157 2014-03-22 13:17:04 <ribasushi> a wallet-less, UI-less node that can talk to multiple networks which vary only by small parameters + separate chain would be the "one thing and do it well" in my eye
158 2014-03-22 13:17:50 <ribasushi> basically I am wondering "am I missing something" given such a thing doesn't exist
159 2014-03-22 13:19:04 <cbeams> ribasushi: who would decide which alt networks are blessed to get into the daemon?
160 2014-03-22 13:19:39 <ribasushi> the author of said daemon :)
161 2014-03-22 13:20:03 <cbeams> disadvantageous to new alts, as there would be a natural tendency to be conservative as time goes on (assuming said daemon were to become well-adopted)
162 2014-03-22 13:20:15 <ribasushi> nor having a limit seems productive - even when porncoin comes around :)
163 2014-03-22 13:21:17 <ribasushi> but yes, keeping in mind not shutting out new alts is sane
164 2014-03-22 13:21:30 <ribasushi> 
ACTION will ponder, may be an interesting exercise from a tech. pov

165 2014-03-22 13:21:55 <ribasushi> "how hard can it be" >.>
166 2014-03-22 13:22:18 <gmaxwell> I don't think it is at all— interesting that is, or on topic. Seeing as how this is #bitcoin-dev and not #altcoin-dev. :)
167 2014-03-22 13:23:43 <gmaxwell> I'm glad that people are expirementing with other things, but trying to cram them all in one place is precisely the opposite of the freedom and autonomy that expirementation with different things is useful for. Doubly so because the integration would likely only be maintainable where the differences were utterly trivial— and thus maximally uninteresting.
168 2014-03-22 13:24:32 <ribasushi> gmaxwell: aren't differences between all current altcoins (aside from ripple) precisely this - utterly trivial?
169 2014-03-22 13:24:39 <ribasushi> (not trolling, honest question)
170 2014-03-22 13:24:55 <gmaxwell> For the most part. (There are a few other things which aren't quite utterly trivial)
171 2014-03-22 13:25:29 <ribasushi> gmaxwell: can you get me some insights? (pm is fine if you don't want to stray off topic too much)
172 2014-03-22 13:26:01 <wumpus> ribasushi: "well, by this logic having a UI + rpc + wallet + p2p node in one tool is exceedingly bloated as well" <- and it is, there are serious plans to split off the wallet to a seperate project
173 2014-03-22 13:26:13 <ribasushi> wumpus: good to hear
174 2014-03-22 13:26:54 <gmaxwell> ribasushi: some other time, I'm tied up right now.
175 2014-03-22 13:27:22 <ribasushi> gmaxwell: np, cheers
176 2014-03-22 13:27:29 <wumpus> ribasushi: you can already build with --disable-wallet in 0.9
177 2014-03-22 13:27:32 <cbeams> ribasushi, the argument here is that difficulty is beside the point. Such a design would be undesirable in any case. Akima's point that it violates the unix way is exactly right, and the practical management of such an approach would be non-ideal to say the least. Core devs would deal with many pull requests for coins they don't care about, etc.
178 2014-03-22 13:28:29 <cbeams> It may be interesting as an exercise for your own edification, but wouldn't be a suitable direction for bitcoind itself.
179 2014-03-22 13:28:35 <wumpus> +1 cbeams
180 2014-03-22 13:30:37 <wumpus> cbeams: btw re github: why do you think upgrading boost is necessary? are there really things that the current/older boost version cannot do that we need?
181 2014-03-22 13:31:23 <cbeams> wumpus, I don't have an opinion as to whether it's necessary. Rather, that commit reflects that fact that it is already necessary. I could not compile without the change there, as described in the commit comment.
182 2014-03-22 13:31:36 <wumpus> cbeams: requiring head is really undesirable
183 2014-03-22 13:31:46 <cbeams> agreed, as mentioned in the commit.
184 2014-03-22 13:31:47 <wumpus> cbeams: I'd suggest trying to find another workaround to build with older boost, then
185 2014-03-22 13:32:11 <wumpus> it could be as simple as a missing include file, or including some #ifdef magic incantation :p
186 2014-03-22 13:36:41 <cbeams>  not sure what else can be done to remedy this. It seems that someone committed the changes that cause these errors whist working against that newer rev of Boost. I could do some git bisecting to see exactly when the breakage was introduced, I suppose.
187 2014-03-22 13:36:41 <cbeams> wumpus, that sounds quite reasonable, but are we clear that the build is already broken on OS X? That pull request simply reflects what was necessary for me to make `make` work. It could be that I have a misconfigured system, but given that I simply followed the original instructions to `brew install boost` (which gets you 1.55.0) and this resulted in compilation errors that are fixed by an upgrade to boost@HEAD, I'm
188 2014-03-22 13:37:17 <wumpus> cbeams: builds break sometimes, that's a matter of fact, and I don't disagree on that
189 2014-03-22 13:37:30 <wumpus> cbeams: but in this case I'd advocate for solving the issue, instead of documenting around it :)
190 2014-03-22 13:38:03 <omp> suppose there are two transactions, #1 and #2, in the same block, and transaction #2 references transaction #1 as an input. is it required that #2 comes after #1 in the list of transactions?
191 2014-03-22 13:38:05 <cbeams> wumpus: thanks. Let's see what git bisect tells us.
192 2014-03-22 13:38:16 <wumpus> in any case in linux or windows there are no problems with building current master
193 2014-03-22 13:38:19 <wumpus> not even with ancient boost
194 2014-03-22 13:38:30 <wumpus> I cannot test on macosx
195 2014-03-22 13:39:20 <wumpus> omp: AFAIK yes, transactions are processed in the order that they are in a block
196 2014-03-22 13:39:35 <cbeams> wumpus: very good to know. Tells us this is very likely indeed a mis- (or at least differently-) configured system problem, as opposed to a real breakage at the code level. Thanks.
197 2014-03-22 13:39:40 <omp> wumpus: cool, thanks
198 2014-03-22 13:42:23 <jcorgan> cbeams: i'm not a macosx person, but ISTR that boost 1.5.4 on mac specifically had an issue itself that caused problems for a variety of projects.  this came up in gnuradio, for example, and required 1.5.5
199 2014-03-22 13:43:01 <cbeams> jcorgan, I was experiencing this build failure against 1.5.5, so sounds unrelated, but thanks.
200 2014-03-22 13:44:00 <jcorgan> i'll see if i can dig up any more details
201 2014-03-22 13:45:21 <jcorgan> i don't know if this is at all related: http://lists.gnu.org/archive/html/discuss-gnuradio/2014-03/msg00266.html
202 2014-03-22 13:50:40 <dexX7> i assume it's known that the op_0 at the beginning of a multisig scriptsig can be replaced with something else?
203 2014-03-22 13:51:39 <ribasushi> cbeams: oh absolutely, I was more musing on the unavailability of alternative daemons
204 2014-03-22 13:51:56 <ribasushi> especially given that the current implementation is... problematic to bootstrap
205 2014-03-22 14:54:19 <halfcab123> hello world
206 2014-03-22 14:57:16 <cbeams> for those interested in the Boost-related compilation issue, see https://github.com/bitcoin/bitcoin/pull/3936#issuecomment-38353579 which explains its resolution and why building from source is no longer necessary as of about 9 hours ago.
207 2014-03-22 14:58:25 <halfcab123> +1
208 2014-03-22 16:07:11 <halfcab123> So what do you guys think about Counterparty ?
209 2014-03-22 16:07:30 <maaku> dexX7: yes
210 2014-03-22 16:07:54 <maaku> checkmultisig pops one too many items off the stack
211 2014-03-22 16:11:40 <maaku> halfcab123: off-topic
212 2014-03-22 16:18:50 <ahmed__> hi all
213 2014-03-22 16:19:06 <ahmed__> does anyone here know how i can do multi sig escrow transactions in python?
214 2014-03-22 16:19:07 <halfcab123> hi ho
215 2014-03-22 16:19:31 <maaku> ahmed__: what does python have to do with it?
216 2014-03-22 16:22:59 <ahmed__> maaku: my app is in python so thats what ill be using to communicate with bitcoind
217 2014-03-22 16:23:17 <ahmed__> (well it doesnt have much if any to do with it but u get what i mean :P)
218 2014-03-22 16:25:11 <jgarzik> maaku, kind of...
219 2014-03-22 16:25:59 <jgarzik> maaku, Presuming that halfcab123 is the same as on https://bitcointalk.org/index.php?topic=395761.0 then it is relevant to the discussion of OP_RETURN behavior in bitcoind
220 2014-03-22 16:26:12 <jgarzik> maaku, though I agree that a general Counterparty opinion is off-topic
221 2014-03-22 16:26:51 <maaku> ahmed__: use python-bitcoin{,lib} 's rpc capabilities to talk with bitcoind
222 2014-03-22 16:27:48 <ahmed__> this one?https://github.com/jgarzik/python-bitcoinrpc
223 2014-03-22 16:30:56 <ahmed__> maaku: ^
224 2014-03-22 16:31:12 <jgarzik> yes
225 2014-03-22 16:31:40 <jgarzik> ahmed__, https://github.com/petertodd/python-bitcoinlib also has an rpc module
226 2014-03-22 16:31:59 <jgarzik> basically the same code, but if you are going to be doing other bitcoin things, you want the bigger lib
227 2014-03-22 16:32:44 <ahmed__> mhmm what confuses me is how to actually go about create the multi sig transactions
228 2014-03-22 16:34:17 <maaku> ahmed__: you construction a version 5 (starts with 3) address
229 2014-03-22 16:36:56 <jgarzik> ahmed__, to send to a multisig address, you (a) collect the public keys together and sort them, (b) make a multisig address, and (c) send funds to that address.
230 2014-03-22 16:37:15 <jgarzik> ahmed__, to spend the funds, you collect signatures from everyone involved in the transaction
231 2014-03-22 16:49:51 <jgarzik> On chain scanning and multisig
232 2014-03-22 16:50:36 <jgarzik> found a few corrupted (or invalid) CHECKMULTISIG scripts in the chain
233 2014-03-22 16:51:02 <jgarzik> not a big deal, just fun to dig through them for curiosity's sake
234 2014-03-22 17:20:37 <Imbue> hmm
235 2014-03-22 17:20:51 <Imbue> found an oddity in createrawtransaction; not sure if intended
236 2014-03-22 17:21:22 <Imbue> i don't have it open to check right now, will do it when i have time
237 2014-03-22 17:21:24 <Imbue> however;
238 2014-03-22 17:21:33 <Imbue> sending amount 0 to address errors out
239 2014-03-22 17:21:51 <Imbue> sending amount 0.0000(lots of zeroes)1 works and results in actually having a dummy output
240 2014-03-22 17:21:53 <Imbue> is this intended?
241 2014-03-22 17:22:53 <petertodd> ahmed__: here's an example https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2sh-txout.py
242 2014-03-22 17:24:32 <maaku> Imbue: can you post the actual error?
243 2014-03-22 17:24:53 <Imbue> maaku: yes; i will do so when i get up and running
244 2014-03-22 17:24:54 <petertodd> jgarzik: speaking of: https://github.com/bitcoin/bitcoin/pull/3860
245 2014-03-22 17:25:06 <maaku> nevermind
246 2014-03-22 17:25:33 <maaku> the "problem" (philosophical point on if it is) is in AmountFromValue in rpcserver.cpp
247 2014-03-22 17:26:08 <maaku> it rejects amounts <= 0.0
248 2014-03-22 17:27:31 <jgarzik> petertodd, useful
249 2014-03-22 17:28:22 <Imbue> maaku: yes. verified it just now. Invalid amount (code -3) for 0, but 0.0000 0000 1 (i.e. sub satoshi) produces a rawtx with amt = 0
250 2014-03-22 17:28:49 <Imbue> whether this is actually a problem i don't know; i don't know the reasoning behind blocking amt=0
251 2014-03-22 17:30:41 <jgarzik> sipa, RE libsecp256k1, (a) is there a doc or Makefile.am snip or something that serves as a guide for the -minimum- source code files I would need to import into my project, to use it?  i.e. excise tests, benching, alt implementations
252 2014-03-22 17:31:45 <jgarzik> (b) is it a complete replacement for OpenSSL EC* ?  or IOW, can libsecp256k1 + EC-stripped openssl yield a working bitcoind?
253 2014-03-22 17:32:18 <jgarzik> The #1 picocoin request has always been "zero dependencies"
254 2014-03-22 18:02:50 <halfcab123> Hey @jgarzik do you have a spare moment ?
255 2014-03-22 18:03:53 <halfcab123> Does anyone know, why even still on 0.9.0, it takes so long to importprivkey from console ?
256 2014-03-22 18:04:03 <halfcab123> < --- noob here btw
257 2014-03-22 18:04:37 <jgarzik> halfcab123, happy to answer on #bitcoin
258 2014-03-22 18:08:37 <Imbue> hm
259 2014-03-22 18:08:53 <Imbue> if a cpp wizard has one second to answer a question for me, that would be appreciated.
260 2014-03-22 18:09:22 <Imbue> in core.cpp , CTxOutCompressor::DecompressAmount , at the end of the function 10**e is achieved using repeated multiplication rather than exponentiation
261 2014-03-22 18:09:46 <Imbue> why is this? clarity, or cpp doesn't have exponentiation? sorry for the potentially stupid question...
262 2014-03-22 18:11:19 <maaku> Imbue: C++ doesn't have exponentiation
263 2014-03-22 18:11:30 <maaku> Imbue: well, what's the reasoning for allowing 0-valued outputs?
264 2014-03-22 18:11:32 <Imbue> hehe. thought it would be the simple answer. thanks maaku
265 2014-03-22 18:11:58 <Imbue> maaku: you are of course right
266 2014-03-22 18:12:09 <Imbue> waste of space etc
267 2014-03-22 18:12:46 <maaku> it's not a waste of space if it has a use. but what is the use?
268 2014-03-22 18:12:48 <Imbue> it seemed to me that it could have been an 'intentional mistake' in order to allow you to create zero output without crafting the rawtx from hex.
269 2014-03-22 18:13:42 <Imbue> i can't think of one
270 2014-03-22 18:14:18 <kadoban> well, it has exponentiation (std::pow), but presumably there was a reason not to use that.  iirc it converts to floating point, which might have a lot to do with it
271 2014-03-22 18:14:46 <Imbue> kadoban: probably performance :)
272 2014-03-22 18:15:06 <Imbue> i.e. best performing solution that doesn't add in FP error... amount is pretty crucial :P
273 2014-03-22 18:16:06 <kadoban> yeah, avoiding floating point when you can is a good way to avoid some really obscure 'fun'
274 2014-03-22 18:19:18 <Imbue> was disconnected. kabodan: indeed :p
275 2014-03-22 18:22:31 <maaku> Imbue: floationg-point exponentiation is both imprecise and non-deterministically so
276 2014-03-22 18:22:49 <Imbue> maaku: yeah; i am aware of this
277 2014-03-22 18:24:12 <sipa> jgarzik: i have a bitvoin branch that uses libsecp256k1 and works on ec-stripped openssl
278 2014-03-22 18:24:44 <sipa> jgarzik: you need pretty much all src/*.h fikes + secp256k1.cpp
279 2014-03-22 18:26:11 <sipa> eh, .c
280 2014-03-22 18:26:15 <sipa> current
281 2014-03-22 18:32:27 <tiago> 779 strings and a few hours later... the PT_pt translation is now massively improved
282 2014-03-22 18:33:39 <jgarzik> sipa, I'm thinking in the context of picocoin (C, not C++) FWIW
283 2014-03-22 18:33:45 <tiago> was really needing it, too. horrible mistakes like translating "change" with the wrong meaning ("to change", instead of the remaining coins)
284 2014-03-22 18:34:06 <jgarzik> sipa, sounds straightforward
285 2014-03-22 18:44:15 <andytoshi> maaku: thx for responding to troy on the list, that comment of his got under my skin
286 2014-03-22 19:00:48 <ahmed__> jgarzik: finally back
287 2014-03-22 19:01:09 <ahmed__> i think i understand that now. could u give me an idea of what bitcoinrpc calls are required to do such a thing?
288 2014-03-22 19:02:29 <gmaxwell> jgarzik: libsecp256k1 does have a GMP dependency currently, however.
289 2014-03-22 19:04:32 <ahmed__> if someone is willing to help out in making a multi sig transaction in a while id be glad to document it thoroughly since documentation on multi sig address generation and transactions seems to be scarce
290 2014-03-22 19:05:19 <gmaxwell> ahmed__: http://people.xiph.org/~greg/escrowexample.txt
291 2014-03-22 19:08:20 <olalonde> hola chikitas
292 2014-03-22 19:44:03 <Luke-Jr> aschildbach: yeah, sorry, 1 sec
293 2014-03-22 19:54:56 <Luke-Jr> aschildbach: done
294 2014-03-22 20:04:46 <ahmed__> thanks gmaxwell :)
295 2014-03-22 20:59:55 <deego> Just asking once more, just to confirm. i'm on bitcoin 0.8.4 which apparently uses blocks/ ... Is it therefore safe to delete blk*.dat in ~/.bitcoin ?
296 2014-03-22 21:00:32 <gmaxwell> deego: sure. though if you upgraded the blk0* stuff ended up hardlinked so the savings may be less than you were expecting.
297 2014-03-22 21:01:34 <Luke-Jr> deego: upgrade to at least 0.8.7 :p
298 2014-03-22 21:01:48 <Luke-Jr> 0.8.6*
299 2014-03-22 21:02:22 <deego> Luke-Jr: ah, ok.
300 2014-03-22 21:03:00 <deego> gmaxwell: Ah, interesting. my blk*.dat in ~/.bitcoin are 2GB each. Nothing else in subdirectories is that large. everything in blocks/ is around 2M or so
301 2014-03-22 21:03:14 <deego> err, 128M
302 2014-03-22 21:05:12 <aschildbach> Luke-Jr: thanks
303 2014-03-22 21:40:35 <Ghaleon_> BlueMatt .... any eta on 0.9.0 PAA ?
304 2014-03-22 21:42:14 <BlueMatt> yes...soon
305 2014-03-22 21:42:40 <Ghaleon_> ....ok.... thank you for putting in the effort brother
306 2014-03-22 21:43:04 <Ghaleon_> we appreciate it, thankless job I know. if I find a wallet with 200k bit coins I will send u 10k at least
307 2014-03-22 21:45:06 <Rawdawg-> a big thanks to the guys in here that helped me with my wallet the other day! You can see the finished product at www.dgcpoker.net
308 2014-03-22 21:45:11 <Rawdawg-> thanks guys!
309 2014-03-22 21:45:34 <Ghaleon_> u setup your own bitcond server rawdawg?
310 2014-03-22 21:46:33 <Rawdawg-> it was digitalcoind, but not quite Ghaleon_, the guys in here helped me get it working so i could host the wallet on a different server but still use rpc commands between the 2
311 2014-03-22 21:46:52 <Rawdawg-> we got it nice and secure so noone can steal any coins :P
312 2014-03-22 21:47:21 <Rawdawg-> so like i said, thanks very much guys!
313 2014-03-22 21:47:57 <Ghaleon_> hmm
314 2014-03-22 21:48:07 <Ghaleon_> i'd be interested in some security tips
315 2014-03-22 21:48:18 <Ghaleon_> locking down my unbent bitcoind right now. u on 0.9.0 ?
316 2014-03-22 21:48:42 <Rawdawg-> no i actualy use the java one for bitcoin
317 2014-03-22 21:48:51 <Rawdawg-> the server we setup was for digitalcoin
318 2014-03-22 21:48:55 <Rawdawg-> i think its v1.1
319 2014-03-22 21:49:15 <Ghaleon_> bitcoin J ?
320 2014-03-22 21:49:38 <Rawdawg-> yea, ill find a link for you
321 2014-03-22 21:49:40 <Rawdawg-> just a sec
322 2014-03-22 21:50:11 <Rawdawg-> https://code.google.com/p/bitcoinj/
323 2014-03-22 21:50:25 <Rawdawg-> there, its client only, but i dont offer any services for bitcoin at the moment
324 2014-03-22 21:50:34 <Rawdawg-> so i havent needed to setup a bitcoind yet
325 2014-03-22 21:50:53 <Rawdawg-> but soon i will i think
326 2014-03-22 21:51:27 <Rawdawg-> I am thinking about taking payments for chips on www.dgcpoker.net in bitcoins then when they cash out they get digitalcoins
327 2014-03-22 21:52:06 <Rawdawg-> idk how exactly to do it, i would probably have to do kinda what coinpayments used to do and freeze the price for 15 min or so and charge a small fee
328 2014-03-22 21:52:28 <LarsLarsen> yes,  and if they back out they loose the deposit
329 2014-03-22 21:52:43 <Rawdawg-> basicly yea
330 2014-03-22 21:52:51 <Rawdawg-> the price you mean right?
331 2014-03-22 21:53:00 <LarsLarsen> its pretty straightforward,  you just have to have long lock times
332 2014-03-22 21:53:40 <Rawdawg-> yea, probably 15 min? is that enough?
333 2014-03-22 21:53:50 <Rawdawg-> or 30 would be better possiblt
334 2014-03-22 21:53:53 <Rawdawg-> possibly*
335 2014-03-22 21:53:54 <LarsLarsen> consider how many block confirmations you want
336 2014-03-22 21:54:00 <Rawdawg-> probably 3
337 2014-03-22 21:54:01 <LarsLarsen> and multiply that by 10 minutes
338 2014-03-22 21:54:03 <LarsLarsen> 30
339 2014-03-22 21:54:06 <Rawdawg-> seems decently safe
340 2014-03-22 21:54:16 <LarsLarsen> yes,  you wont lose much money :)
341 2014-03-22 21:54:23 <Rawdawg-> oh and btw we are having a free tournament tonight guys
342 2014-03-22 21:54:24 <LarsLarsen> 2 is probably the lowest you can go
343 2014-03-22 21:54:31 <LarsLarsen> but 3 sounds safe
344 2014-03-22 21:54:31 <Rawdawg-> 50,000 chips in prizes
345 2014-03-22 21:54:36 <LarsLarsen> ish
346 2014-03-22 21:54:44 <Rawdawg-> yea, 3 would be safer than just 1 or 2
347 2014-03-22 21:54:47 <michagogo> cloud|Heh, did Gavin actually do the thing me mentioned he might, creating lots of bogus keys?
348 2014-03-22 21:54:58 <Rawdawg-> ive seen people get burned with just 1
349 2014-03-22 21:55:07 <LarsLarsen> 1 isnt acceptable at all,  blocks get orphaned all the time
350 2014-03-22 21:55:12 <LarsLarsen> I think 3 would be super rare
351 2014-03-22 21:55:17 <Rawdawg-> yea
352 2014-03-22 21:55:26 <Rawdawg-> i dont think ive seen 3 orphaned in a row
353 2014-03-22 21:56:18 <michagogo> cloud|I count about 50 Gavins on pgp.mit.edu... o_O
354 2014-03-22 21:56:30 <Rawdawg-> lol
355 2014-03-22 21:56:34 <LarsLarsen> it could go up to 6 with a huge attacker,  but you should worry about random orphans
356 2014-03-22 21:56:53 <LarsLarsen> I'd go way farther with sketchy altchains if you're doing that though
357 2014-03-22 21:57:00 <Rawdawg-> yea random ones are more likely than someone attacking it
358 2014-03-22 21:57:13 <michagogo> cloud|Um, why did he use all the bogus keys to sign his real key? o_O
359 2014-03-22 21:57:20 <Rawdawg-> the only altcoin i trust at this point is DGC
360 2014-03-22 21:57:27 <Rawdawg-> never been successfully forked
361 2014-03-22 21:57:46 <Rawdawg-> thats why i started the www.dgcpoker.net site, i think the coin could be pretty decent
362 2014-03-22 21:57:53 <LarsLarsen> they just hard forked the code I heard
363 2014-03-22 21:58:05 <Rawdawg-> yea, just for updates
364 2014-03-22 21:58:11 <toffoo> hi, I just encrypted a bitcoin-qt wallet that has been unencrypted for a long time .. at the very end of the process a message popped up that warned something like "any existing backups of old unencrypted wallets will no longer work".  can someone explain to me exactly how this is the case?
365 2014-03-22 21:58:17 <LarsLarsen> a big update!  changing payout!  thats immutable!
366 2014-03-22 21:58:19 <Rawdawg-> they did a hard fork couple months back to fix the multipools problem
367 2014-03-22 21:58:21 <michagogo> cloud|toffoo: The keypool is cleared
368 2014-03-22 21:58:42 <LarsLarsen> I understand
369 2014-03-22 21:58:45 <michagogo> cloud|So any keys generated from the moment you encrypt won't be in older backups
370 2014-03-22 21:59:07 <Rawdawg-> digitalcoins are cheap right now too, 0.04$ atm
371 2014-03-22 21:59:15 <michagogo> cloud|;;later tell gavinandresen* Hey, did you actually do what you mentioned you might and make ~100 bogus keys with your name? Also, I'm surprised to see that those keys all signed your real one.
372 2014-03-22 21:59:16 <gribble> The operation succeeded.
373 2014-03-22 21:59:21 <toffoo> michagogo|cloud but wouldn't old unencrypted wallets still have the valid private keys for the old used addresses?
374 2014-03-22 21:59:24 <Rawdawg-> so imo buying a couple thousand woth couldnt hurt
375 2014-03-22 21:59:48 <michagogo> cloud|toffoo: Yes, but when you next generate a key, that key won't be in the old backup
376 2014-03-22 21:59:57 <LarsLarsen> rawdawg-: look at https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
377 2014-03-22 22:00:01 <toffoo> ok that makes sense, thanks
378 2014-03-22 22:00:23 <LarsLarsen> rawdawg: the algorithm,  with timeouts,  is all there
379 2014-03-22 22:01:34 <Rawdawg-> thanks LarsLarsen
380 2014-03-22 22:02:08 <Rawdawg-> if you want to come play poker with us tonight let me know LarsLarsen, once the tourney is all done ill give you 1000 chips for free :P
381 2014-03-22 22:02:33 <LarsLarsen> rawdawg-: you have a centralized server of funds,  so you dont really need this.... but it will help your thinking
382 2014-03-22 22:02:54 <Rawdawg-> yea it will for sure, and any new thing i can learn makes me happier
383 2014-03-22 22:03:06 <LarsLarsen> rawdawg-: I appreciate the offer,  but I'm terrible at poker :)
384 2014-03-22 22:03:24 <Rawdawg-> haha, well worst case scenario you meet some new ppl :P
385 2014-03-22 22:03:32 <Rawdawg-> and get some free DGC :P
386 2014-03-22 22:03:57 <LarsLarsen> lol,  dont shill here,  take it to #bitcoin :P
387 2014-03-22 22:04:15 <Rawdawg-> haha
388 2014-03-22 22:04:28 <Rawdawg-> but thank you very much for the help!
389 2014-03-22 22:04:32 <Rawdawg-> its much appreciated
390 2014-03-22 22:04:45 <LarsLarsen> please always come ask for help with things that involve security,  you shouldnt do it yourself
391 2014-03-22 22:05:10 <Rawdawg-> i agree completely, money is one thing you shouldnt do trial and error on
392 2014-03-22 22:05:23 <LarsLarsen> esp other peoples money
393 2014-03-22 22:05:30 <LarsLarsen> they get touchy about that
394 2014-03-22 22:05:31 <Rawdawg-> exactly
395 2014-03-22 22:05:54 <LarsLarsen> luckily,  that algo seems solid and you should be fine
396 2014-03-22 22:05:54 <Rawdawg-> and i am an ex stock broker lol, so i know about the value of securing peoples money
397 2014-03-22 22:06:11 <LarsLarsen> lol yeah,  or flagrantly risking it :)
398 2014-03-22 22:06:29 <Rawdawg-> exactly haha
399 2014-03-22 22:06:40 <Rawdawg-> luckily i had nothing to do with the subprime market
400 2014-03-22 22:06:46 <LarsLarsen> I believe you
401 2014-03-22 22:07:10 <Rawdawg-> almost worse tho lol, i was involved with penny stocks
402 2014-03-22 22:07:36 <Rawdawg-> but not for the retail market, i only traded for high risk guys that knew the risk they were taking