1 2014-04-04 00:06:35 <SoftwareMechanic> Everyone is hiring devs
  2 2014-04-04 00:17:13 <BCB> axilla, what languages
  3 2014-04-04 00:27:18 <axilla> HTML5/CSS3/Javascript/Rails/PHP/Bash/Can Probably Learn anything with enough time but have no desire to learn Java or C++
  4 2014-04-04 00:27:23 <axilla> do have some python exp.
  5 2014-04-04 00:30:44 <dexx> do you have a portfolio to show some webdesign stuff?
  6 2014-04-04 00:31:56 <axilla> sure
  7 2014-04-04 00:32:01 <netg_> y
  8 2014-04-04 00:32:07 <axilla> robogrowth-com.herokuapp.com
  9 2014-04-04 00:32:15 <netg_> would you considering coding 4 euqity#
 10 2014-04-04 00:32:16 <axilla> http://ec2-54-84-14-33.compute-1.amazonaws.com/
 11 2014-04-04 00:32:26 <netg_> in real solid/potential projects
 12 2014-04-04 00:32:33 <axilla> http://netcamps.herokuapp.com/
 13 2014-04-04 00:32:43 <axilla> some freelance stuff i've done
 14 2014-04-04 00:32:45 <axilla> for various companies
 15 2014-04-04 00:32:55 <axilla> www.github.com/fluffheadsr
 16 2014-04-04 00:33:06 <axilla> php/opensource projects i've contributed to.
 17 2014-04-04 00:33:22 <axilla> depends netg_
 18 2014-04-04 00:33:27 <netg_> ok
 19 2014-04-04 00:33:50 <axilla> if i like the idea, and the horizon of getting paid isnt to far away
 20 2014-04-04 00:33:57 <netg_> yeah
 21 2014-04-04 00:33:59 <axilla> i could probably contribute some code.
 22 2014-04-04 00:34:12 <netg_> its the same answer all devs give :)
 23 2014-04-04 00:34:37 <netg_> ok, i put you on my watchlist
 24 2014-04-04 00:34:44 <netg_> on person to com
 25 2014-04-04 00:35:00 <netg_> on person to contact wgebn codingis neede
 26 2014-04-04 00:35:02 <axilla> well, most non-dev's come to you with this line, "Hey i got this website i need made, shouldn't take anymore than 3-4hrs. Very Easy, just need this this this this and this."
 27 2014-04-04 00:35:13 <axilla> Oh yea you know how many hours it should take?  You're a developer then eh?
 28 2014-04-04 00:35:18 <netg_> yeah
 29 2014-04-04 00:35:36 <netg_> no, no, doing full time coin proejcts
 30 2014-04-04 00:35:42 <axilla> would love to
 31 2014-04-04 00:35:47 <netg_> but now i want to launch
 32 2014-04-04 00:35:51 <axilla> i've been doing things i don't like for to long
 33 2014-04-04 00:35:59 <netg_> like 10 big sites/projects
 34 2014-04-04 00:36:03 <Luke-Jr> guys, this isn't really bitcoin-related.. maybe take it to PM?
 35 2014-04-04 00:36:10 <netg_> sorry man
 36 2014-04-04 00:36:16 <netg_> sorry luke
 37 2014-04-04 00:36:22 <Luke-Jr> np
 38 2014-04-04 00:36:33 <axilla> yea np
 39 2014-04-04 00:36:48 <axilla> gonna go watch a movie with the wife and appreciate life :)
 40 2014-04-04 00:37:44 <Luke-Jr> axilla: you might try #bitcoin-otc also btw
 41 2014-04-04 00:38:10 <axilla> thx :)
 42 2014-04-04 00:38:52 <axilla> i have a odesk profile with nearly a 5* review record.
 43 2014-04-04 00:39:05 <axilla> anyway later
 44 2014-04-04 00:54:48 <tg2> quick q, if I wanted to have a stratum relay wherein miners connect to the relay server with a login/pass and then the relay connects to a downstream stratum server with a single account, is this possible?
 45 2014-04-04 00:55:59 <tg2> used bithopper before but it doesn't scale well
 46 2014-04-04 01:07:37 <olalonde> hola
 47 2014-04-04 01:36:43 <warren> https://en.bitcoin.it/wiki/Transaction_fees#Sending  is the "all outputs" point still true in 0.9?
 48 2014-04-04 03:06:38 <fuegofuego2> hey does anybody know how to turn this data on a logfile? printscreen: http://i62.tinypic.com/ae31xd.jpg I tryed out taking the source directly from the API provider without luck https://www.bitstamp.net/websocket/
 49 2014-04-04 03:16:01 <coinboywv> Hi all, I'm working on understanding the JSON calls to Bitcoin-QT and I can't quite get anything to connect up to my server. I can go to the address via http://<IP ADDRESS>:<PORT> and it comes back with, "{"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}" Where do I go from here to start passing along commands to the server easily?
 50 2014-04-04 03:21:48 <lachesis> "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."
 51 2014-04-04 03:22:44 <lachesis> i'm on v 90000, and block height is 293768 for some reason
 52 2014-04-04 03:23:06 <deego> lachesis: What version of bitcoin ?
 53 2014-04-04 03:23:10 <lachesis> v0.9.0
 54 2014-04-04 03:23:16 <copumpkin> 294084 is current
 55 2014-04-04 03:23:29 <lachesis> that's what i see on blockchain.info, ya
 56 2014-04-04 03:24:02 <lachesis> ugh how do i force the bitcoind to leave safemode?
 57 2014-04-04 03:24:07 <lachesis> i want to find the hash of my top block
 58 2014-04-04 03:24:56 <Luke-Jr> lachesis: -safemode=0
 59 2014-04-04 03:25:19 <lachesis> Luke-Jr: anything else i should do before i restart to aid debugging if a restart fixes it
 60 2014-04-04 03:25:20 <lachesis> ?
 61 2014-04-04 03:25:34 <Luke-Jr> dunno
 62 2014-04-04 03:25:49 <lachesis> k, well restart it is
 63 2014-04-04 03:26:34 <lachesis> https://gist.github.com/lachesis/28eb858cdf67cc290462
 64 2014-04-04 03:26:41 <lachesis> database corrupted, huh?
 65 2014-04-04 03:27:48 <lachesis> https://gist.github.com/lachesis/28eb858cdf67cc290462 now it's looping this
 66 2014-04-04 03:28:33 <Luke-Jr> lachesis: did you downgrade?
 67 2014-04-04 03:28:38 <lachesis> no
 68 2014-04-04 03:28:41 <lachesis> i'm on 0.9.0
 69 2014-04-04 03:28:46 <lachesis> it was working fine for some time
 70 2014-04-04 03:28:54 <lachesis> i am on a newer version of bdb
 71 2014-04-04 03:29:12 <lachesis> 5.1 i think
 72 2014-04-04 03:30:07 <copumpkin> I thought bdb was gone
 73 2014-04-04 03:30:20 <lachesis> *shrug* bitcoind is linked against it
 74 2014-04-04 03:31:05 <lachesis> so what should i do about this corruption detected message?
 75 2014-04-04 03:32:29 <lachesis> gmaxwell: around?
 76 2014-04-04 03:34:12 <Luke-Jr> lachesis: get a new hard drive maybe
 77 2014-04-04 03:34:59 <Luke-Jr> although hard to rule out memory
 78 2014-04-04 03:38:26 <lachesis> why does it say "Aborted block database rebuild. Exiting." ?
 79 2014-04-04 03:38:31 <lachesis> i don't have any errors in dmesg from hdd
 80 2014-04-04 03:38:33 <lachesis> and it's a RAID 1
 81 2014-04-04 03:38:53 <Luke-Jr> lachesis: because you're not running a GUI
 82 2014-04-04 03:38:57 <lachesis> of drives that were (until recently) in a ZFS array
 83 2014-04-04 03:43:43 <lachesis> this will be my first time running bitcoin-qt
 84 2014-04-04 03:43:50 <lachesis> i've been on bitcoind since the wxwindows days
 85 2014-04-04 03:47:50 <Luke-Jr> you could use -reindex to have bitcoind do it :p
 86 2014-04-04 03:47:59 <Luke-Jr> -qt is nice though
 87 2014-04-04 03:48:01 <lachesis> oh now you tell me :)
 88 2014-04-04 03:48:05 <lachesis> qt just finished building
 89 2014-04-04 03:48:10 <lachesis> i think i'll fire it up, wonder how it looks now
 90 2014-04-04 03:49:03 <Luke-Jr> lachesis: Bitcoin-Qt has no relation to wxBitcoin, besides using the core bitcoin code
 91 2014-04-04 03:53:24 <Belxjander> wxBitCoin?
 92 2014-04-04 03:54:40 <Luke-Jr> Belxjander: the original client Satoshi wrote
 93 2014-04-04 03:54:51 <Belxjander> ahhh okay
 94 2014-04-04 03:59:41 <warren> anyone have an example of what gettransaction looks like if you query a double-spent txid?
 95 2014-04-04 04:13:16 <Luke-Jr> warren: in 0.9, "confirmations": -1 I think
 96 2014-04-04 04:13:48 <Luke-Jr> (check for <0, not ==-1)
 97 2014-04-04 04:30:53 <phrackage> Before I go making up my own DB - is there any online service or API that allows me to get the fiat equivalent of historical blockchain transactions (for a couple of popular exchanges)?
 98 2014-04-04 04:31:11 <lachesis> Luke-Jr: what are your thoughts on the selfish mining paper? it seems sane to me, but i don't see people in the bitcoin community shouting about it.
 99 2014-04-04 04:33:37 <olalonde> hi all. is there any technical difference between a cold start (0 blocks downloaded) and a normal start?
100 2014-04-04 04:33:47 <olalonde> or are both cases pretty much handled the same
101 2014-04-04 04:34:34 <gmaxwell> I can't think of any difference off the top of my head.
102 2014-04-04 04:34:46 <olalonde> ok
103 2014-04-04 04:35:01 <olalonde> I guess except bitcoind specific stuff like creating the proper directory structure
104 2014-04-04 04:35:17 <Luke-Jr> lachesis: tired of answering about nonsense papers written by clueless people
105 2014-04-04 04:35:37 <lachesis> Luke-Jr: alright...
106 2014-04-04 04:36:02 <gmaxwell> lachesis: I think luke is being a bit harsh there, but it's been extensively discussed elsewhere...
107 2014-04-04 04:36:03 <olalonde> what paper?
108 2014-04-04 04:37:48 <Luke-Jr> gmaxwell: meh, that one may have been on the "less bad" end, but in general these kind of papers are rubbish
109 2014-04-04 04:38:25 <gmaxwell> I'm perhaps more sympathetic after talking to one of the authors in person. It certantly got a lot of rubbish promotion.
110 2014-04-04 04:39:01 <BCB> what is the difference betweek block verion 1 and version 2
111 2014-04-04 04:39:04 <gmaxwell> lachesis: basically they have some assumptions which are not realistic (that the attacker has a communications advantage), and their proposed fix creates a more reliable vulnerability at hashrates pools are actually at. There might be some improvement to be made, but the prefer first block generally creates incentives against withholding. There is also an interesting point that doing this delays your income, not a great strategy while ...
112 2014-04-04 04:39:10 <gmaxwell> ... the hashrate is rising exponentially.
113 2014-04-04 04:39:43 <lachesis> gmaxwell: that's an interesting point.
114 2014-04-04 04:40:16 <lachesis> gmaxwell: i wasn't conscious of that assumption, but now that i look at it, it does seem dubious
115 2014-04-04 04:40:30 <Luke-Jr> gmaxwell: they need to get over themselves, realise nobody cares to steal credit for their stupid paper, and verify facts :P
116 2014-04-04 04:40:36 <gmaxwell> Ultimately there may be some improvements to make there, but sorting out the best approach is hard and the current behavior— of prefering the first block you heard— does strongly encourage the right behavior, assuming no network position advantage. ... with it being so easily detected if its going on it wouldn't seem prudent to be overly hasty.
117 2014-04-04 04:40:46 <BCB> and what is the diff between blk00000.dat and blk00002 data structures
118 2014-04-04 04:40:56 <lachesis> i suppose the honest and attacking pools would both have similar connectivity
119 2014-04-04 04:41:04 <lachesis> although they both have better connectivity than my node
120 2014-04-04 04:41:14 <gmaxwell> BCB: block v2 has the height in coinbase.
121 2014-04-04 04:41:32 <BCB> and what is the diff between blk00000.dat and blk00002 data structures
122 2014-04-04 04:41:40 <gmaxwell> lachesis: it's more than that, to get the full effect described in the paper the attacker must sybil the network so they always hear block announcements first and can preempt them.
123 2014-04-04 04:41:50 <gmaxwell> BCB: -ENONSENSEQUESTION
124 2014-04-04 04:43:17 <BCB> gmaxwell, my parser works on blk00000.dat but breaks on blk00001.dat
125 2014-04-04 04:43:22 <gmaxwell> BCB: there is no difference the blk%5d.dat files are all just more blocks.
126 2014-04-04 04:43:34 <gmaxwell> BCB: welp perhaps you should fix your code?
127 2014-04-04 04:43:35 <gmaxwell> :P
128 2014-04-04 04:43:46 <BCB> gmaxwell, working on that
129 2014-04-04 04:44:01 <gmaxwell> :)
130 2014-04-04 04:44:02 <Luke-Jr> BCB: there's nothing that prevents garbage corruption at the end of the file (which is then later appended onto)
131 2014-04-04 04:44:14 <BCB> hmm interesting
132 2014-04-04 04:44:31 <gmaxwell> yea, you might have had a truncated write with an unclean shutdown, and then it just appended to it.
133 2014-04-04 04:44:47 <gmaxwell> there is currently no blockfile vacuum.
134 2014-04-04 04:44:54 <BCB> I'll write one
135 2014-04-04 04:45:06 <BCB> so is a rescan in order
136 2014-04-04 04:45:20 <vetch> gmaxwell: block vacuum? I'm still waiting for a pool boy.
137 2014-04-04 04:45:21 <BCB> ?
138 2014-04-04 04:45:29 <BCB> I don't do pools
139 2014-04-04 04:45:43 <vetch> memory pool, not mining pool.
140 2014-04-04 04:45:55 <BCB> ahhh I'll think about that
141 2014-04-04 04:46:12 <kazcw> block vacuum... so you can move ~64MB of data on disk in order to save ~.25MB?
142 2014-04-04 04:49:31 <gmaxwell> well I'll come about as a side effect of pruning in any case... and the blocks are now grouped in smaller files specifically to make that kind of rewriting more realistic (rewriting a 2gb file kinda stinks!)
143 2014-04-04 04:51:49 <Luke-Jr> gmaxwell: why rewrite at all? just tell the OS to punch a hole.. :P
144 2014-04-04 04:54:08 <phantomcircuit> Luke-Jr, dat fragmentation
145 2014-04-04 04:54:51 <phantomcircuit> BCB, the parser for blk*.dat in bitcoin-core is exceptionally forgiving of errors
146 2014-04-04 04:55:46 <Luke-Jr> phantomcircuit: that's because Bitcoin Core *never* parses blk*.dat :P
147 2014-04-04 04:55:55 <SomeoneWeird> Luke-Jr, ahah
148 2014-04-04 04:56:17 <BCB> phantomcircuit, I'm doing it in bash
149 2014-04-04 04:56:30 <Luke-Jr> BCB: …………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
150 2014-04-04 04:56:40 <phantomcircuit> BCB, you're doing wat
151 2014-04-04 04:56:53 <BCB> I'm parsing block headers in bash
152 2014-04-04 04:56:55 <kazcw>  /facebash
153 2014-04-04 04:57:35 <kazcw> what would possess you to do that?
154 2014-04-04 04:57:54 <BCB> kazcw then I'm going to write a parser in Fortran
155 2014-04-04 04:58:12 <phantomcircuit> BCB, please stop
156 2014-04-04 04:58:17 <phantomcircuit> there's blood coming out of my eyes
157 2014-04-04 04:58:18 <Luke-Jr> ok now that's just too far
158 2014-04-04 05:00:19 <BCB> i'm using xdd / hexdump and cat :P
159 2014-04-04 05:02:58 <gmaxwell> BCB: pft. you're not writing it in bitcoin script?
160 2014-04-04 05:03:28 <BCB> gmaxwell, that is next
161 2014-04-04 05:04:01 <Luke-Jr> BCB: just skip to Pythoncoin
162 2014-04-04 05:06:16 <Belxjander> so however a local bitcoin "client" whether it is a wallet/node/miner handles the blockchain as block records is up to the implimentor?
163 2014-04-04 05:06:33 <Belxjander> as long as the protocol is 100% compliant with generated packets from the client concerned?
164 2014-04-04 05:06:59 <BCB> my first block in blk00001.dat is 25498 bytes??
165 2014-04-04 05:07:11 <BCB> that's a bit large no
166 2014-04-04 05:07:27 <Belxjander> BCB: are you reading the DB data files directly?
167 2014-04-04 05:07:33 <BCB> yes
168 2014-04-04 05:07:37 <BCB> xdd
169 2014-04-04 05:07:43 <Belxjander> BCB: as that will be BerkeleyDB or LevelDB data...not BitCoin directly
170 2014-04-04 05:08:06 <gmaxwell> Belxjander: uh, of course.
171 2014-04-04 05:08:25 <gmaxwell> Belxjander: the block files are just blocks.
172 2014-04-04 05:08:34 <BCB> xdd -p blk.dat | grep -b -n f9beb4d9
173 2014-04-04 05:08:46 <Belxjander> gmaxwell: I've worked out a possible tweak that makes endian issues irrelevant as long as the data is processed in the same order afaict
174 2014-04-04 05:09:05 <BCB> first 2nd offset is 25498
175 2014-04-04 05:09:25 <BCB> *2nd
176 2014-04-04 05:09:46 <BCB> that a big freaking block
177 2014-04-04 05:10:11 <BCB> *xxd
178 2014-04-04 05:18:33 <BCB> Luke-Jr, so how do I fix block corruption.  Delete and redownload??
179 2014-04-04 05:22:37 <BCB> gmaxwell, I fixed my code!
180 2014-04-04 05:34:46 <phantomcircuit> BCB, cat blocks/blk*.dat > bootstrap.dat; bitcoind -loadblock=bootstrap.dat
181 2014-04-04 05:34:50 <phantomcircuit> er
182 2014-04-04 05:35:08 <phantomcircuit> you have to delete everything in between
183 2014-04-04 05:35:13 <phantomcircuit> but that's close enough
184 2014-04-04 05:57:00 <etotheipi_> for signing multi-sig tx... you are supposed to put an OP_0 in place of signatures that aren't present, correct?
185 2014-04-04 05:57:09 <etotheipi_> for some reason I can't find any examples of this
186 2014-04-04 06:06:44 <Luke-Jr> etotheipi_: I don't think so. there's a BIP
187 2014-04-04 06:07:02 <etotheipi_> Luke-Jr: seriously, I can't find any examples
188 2014-04-04 06:07:04 <etotheipi_> am I blind?
189 2014-04-04 06:07:36 <Luke-Jr> hm
190 2014-04-04 06:07:42 <Luke-Jr> guess the BIP doesn't have the sig details
191 2014-04-04 06:08:06 <etotheipi_> seriously, I've spent a lot of time looking for this...
192 2014-04-04 06:08:06 <Luke-Jr> etotheipi_: I *think* it's just the actual sigs, in order
193 2014-04-04 06:08:11 <Luke-Jr> skip ones you don't use
194 2014-04-04 06:08:34 <etotheipi_> oh I guess rather than chasing things around, I could just mess with my createSigScript method to try that
195 2014-04-04 06:10:08 <etotheipi_> holy $#!+
196 2014-04-04 06:10:11 <etotheipi_> it worked
197 2014-04-04 06:10:12 <etotheipi_> thanks Luke-Jr !
198 2014-04-04 06:10:26 <Luke-Jr> XD
199 2014-04-04 06:10:28 <Luke-Jr> np
200 2014-04-04 06:10:48 <etotheipi_> just executed my first multi-sig spend... after like... forever
201 2014-04-04 06:10:57 <etotheipi_> thousands of lines of code later
202 2014-04-04 07:21:24 <wumpus> phew... and, was it worth it?
203 2014-04-04 07:49:57 <dcousens_> The constants 0x00 for HASH160, 0x80 for WIF and 0x05 for P2SH, are these following some kind of format or just randomly chosen constants?
204 2014-04-04 08:02:35 <wumpus> not really, it's just a matter of claiming a number that's preferably not in use yet https://en.bitcoin.it/wiki/List_of_address_prefixes
205 2014-04-04 08:05:09 <petertodd> wumpus: reminds me: we should consider doing a BIP with just a list of address prefixes
206 2014-04-04 08:05:25 <dcousens> thanks wumpus
207 2014-04-04 08:06:39 <petertodd> wumpus: e.g. I'm going to be picking at least one for stealth addresses soon. I'm also wondering if the model of a single version byte is really the right way to go, given that it looks like addresses may be useful even when they aren't seen by humans in the "this is how I want you to create the actual scriptPubKey(s)" model
208 2014-04-04 08:06:44 <wumpus> petertodd: yes, although it will probably be a fight what to include
209 2014-04-04 08:06:52 <petertodd> wumpus: certainly!
210 2014-04-04 08:07:12 <wumpus> 'why is litecoin in this list, but not mypoopcoin?'
211 2014-04-04 08:07:32 <petertodd> wumpus: it would have been better had addresses had a generic "chain UUID" in them, along with another number for the type
212 2014-04-04 08:08:18 <Luke-Jr> petertodd: each address version has its own BIP :p
213 2014-04-04 08:08:33 <petertodd> for instance we kinda wound up re-inventing that for the OpenPGP address extension I'm helping with
214 2014-04-04 08:08:52 <wumpus> right, the type of address and the chain has been combined into one byte, that leaves very little wiggle room
215 2014-04-04 08:08:54 <Luke-Jr> it looks like addresses may be useful even when they aren't seen by humans in the "this is how I want you to create the actual scriptPubKey(s)" model <--- um, just send the actual sPK..
216 2014-04-04 08:09:00 <petertodd> wumpus: yup!
217 2014-04-04 08:09:35 <petertodd> Luke-Jr: for stealth addresses there is no "actual sPK" to send - the scriptPubKey used depends on the sender and can't be "just" specified by the receiver
218 2014-04-04 08:09:38 <Luke-Jr> wumpus: rather, there simply is no "chain identifier" at all; the alts are just abusing it ;P
219 2014-04-04 08:09:46 <wumpus> I'm sure there are already more altcoins than address prefixes (though that's their problem, they don't have to use the bitcoin convention at all)
220 2014-04-04 08:09:57 <Luke-Jr> petertodd: hm, true
221 2014-04-04 08:09:57 <petertodd> Luke-Jr: meh, might as well be pragmatic IMO and give them a catch-all UUID
222 2014-04-04 08:10:12 <Luke-Jr> petertodd: you know I wrote up a possible spec that DID have a chain id..?
223 2014-04-04 08:10:29 <petertodd> Luke-Jr: similarly, BIP32 chain ID's can't have the scriptPubKey specified up front
224 2014-04-04 08:10:31 <wumpus> it's just that, for bitcoin, no one is interested in switching the address encoding
225 2014-04-04 08:10:33 <wumpus> it works so...
226 2014-04-04 08:10:35 <petertodd> Luke-Jr: oh yeah?
227 2014-04-04 08:11:39 <Luke-Jr> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02183.html
228 2014-04-04 08:11:52 <Luke-Jr> 11 months ago :P
229 2014-04-04 08:13:22 <Luke-Jr> the actual format spec is a comment in the example code
230 2014-04-04 08:13:46 <petertodd> Luke-Jr: ah, right, I remember that now
231 2014-04-04 08:14:01 <Luke-Jr> wow, I even wrote a test suite XD
232 2014-04-04 08:15:38 <petertodd> Luke-Jr: I'd do a 128-bit UUID for the alt-chain ids so we can get out of the business of trying to allocate them
233 2014-04-04 08:16:06 <warren> hmm
234 2014-04-04 08:16:07 <warren>     "version" : 99900,
235 2014-04-04 08:16:16 <warren> the next release will not be a 0.9.x?
236 2014-04-04 08:16:18 <Luke-Jr> petertodd: then everyhting gets long
237 2014-04-04 08:16:39 <Luke-Jr> warren: if it is, it'd be based on the 0.9.x branch I'd think
238 2014-04-04 08:16:48 <Luke-Jr> warren: remember it got branched off master before 0.9.0
239 2014-04-04 08:16:48 <warren> ugh
240 2014-04-04 08:16:51 <petertodd> Luke-Jr: I'm thinking about this assuming that most uses of these "advanced addresses" will be hidden from the user in payment requests, OpenPGP keys etc.
241 2014-04-04 08:16:56 <warren> Luke-Jr: it did?  damn
242 2014-04-04 08:17:22 <Luke-Jr> petertodd: then binary works fine :P
243 2014-04-04 08:17:34 <petertodd> Luke-Jr: e.g. the stealth address standard results in some really long addresses at worst, an at the same time, it was mainly developed so you could put an address in OpenPGP
244 2014-04-04 08:18:10 <petertodd> Luke-Jr: exactly - our OpenPGP prototype just takes the raw bytes of an address, chops off the checksum bytes, and encodes it in a new type of user attribute
245 2014-04-04 08:18:27 <Luke-Jr> eh, might want to keep the checksum
246 2014-04-04 08:18:45 <Luke-Jr> might be okay for PGP, but if you want something generic..
247 2014-04-04 08:18:46 <petertodd> Luke-Jr: the user attribute data is signed, so I'm not too worried there
248 2014-04-04 08:19:16 <petertodd> Luke-Jr: right, I think any standard should have a "human-readable" version of the encoding which has a well-defined checksum
249 2014-04-04 08:20:07 <Luke-Jr> petertodd: anyhow, c32d could easily be extended to a longer namespace size; but I think gmaxwell had suggested some other improvements too, so might be good to look at those if you want to do something
250 2014-04-04 08:20:49 <petertodd> Luke-Jr: cool, link?
251 2014-04-04 08:21:13 <petertodd> Luke-Jr: this might get added to dark wallet and released relatively soon - they want to ship stealth address support in the next two or three weeks
252 2014-04-04 08:21:29 <Luke-Jr> petertodd: lol, I'm not that organised :D
253 2014-04-04 08:22:10 <petertodd> Luke-Jr: ha
254 2014-04-04 08:42:40 <sipa> dcousens: originally intendrd to follow a pattern, but by changingnthe pattern all the time, effectively mostly arbitrary
255 2014-04-04 08:57:51 <vetch> wumpus, Luke-Jr: regarding the version byte for future bitcoin address types, most of the "altcoins" seem to stick to alpha characters and ignore the numerical ones altogether. from a quick trawl of they altcoins subform on bitcointalk the ones what have bothered to change it just use the first letter of the coin name and picks the relevant address byte to match it. a large number seem not to bother at all and just use the same ones Bitcoin uses.
256 2014-04-04 08:58:37 <vetch> wumpus, Luke-Jr: didn't see any Qs but there's literally hundreds of them to collate at this point. the fact that there's a number of altcoins using the same bytes as bitcoin suggests confusion isn't so much of an issue, right?
257 2014-04-04 08:59:05 <Luke-Jr> vetch: my point is, the altcoins are not "real"
258 2014-04-04 08:59:46 <arjen-jonathan> when *HaveCoins* on a CCoinsViewCache returns false, does that mean the coins are spent? Or can it also just indicate a cache miss?
259 2014-04-04 09:00:43 <vetch> Luke-Jr: of course they're not real. the issue lies in people thinking they are and associating a particular address type with a pump and dump rather than a stealth address.
260 2014-04-04 09:01:16 <vetch> or whatever address type a conflicted version byte represents.
261 2014-04-04 09:05:46 <arjen-jonathan> Any devs here at this hour?
262 2014-04-04 09:27:12 <wumpus> arjen-jonathan: it means that a) the coins are spent or b) the input doesn't exist at all
263 2014-04-04 09:30:13 <olalonde> https://en.bitcoin.it/wiki/Protocol_specification#tx <-- is this the same format as the forma inside blocks?
264 2014-04-04 09:31:48 <wumpus> alecalve: yes
265 2014-04-04 09:33:13 <olalonde> answer: yes
266 2014-04-04 09:33:31 <wumpus> transactions always use the same format, that's pretty nice
267 2014-04-04 09:39:39 <arjen-jonathan> wumpus: What does "does not exist at all" mean then? i.e.: It is an 'invalid' transaction or 'we don't know about this input and should get it'
268 2014-04-04 09:41:15 <wumpus> it would usually mean it is invalid, someone could just make up a txid/vout pair
269 2014-04-04 09:41:38 <wumpus> I just mean that using the function there is no way to distinguish between a spent output and one that doesn't exist
270 2014-04-04 09:42:03 <wumpus> but for the use case it doesn't matter as in both cases they're not valid for spending
271 2014-04-04 09:45:49 <arjen-jonathan> Ah thanks.
272 2014-04-04 09:45:55 <arjen-jonathan> Can I ask you something else?
273 2014-04-04 09:46:02 <wumpus> don't ask to ask, just ask
274 2014-04-04 09:46:18 <wumpus> even if I don't know one of the 552 other peopl in the channel might
275 2014-04-04 09:46:22 <arjen-jonathan> How would one go about finding out at what height a downloaded block is in the blockchain?
276 2014-04-04 09:46:43 <arjen-jonathan> (assuming I might still be downloading new blocks)
277 2014-04-04 09:47:49 <arjen-jonathan> Does a node know at what height the longest chain in the network is? Even if it's still downloading blocks
278 2014-04-04 09:47:59 <wumpus> what is the use case? you have a pointer to a CBlock structure and want to find out the height?
279 2014-04-04 09:48:29 <arjen-jonathan> I only have a pointer to the transaction for now.
280 2014-04-04 09:48:44 <wumpus> a node always knows the height because it can find the way back to the genesis block
281 2014-04-04 09:49:12 <arjen-jonathan> Oh, yes sorry. I need the depth actually.
282 2014-04-04 09:49:19 <wumpus> wtx.GetDepthInMainChain() ?
283 2014-04-04 09:49:39 <arjen-jonathan> Would that work even if we're still downloading new blocks?
284 2014-04-04 09:49:56 <arjen-jonathan> Say if I've been offline for a while, downloading blocks, would I get an accure depth?
285 2014-04-04 09:50:35 <wumpus> depth is always relative to the current synchonization/indexing position
286 2014-04-04 09:51:05 <wumpus> if you have been offline for a while, all newer transactions are at depth 0 (unconfirmed)
287 2014-04-04 09:51:42 <arjen-jonathan> So depth is a local property?
288 2014-04-04 09:52:04 <arjen-jonathan> Is there a notion of depth of a transaction with respect to what the network agreed on?
289 2014-04-04 10:06:36 <arjen-jonathan> Anyone? Is there any notion inside a node of the depth of a block in the network (in contrast to the local known depth)?
290 2014-04-04 10:12:21 <EricLarch> Hello. I wrote a BIP draft about a Bitcoin address authentification protocol for websites and applications. It is available here https://bitcointalk.org/index.php?topic=557037.0  ; my question is : should I post it to the bitcoin-dev mailing list, or is it better to keep the discussion on Bitcointalk until there is at least some support from the community ?
291 2014-04-04 10:15:38 <wumpus> arjen-jonathan: no
292 2014-04-04 10:16:07 <wumpus> arjen-jonathan: in general in P2P, everything is local, and relative to your own view of things
293 2014-04-04 10:17:36 <wumpus> arjen-jonathan: you'd need a SPV client to know where a transaction is in the chain without downloading and verifying all the blocks
294 2014-04-04 10:25:48 <arjen-jonathan> That makes sense.
295 2014-04-04 10:44:29 <Luke-Jr> EricLarch: BitcoinTalk is just trolls, all real development is on IRC and the ML
296 2014-04-04 10:47:59 <archrs> looks cool, eric
297 2014-04-04 10:48:24 <olalonde> I wonder why satoshi didn't make it possible to spend just part of a txout
298 2014-04-04 10:48:25 <Luke-Jr> EricLarch: also, your URI is malformed. and the current spec doesn't mean the expected standards for signed messages (timestamp followed by human-readable contract)
299 2014-04-04 10:48:48 <Luke-Jr> olalonde: that's vulnerable to races
300 2014-04-04 10:49:19 <Luke-Jr> olalonde: ie, the same kind of problem as if it had address balances
301 2014-04-04 10:49:28 <olalonde> Luke-Jr: care to elaborate?
302 2014-04-04 10:49:32 <olalonde> or link to somewhere
303 2014-04-04 10:49:54 <Luke-Jr> olalonde: http://tools.ietf.org/html/rfc3986
304 2014-04-04 10:50:04 <Luke-Jr> olalonde: oh, that link is for EricLarch sorry
305 2014-04-04 10:50:16 <Luke-Jr> olalonde: there's nothing to link to for you
306 2014-04-04 10:50:20 <olalonde> haha ok
307 2014-04-04 10:51:14 <Luke-Jr> olalonde: if you had an output with 2 BTC, then you could make two transactions spending 1 BTC from it. then you can't safely double-spend it.
308 2014-04-04 10:51:17 <olalonde> so you think a system like bitcoin where you can transfer only a fraction of the value of a TxOut wouldn't work?
309 2014-04-04 10:52:21 <Luke-Jr> no
310 2014-04-04 10:52:21 <olalonde> "you can't safely double spend it"? isn't that a good thing?
311 2014-04-04 10:52:46 <Luke-Jr> double spending is not always bad
312 2014-04-04 10:53:07 <Luke-Jr> for example, if you don't include enough of a fee, you need to double-spend to safely add a fee (in some cases at least)
313 2014-04-04 10:53:16 <Luke-Jr> or you end up goxing yourself
314 2014-04-04 10:53:21 <olalonde> perhaps it would make the system more complex to implement
315 2014-04-04 10:53:35 <olalonde> but I don't see the hard theoretical problems with such a scheme
316 2014-04-04 10:54:07 <olalonde> ah ok I think I see what you mean
317 2014-04-04 10:54:38 <olalonde> if you re sent the same transaction, both transactions could get confirmed
318 2014-04-04 10:55:46 <olalonde> right, makes sense
319 2014-04-04 10:57:12 <olalonde> there could be an additional field that would say the value left on the txout after the transaction but yeah.. not very practical
320 2014-04-04 10:57:57 <HM> http://preshing.com/20131219/bitcoin-address-generator-in-obfuscated-python/
321 2014-04-04 10:58:00 <HM> this is so cool
322 2014-04-04 10:58:06 <HM> and so old :(
323 2014-04-04 11:29:27 <EricLarch> Luke-Jr: thanks
324 2014-04-04 11:32:01 <vetch> HM: that's sort of awkward that he only blurred a tiny part of the key. I know there's no money at stake but it's really no protection at all.
325 2014-04-04 11:32:51 <vetch> HM: we know the font and the shape of the letters underneath. it wouldn't be a whole lot of work to run through the small number of missing characters and recover the key.
326 2014-04-04 11:33:10 <vetch> never blur sensitive data. never never never.
327 2014-04-04 11:33:27 <EricLarch> Luke-Jr : where is the URI invalid ? I checked using http://www.websitedev.de/temp/rfc3986-check.html.gz and it passes
328 2014-04-04 11:33:54 <Luke-Jr> EricLarch: :// is for locations only
329 2014-04-04 11:34:06 <Luke-Jr> EricLarch: hence mailto: and bitcoin: do not have //
330 2014-04-04 11:37:05 <EricLarch> Luke-JR : understood, I'll correct it
331 2014-04-04 11:37:34 <EricLarch> Luke-Jr : is the human readable message strictly enforcable ? because there is a language problem
332 2014-04-04 11:37:58 <EricLarch> Luke-Jr : it will be up to the wallet to present the authentication request in a human readable format, in the language of choice
333 2014-04-04 11:42:20 <vetch> EricLarch: how often do you find yourself buying something on a foreign website you don't know the language of?
334 2014-04-04 11:45:13 <EricLarch> vtech : if I'm on a French website, the message to sign should be in French ; it just means that the URI must contain the message to sign in plain text and a parsable version for the wallet to understand
335 2014-04-04 11:53:50 <aekym> Hi, I have an issue with submitting a raw transaction
336 2014-04-04 11:53:57 <aekym> Up to signrawtransaction everything is ok
337 2014-04-04 11:54:24 <aekym> But on sendrawtransaction I get 'Tx rejected'
338 2014-04-04 11:54:32 <aekym> Bitcoind 0.8.5
339 2014-04-04 11:54:46 <aekym> Help is very much appreciated
340 2014-04-04 11:54:54 <vetch> vetch: the URI is not really human readable. any text displayed to the user can be customisable.
341 2014-04-04 11:55:03 <vetch> er, EricLarch
342 2014-04-04 11:55:34 <vetch> aekym: how's your fees? you should also probably upgrade either way.
343 2014-04-04 11:57:56 <aekym> Upgrade, I know, but don't have the time right now. Need to fix the issue first..
344 2014-04-04 11:58:02 <EricLarch> vtech : I'll amend the BIP draft in this direction
345 2014-04-04 11:58:06 <aekym> Fee is standard 0.0001
346 2014-04-04 11:59:28 <vetch> what's the reject message?
347 2014-04-04 12:00:59 <aekym> "TX rejected"
348 2014-04-04 12:01:02 <aekym> Code -22
349 2014-04-04 12:01:15 <aekym> Probably coming from here: https://github.com/bitcoin/bitcoin/blob/0.8.5/src/rpcrawtransaction.cpp#L562
350 2014-04-04 12:03:39 <aekym> The very same source code runs just fine within the testnet, but in the normal bitcoin network I'm having trouble
351 2014-04-04 12:06:40 <vetch> I think the debug.log gives a better reject message with a reason.
352 2014-04-04 12:08:19 <vetch> though the "mucho data" reason is so hilarious that it looks to have been removed, sadly.
353 2014-04-04 12:12:18 <wumpus> in master you get better error reporting on sendrawtransaction
354 2014-04-04 12:19:38 <olalonde> question about nLockTime... what is it supposed to do? a transaction is not valid if one of its txin has a nLockTime > current time?
355 2014-04-04 12:20:11 <olalonde> or is the transaction valid but its output can't be spent until nLockTime
356 2014-04-04 12:22:47 <vetch> a transaction is invalid until the time.
357 2014-04-04 12:22:56 <sipa> olalonde: valid, but not confirmable before the locktime has expired
358 2014-04-04 12:23:15 <sipa> so it cannot be included in the blockchain until that time
359 2014-04-04 12:23:24 <vetch> the time or the block height, whichever the value is parsed as.
360 2014-04-04 12:23:37 <olalonde> I see... is there any use case for this? seems like the equivalent of just waiting the nLockTime to broadcast the transaction
361 2014-04-04 12:24:09 <sipa> olalonde: ican give you a paybackntransaction ahead of time for some deal we're going to do
362 2014-04-04 12:24:20 <vetch> I can sign a transaction and give it to you. you can't do anything but wait until it is time to broadcast it. for contingencies for example.
363 2014-04-04 12:24:24 <sipa> if the deal doesn't go through, younget your money back
364 2014-04-04 12:24:32 <olalonde> but is there anything that prevents you from spending the same outputs?
365 2014-04-04 12:24:39 <vetch> nope
366 2014-04-04 12:24:41 <sipa> see the contracts page on the wiki
367 2014-04-04 12:24:43 <sipa> nope
368 2014-04-04 12:25:16 <olalonde> so what kind of assurance does having that transaction give me?
369 2014-04-04 12:26:04 <olalonde> maybe it could be used as a "dead man" switch?
370 2014-04-04 12:26:51 <olalonde> like you give a transaction to someone that spends your cold storage coins and if you don't move your coins before nLockTime.. the person has access to your coins
371 2014-04-04 12:27:16 <sipa> yuop
372 2014-04-04 12:27:18 <sipa> yup
373 2014-04-04 12:27:24 <olalonde> cool
374 2014-04-04 12:27:28 <sipa> but see the contracts page for more use cases
375 2014-04-04 12:27:32 <olalonde> ok
376 2014-04-04 12:27:48 <olalonde> thanks
377 2014-04-04 12:34:23 <olalonde> why do TxOuts have hash of transaction and index fields. Isn't that redundant information given that they are part of the transaction message?
378 2014-04-04 12:35:08 <olalonde> oh nevermind
379 2014-04-04 12:35:19 <olalonde> there is a OutPoint structure defined in  the wiki
380 2014-04-04 12:35:27 <JyZyXEL> whats the point of having P2SH capability in an escrow market system?
381 2014-04-04 12:35:28 <olalonde> and a TxOut structure
382 2014-04-04 12:35:36 <aekym> debug.log tells: "ERROR: CTxMemPool::accept() : nonstandard transaction type"
383 2014-04-04 12:35:59 <olalonde> oh outpoint is part of TxIn, nevermind
384 2014-04-04 12:37:22 <aekym> Not sure how I was able to achieve that..
385 2014-04-04 12:39:09 <JyZyXEL> nevermind, i finally found a page that explains it clearly: https://www.belshe.com/2013/12/15/p2sh-safe-addresses/
386 2014-04-04 12:41:38 <aekym> Oh, that is interesting and explains why I haven't had the issue with the testnet:
387 2014-04-04 12:41:39 <aekym>     if (!fTestNet && !tx.IsStandard())         return error("CTxMemPool::accept() : nonstandard transaction type");
388 2014-04-04 12:42:31 <aekym> https://github.com/bitcoin/bitcoin/blob/0.8.5/src/main.cpp#L664
389 2014-04-04 12:44:16 <vetch> aekym: what were you doing to make your transaction not standard?
390 2014-04-04 12:44:46 <aekym> ha, exactly my question
391 2014-04-04 12:45:35 <aekym> building a raw tx
392 2014-04-04 12:45:35 <aekym> but works perfectly fine in testnet
393 2014-04-04 12:48:15 <vetch> what does it consist of exactly?
394 2014-04-04 12:50:08 <aekym> Do you mean the details of the tx?
395 2014-04-04 12:52:50 <aekym> it's send to: {"1a...":0.00150524,"1b...":0.00001075,"1c...":0.00000007,"1d...":0.00284546}
396 2014-04-04 12:53:00 <aekym> am i creating dust here?
397 2014-04-04 12:53:47 <aekym> (it's one of the things that's checked in the IsStandard method)
398 2014-04-04 12:56:54 <Apocalyptic> 0.00000007 < obvious dust
399 2014-04-04 12:58:26 <aekym> Alright, so I either increase that txout or the fee?
400 2014-04-04 12:58:42 <aekym>  // so dust is a txout less than 54 uBTC     // (5430 satoshis) with default nMinRelayTxFee
401 2014-04-04 12:59:53 <sipa> dust won't be relayed, even with a fee
402 2014-04-04 13:00:45 <aekym> Does that mean every txout needs to be at least 5430 satoshis--no matter what?
403 2014-04-04 13:00:45 <sipa> yes and no
404 2014-04-04 13:01:02 <sipa> every txout needs to be at least 3 times the marginal cost for spending it
405 2014-04-04 13:01:07 <aekym> b/c I saw tx with txout = 1 satoshi
406 2014-04-04 13:01:25 <sipa> that marginal cost is determined by the relay fee for every node, which is variable
407 2014-04-04 13:01:49 <sipa> in time, that relay fee will be guessed based on data from the network
408 2014-04-04 13:02:02 <sipa> rather than being hardcoded
409 2014-04-04 13:02:11 <aekym> makes sense
410 2014-04-04 13:02:16 <sipa> you can manually decrease your minrelayfee, but that doesn't guarantee that your peers will do the same
411 2014-04-04 13:02:30 <sipa> if you send it directly to a miner however, and they agree to mine it, everything is possible
412 2014-04-04 13:02:45 <sipa> standardness doesn't apply to transactions once they are in blocks
413 2014-04-04 13:02:54 <aekym> that may explain the tx i saw with 1 satoshi txout
414 2014-04-04 13:02:56 <aekym> i guess
415 2014-04-04 13:03:48 <aekym> ok, will increase the one txout i can influence and if that doesn't work, i guess, i need to upgrade to 0.9 to get a better explanation of what's happening
416 2014-04-04 13:04:26 <sipa> the default min relay decreased in 0.9 too, so it may happen that your node allows the transaction
417 2014-04-04 13:04:35 <sipa> but that still doesn't guarantee that other nodes will
418 2014-04-04 13:05:41 <aekym> true, and there are better tools to check that with 0.9
419 2014-04-04 13:06:01 <aekym> one thing, i really dislike that there is a different behavior for testnet and bitcoin network
420 2014-04-04 13:06:20 <sipa> yes, i understand
421 2014-04-04 13:06:25 <olalonde> http://syskall.com/bitcoin-notes/svg/blockchain.svg anyone care to see if I my graphs make sense?
422 2014-04-04 13:06:55 <Apocalyptic> 54 uBTC     // (5430 satoshis) // do you even math ?
423 2014-04-04 13:07:10 <sipa> olalonde: what do altcoins have to do with it?
424 2014-04-04 13:07:22 <sipa> or what do you refer to by alt chains?
425 2014-04-04 13:07:32 <sipa> also, orphan blocks are technically not part of the block chain
426 2014-04-04 13:07:40 <olalonde> sipa: ah no.. perhaps i used a non standard nomenclatures.. I meant chains that diverge from the longest chain
427 2014-04-04 13:07:59 <aekym> thanks for the help guys!
428 2014-04-04 13:08:08 <sipa> olalonde: those are actually not part of the block chain either
429 2014-04-04 13:08:15 <Apocalyptic> I was under the impression that the dust limit was something like 5** satoshis
430 2014-04-04 13:08:39 <Apocalyptic> or of similar order of magnitude
431 2014-04-04 13:08:39 <sipa> Apocalyptic: with the default minrelay fee in 0.9, yes
432 2014-04-04 13:08:41 <olalonde> sipa: I guess the blockchain here is called "main chain".
433 2014-04-04 13:08:55 <sipa> olalonde: yeah, that's confusing nomenclature but standard i guess
434 2014-04-04 13:08:56 <olalonde> sipa: orphan/altchains are still needed by clients so I included them
435 2014-04-04 13:09:22 <sipa> olalonde: i prefer to call the whole set of blocks connectable to the genesis block "the block tree"
436 2014-04-04 13:09:33 <olalonde> sipa: ok
437 2014-04-04 13:09:35 <sipa> olalonde: one path through the block tree is the active/main chain, or "the block chain"
438 2014-04-04 13:10:05 <sipa> orphan blocks are pieces of block tree(s) that are not connectable to genesis
439 2014-04-04 13:10:17 <olalonde> right
440 2014-04-04 13:10:29 <sipa> and you have dead branches of the block tree
441 2014-04-04 13:10:39 <sipa> (which are commonly, but incorrectly, called orphaned blocks)
442 2014-04-04 13:11:00 <sipa> which are potentially valid chains, but not active/main
443 2014-04-04 13:11:12 <vetch> Apocalyptic: around 5400.
444 2014-04-04 13:11:21 <sipa> vetch: in 0.8.x, yes
445 2014-04-04 13:11:27 <Apocalyptic> i thing it's a degree of magnitude lower than that
446 2014-04-04 13:11:27 <sipa> vetch: in 0.9, it's around 500
447 2014-04-04 13:11:45 <olalonde> ok... so I'll rename bockchain to block tree and alt chains to dead branches ... and blockchain will only be connected to the longest chain
448 2014-04-04 13:11:46 <sipa> or rather, with the default minrelayfee in 0.9
449 2014-04-04 13:11:58 <sipa> as you can set it to whatever you like
450 2014-04-04 13:12:03 <vetch> sipa: wouldn't most clients still be 0.8.x?
451 2014-04-04 13:12:11 <sipa> vetch: yes
452 2014-04-04 13:12:40 <vetch> got it. should be 500 but probably sill 5400 in practice.
453 2014-04-04 13:13:02 <sipa> 546 or so
454 2014-04-04 13:14:00 <olalonde> how about the block diagram? (you can click Block X)
455 2014-04-04 13:14:09 <BCB> phantomcircuit: thx
456 2014-04-04 13:14:48 <sipa> olalonde: cool
457 2014-04-04 13:15:01 <sipa> olalonde: you may want to organize the list of transactions into a merkle tree
458 2014-04-04 13:16:19 <aekym> I guess I need to upgrade to 0.9..
459 2014-04-04 13:16:19 <aekym> I increased the txout to 5555 satoshis, but have the same issue
460 2014-04-04 13:16:19 <olalonde> Right.. I was thinking about that actually
461 2014-04-04 13:16:29 <olalonde> but was a bit hesitant because I want to stay close to how the protocol represents the structures
462 2014-04-04 13:18:21 <gavinandresen> sipa: was there ever consensus on what to call blocks in the tree that aren't on the best chain?
463 2014-04-04 13:18:37 <sipa> gavinandresen: nope
464 2014-04-04 13:19:24 <sipa> extinct chains, stale chains, dead branches, side branches, ...
465 2014-04-04 13:19:25 <sipa> orphaned blocks
466 2014-04-04 13:19:28 <vetch> dead branch sounds more like a tree.
467 2014-04-04 13:20:10 <sipa> dead blocks, stale blocks, side blocks, orphaned blocks, extinct blocks, ...
468 2014-04-04 13:20:13 <sipa> inactive blocks :p
469 2014-04-04 13:20:21 <sipa> wha'evva
470 2014-04-04 13:20:28 <vetch> they're all sort of a bit too final. the side chain can become the leader again.
471 2014-04-04 13:20:42 <sipa> inactive, then?
472 2014-04-04 13:21:43 <vetch> dead branch fits the tree analogy better. inactive branch fits the fact that they can become active again. none of the terms are perfect, but orphan is pretty much wrong.
473 2014-04-04 13:22:58 <olalonde> I think dead branch might be confusing to a newbie because it sounds like the branch is dead forever
474 2014-04-04 13:23:00 <hearn> side chain blocks, i thought
475 2014-04-04 13:23:10 <hearn> that’s how i always referred to them
476 2014-04-04 13:23:43 <olalonde> I like side chains / orphan chains
477 2014-04-04 13:24:10 <vetch> well a chain can't become orphaned
478 2014-04-04 13:24:18 <gavinandresen> Sidechain blocks sounds good. But sidecar blocks is funnier...
479 2014-04-04 13:24:25 <olalonde> I didn't say orphaned.. I said orphan :P
480 2014-04-04 13:24:43 <venzen> olalonde: dead forever - unless you believe in the Circle of Life ;)
481 2014-04-04 13:27:53 <olalonde> but they're still a useful concept when learning how bitcoin clients work...
482 2014-04-04 13:27:53 <olalonde> haha
483 2014-04-04 13:27:53 <olalonde> mmmm so what should I call those :P
484 2014-04-04 13:27:53 <olalonde> updated: http://syskall.com/bitcoin-notes/svg/blockchain.svg
485 2014-04-04 13:27:53 <olalonde> what about chains that are not connected to the blockchain (yet) ?
486 2014-04-04 13:27:53 <venzen> blockaded
487 2014-04-04 13:27:53 <vetch> olalonde: well to become orphan you must be orphaned. both are impossible in this scenario.
488 2014-04-04 13:27:53 <vetch> side chains as sipa said seems the least confusing.
489 2014-04-04 13:27:53 <vetch> they're invalid, rejected
490 2014-04-04 13:27:53 <vetch> transactions can become orphaned by losing their block in a reorg, blocks can't lose their path to the root.
491 2014-04-04 13:28:42 <sipa> i don't like side chains as that term is also used for the pegged side chain idea
492 2014-04-04 13:28:49 <olalonde> right
493 2014-04-04 13:28:56 <sipa> (independent chains that use the same currency as another chain)
494 2014-04-04 13:28:59 <olalonde> alt chain taken.. side chain taken
495 2014-04-04 13:29:04 <olalonde> :O
496 2014-04-04 13:29:05 <olalonde> haha
497 2014-04-04 13:29:37 <sipa> < olalonde> what about chains that are not connected to the blockchain   <- orphan blocks
498 2014-04-04 13:30:44 <olalonde> that's what i used initially but seems there is no consensus here :p
499 2014-04-04 13:30:53 <sipa> it's how the source code calls them
500 2014-04-04 13:30:58 <sipa> since forever
501 2014-04-04 13:33:50 <olalonde> http://syskall.com/bitcoin-notes/svg/transaction.svg how about this one :p
502 2014-04-04 17:33:13 <SoftwareMechanic> I'm kinda confused about multisig.  So if I create a new multisig address (via addmultisigaddress in bitciond), and I send to that address, which of the original source address is associated with the resulting bitcoins?  Or am I thinking about it incorrectly?
503 2014-04-04 17:34:01 <SoftwareMechanic> I feel like I'm missing something fundamental
504 2014-04-04 17:37:40 <kazcw> Addresses are not "associated with" bitcoins. If you send to a regular address, the person with a key corresponding to that address can spend it; if you send to a multisig destination, people with keys corresponding to that multisig destination can spend it
505 2014-04-04 17:38:18 <kazcw> multisig transactions are usually created as p2sh transactions, in which case the multisig destination is a p2sh address
506 2014-04-04 17:38:37 <SoftwareMechanic> And that transaction is broadcast and put int he blockain right?
507 2014-04-04 17:39:09 <kazcw> if a transaction isn't in the blockchain, it's not a transaction. it's a potential transaction.
508 2014-04-04 17:39:25 <justanot1eruser> It's an unconfirmed transaction
509 2014-04-04 17:39:32 <justanot1eruser> but it's still a transaction
510 2014-04-04 17:39:44 <justanot1eruser> I guess at this point it's just words though
511 2014-04-04 17:40:31 <SoftwareMechanic> I'm unclear as to what state the transcation is in if, say, only one of the multisig signers has signed
512 2014-04-04 17:40:39 <kazcw> then you can't broadcast it
513 2014-04-04 17:40:45 <SoftwareMechanic> ahh
514 2014-04-04 17:43:06 <SoftwareMechanic> It's actually surprisingly hard to fully comprehend that there are no account balances really, only transactions.  It's opposite of how I'm used to thinking about these things
515 2014-04-04 17:43:51 <SoftwareMechanic> It's like assembly language for monetary systems
516 2014-04-04 17:53:32 <gmaxwell> SoftwareMechanic: I don't know why it's hard to comprehend.  When you look at your wallet and see a collection of dimes and nickels and pennies do you assume there is a balance someplace? :)
517 2014-04-04 17:54:29 <SoftwareMechanic> I think of it as there are X dollars and cents.  Not as the sum of transaction since the money was created.
518 2014-04-04 17:55:06 <kazcw> that's an abstraction over the set of bills/coins; wallet software applies the same abstraction when it tells you how much btc you have
519 2014-04-04 17:55:18 <SoftwareMechanic> ya, the wallet software is pretty clear.
520 2014-04-04 17:57:28 <SoftwareMechanic> I wonder how close the current state of bitcoin is to the early monetary policy of a country.