1 2016-02-21 00:00:36 <Luke-Jr> michagogo: that's what I would expect
  2 2016-02-21 06:29:19 <krisives> Hi. Does anyone know of a system like RBF where instead of replacing a tx w/ a fee you can say "dont process this TX until the other one is processed" ?
  3 2016-02-21 07:19:01 <Luke-Jr> krisives: unless you have an output to spend from the other one, it is not presently possible. adding one would be a softfork (and one I plan to propose post-versionbits if nobody beats me to it)
  4 2016-02-21 09:16:16 <krisives> Luke-Jr: you know how miners can currently mine empty blocks? This seems like a way to help solve that / anti censorship
  5 2016-02-21 09:19:31 <krisives> i made a forum post about it https://bitcointalk.org/index.php?topic=1372028.new
  6 2016-02-21 09:20:34 <krisives> Let me know if anyone finds this interesting I like the idea a lot
  7 2016-02-21 09:33:14 <murch> A few comments on your post: RBF affects unconfirmed transactions, it cannot change transactions already included in a block. The concept you are describing already exists. It is called "Child-pays-for-parent" (CPFP). The difference is that CPFP requires you to have two transactions included in blocks, while RBF replaces a transaction with another, i.e. only needs one transaction to work. Since transaction throughput is the issue of our tim
  8 2016-02-21 09:33:23 <murch> krisives: see above.
  9 2016-02-21 09:34:50 <murch> krisives: Also see: https://bitcointalk.org/index.php?topic=1118563.0
 10 2016-02-21 09:36:22 <krisives> Thanks for the link that doesn't meet the critera
 11 2016-02-21 09:36:38 <krisives> It would require the parties to coordinate ahead of time
 12 2016-02-21 09:37:37 <murch> krisives: No. As soon as you create a transaction, the transaction hash and output is known. You can craft another transaction building on an unconfirmed transaction.
 13 2016-02-21 09:37:51 <murch> Did you read my first answer?
 14 2016-02-21 09:38:00 <krisives> specifically CPFP would require spending from the output
 15 2016-02-21 09:38:34 <krisives> in my post I specify I want to be able to do this without coordination of the two parties of the txs
 16 2016-02-21 09:39:26 <krisives> if bitcoin had a way to do this (maybe child pays for parent can do this, i will look more) it could limit the censorship of miners
 17 2016-02-21 09:39:45 <krisives> or at least make it harder to cherry pick transactions and censor them
 18 2016-02-21 09:39:53 <murch> krisives: To quote you "This would be done by making another transaction with a miner fee to incentivize it to be placed into a block."
 19 2016-02-21 09:40:08 <krisives> murch: yes but that tx could be made by someone else
 20 2016-02-21 09:40:21 <krisives> murch: like say i send $1M to Edward Snowden and it refuses to get processed by miners
 21 2016-02-21 09:40:36 <krisives> murch: others could "attach" to it so that their txs dont get processed until mine does
 22 2016-02-21 09:40:45 <murch> krisives: So can CPFP. As soon as a transaction has been broadcasted to the network, others can build on top.
 23 2016-02-21 09:41:02 <krisives> murch: would my edward snowden scenario work?.
 24 2016-02-21 09:41:08 <murch> ah, no, that wouldn't
 25 2016-02-21 09:41:12 <krisives> murch: with CPFP
 26 2016-02-21 09:41:14 <krisives> ah
 27 2016-02-21 09:41:34 <krisives> im mainly interested in the idea that people could vote for other txs they think should be processed
 28 2016-02-21 09:41:36 <murch> krisives: But that really doesn't get clearly communicated by your post
 29 2016-02-21 09:41:39 <krisives> and how this could solve "what is spam"
 30 2016-02-21 09:41:40 <Lightsword> krisives, in regards to that bitcointalk post “In particular, I see the blockchain more as a data structure made up of immutable pieces, and I don't like that RBF violates this to some degree.” this is wrong since RBF is only local policy and has nothing to do with the blockchain
 31 2016-02-21 09:41:56 <krisives> Lightsword: good point i forgot RBF is a mempool
 32 2016-02-21 09:42:07 <krisives> Lightsword: giving RBF that beef was wrong
 33 2016-02-21 09:42:36 <krisives> Lightsword: I still think the blockchain pieces should be as immutable as possible
 34 2016-02-21 09:43:05 <krisives> murch: yes i may not have communicated it well please help me with this if you think its worth it
 35 2016-02-21 09:43:10 <murch> krisives: In other words, you would like to introduce a check that allows a transaction only to be confirmed if a specified other transaction has been confirmed before. I don't think there is a mechanism for that yet.
 36 2016-02-21 09:43:13 <Lightsword> krisives, well that has nothing to do with RBF though
 37 2016-02-21 09:43:47 <krisives> Lightsword: yes i realize dragging RBF in that way may have been wrong, but if this capability existed it would make RBF not needed
 38 2016-02-21 09:44:00 <krisives> Lightsword: either way i was wrong to drag RBF into it to some degree i realize that now
 39 2016-02-21 09:44:01 <murch> krisives: RBF doesn't change anything about the behaviour of the blockchain. It just replaces one unconfirmed transaction with another unconfirmed transaction.
 40 2016-02-21 09:44:23 <Lightsword> krisives, I think RBF would still be needed for other reasons
 41 2016-02-21 09:44:46 <Lightsword> CPFP is also really inefficient
 42 2016-02-21 09:44:52 <murch> krisives: Lightning Network needs some form of RBF, so that payment channel dissolution transactions can be properly updated.
 43 2016-02-21 09:45:01 <krisives> im not against RBF or for it
 44 2016-02-21 09:45:19 <krisives> i just thought the best way to promote the idea i had was to associate it with RBF since people understood that
 45 2016-02-21 09:45:26 <krisives> that was probably a mistake
 46 2016-02-21 09:45:52 <krisives> what im interested in is how this could make miner censorship harder and solve the problem of "what is spam" in bitcoin
 47 2016-02-21 09:46:09 <krisives> because txs would become a kind of web of trust
 48 2016-02-21 09:47:26 <krisives> i dont have it 100% figured out, my first step was to find out if a BIP exists or a process exists of doing this currently
 49 2016-02-21 09:50:49 <murch> krisives: I've asked a question about your idea here: http://bitcoin.stackexchange.com/q/43003/5406
 50 2016-02-21 09:51:09 <krisives> Thanks I was gonna try SE next
 51 2016-02-21 09:51:41 <krisives> you gzipped all the BS i wrote nicely
 52 2016-02-21 09:52:11 <murch> krisives: Thanks. I was just going to ask you whether I got right what you are asking.
 53 2016-02-21 09:53:00 <krisives> if bitcoin never gets a change to allow this (assuming its not possible)
 54 2016-02-21 09:53:23 <murch> krisives: Still, that might help promote the inclusion of the supported transaction, but I don't see why that would change the incentives for miners not to create empty blocks. Can you elaborate what your thought process teher is?
 55 2016-02-21 09:53:51 <krisives> thats exactly what i was going to do =)
 56 2016-02-21 09:54:07 <krisives> there are two scenarios kind of, pre-subsidy and post-subsidy (fee market)
 57 2016-02-21 09:54:12 <krisives> but both are affected
 58 2016-02-21 09:54:32 <krisives> if the subsidy exists we get what we have now
 59 2016-02-21 09:54:40 <krisives> some miners just take the block reward and put 0txs in
 60 2016-02-21 09:55:31 <krisives> it will only incentivize those, and may not solve that because the subsidy
 61 2016-02-21 09:55:41 <murch> krisives: Peter Todd is working on something to disincentivize empty blocks. It would require miners to prove that they have access to a copy of the previous block's data in order to create a new block.
 62 2016-02-21 09:56:19 <krisives> but in a fee market the subsidy is gone, so the miners have to collect the tx fees
 63 2016-02-21 09:56:40 <krisives> if you can attach each tx to another you can create a web where censorship cascades into lost miner fees
 64 2016-02-21 09:57:04 <krisives> aka i attach to all my friends txs and he attaches to all his friends etc.
 65 2016-02-21 09:57:36 <krisives> miner censorship takes many forms
 66 2016-02-21 09:57:56 <krisives> empty blocks, "spam txs", at one point some miners refused to publish satoshi dice txs
 67 2016-02-21 09:58:12 <murch> krisives: I'm just playing the devil's advocate here, but to summarize your proposal: You offer a juicy transaction to confirm a previous transaction. I.e. you up the fee to help a transaction along.
 68 2016-02-21 09:58:31 <krisives> or just your normal tx fees being withheld unless that tx goes through
 69 2016-02-21 09:58:31 <murch> krisives: That's _exactly_ what RBF does.
 70 2016-02-21 09:58:51 <krisives> aka i pay my phone bill but it doesnt go through and the tx fee isnt redeemed until the censored tx goes through
 71 2016-02-21 09:59:15 <krisives> yes but RBF requires you to re-spend YOUR tx
 72 2016-02-21 09:59:58 <krisives> i dont see a way RBF can be turned into a web-of-trust like system to prevent individual txs from being censored
 73 2016-02-21 10:00:16 <murch> krisives: Mh. Okay, I see what you are getting at.
 74 2016-02-21 10:00:26 <krisives> i see how with and without RBF a person could re-send their txs and promote miners with more fees
 75 2016-02-21 10:00:40 <krisives> but miners can just keep rejecting that one guy
 76 2016-02-21 10:01:12 <krisives> again i dont expect everyone to agree 100% with the likliehood of it
 77 2016-02-21 10:01:25 <krisives> but i do think its possible one day if somethings happen we could see censored txs
 78 2016-02-21 10:01:33 <murch> krisives: However, more devil's advocate here: You'd create more meta information about your transactions and your friend's transactions linking you and reducing your privacy. Also, your transaction would be dependent on your friend's transaction for confirmation which would be really inconvenient if you actually need a payment to quickly confirm.
 79 2016-02-21 10:01:58 <krisives> well you wouldnt do it unless you wanted to
 80 2016-02-21 10:02:10 <krisives> in specific if a buddy has a problem with a tx or if a popular tx starts getting censored
 81 2016-02-21 10:02:17 <krisives> or if miners start doing any censorship ppl disagree with
 82 2016-02-21 10:02:53 <krisives> like if tomorrow miners just stopped taking txs from <popular wallet>
 83 2016-02-21 10:02:57 <murch> krisives: Yeah, now that I understood the actual difference, I think it's an interesting idea.
 84 2016-02-21 10:03:54 <murch> krisives: Well, more likely, it would be some _address_ that is censored.
 85 2016-02-21 10:04:02 <murch> Getting some coffee, thinking about it. ;)
 86 2016-02-21 11:45:09 <yuppie> hey guys
 87 2016-02-21 11:45:15 <yuppie> im having an issue getting bitcoin-cli working
 88 2016-02-21 11:50:34 <krisives> yuppie: what system / what is the issue ?
 89 2016-02-21 11:50:43 <krisives> linux, mac, windows ?
 90 2016-02-21 11:50:48 <yuppie> linux
 91 2016-02-21 11:50:51 <krisives> what distro
 92 2016-02-21 11:50:52 <yuppie> centos 7
 93 2016-02-21 11:51:00 <krisives> compile from source
 94 2016-02-21 11:51:01 <krisives> ?
 95 2016-02-21 11:51:05 <yuppie> uh
 96 2016-02-21 11:51:09 <yuppie> rpm install i think
 97 2016-02-21 11:51:11 <krisives> or rpm
 98 2016-02-21 11:51:12 <yuppie> some repo
 99 2016-02-21 11:51:14 <krisives> hmm
100 2016-02-21 11:51:15 <yuppie> rpm
101 2016-02-21 11:51:22 <yuppie> should i delete it and start over? lol
102 2016-02-21 11:51:23 <krisives> what happens if you try to run it ?
103 2016-02-21 11:51:35 <yuppie> Active: active (running) since Sun 2016-02-21 06:48:58 EST; 2min 32s ago
104 2016-02-21 11:52:00 <yuppie> do i need to specify more stuff in my .conf?
105 2016-02-21 11:52:04 <yuppie> im not understanding that
106 2016-02-21 11:52:10 <yuppie> im running bitcoin server
107 2016-02-21 11:52:15 <yuppie> and trying to connect using bitcoin-cli
108 2016-02-21 11:52:27 <krisives> its been a while since i ran it, but you should use RPC
109 2016-02-21 11:52:41 <yuppie> lol ok how
110 2016-02-21 11:52:42 <murch> yuppie: What are you actually trying to do?
111 2016-02-21 11:52:43 <krisives> bitcoin-cli talks to your bitcoind server running via RPC
112 2016-02-21 11:52:52 <yuppie> murch generate some wallet addresses
113 2016-02-21 11:53:02 <krisives> yuppie: one time or programatically ?
114 2016-02-21 11:53:02 <yuppie> ok well the server is running
115 2016-02-21 11:53:07 <krisives> yuppie: try MPK
116 2016-02-21 11:53:28 <krisives> yuppie: download electrum, generate xpub key, then you can generate infinite wallet addresses with that one
117 2016-02-21 11:53:38 <krisives> using PHP, Python, whatever program you want
118 2016-02-21 11:53:46 <yuppie> krisives programmatically eventually
119 2016-02-21 11:53:49 <yuppie> python
120 2016-02-21 11:53:57 <yuppie> but i wanted CLI to work first
121 2016-02-21 11:54:06 <murch> yuppie: http://bitcoin.stackexchange.com/questions/34266/how-to-get-a-wallet-address-and-set-label-via-rpc
122 2016-02-21 11:54:13 <krisives> honestly i suggest not runnning a full stack etc. but you can do it
123 2016-02-21 11:54:25 <yuppie> i dont want to run a full stack really
124 2016-02-21 11:54:45 <yuppie> i think my server just locked up :/
125 2016-02-21 11:54:59 <krisives> if the goal is to generate receiving addreses en-masse you can do that with Master Public Key (MPK) or "HD wallets" as they are called
126 2016-02-21 11:55:20 <krisives> https://github.com/jmcorgan/bip32utils
127 2016-02-21 11:55:27 <murch> yuppie: Is it synchronized already? If it has to still synchronize that might take quite a bit of time and computation.
128 2016-02-21 11:55:31 <krisives> there is a python library that will take your xpub key and let you generate wallet addresses
129 2016-02-21 11:55:51 <yuppie> :/
130 2016-02-21 11:55:51 <yuppie> murch its probably syncing now im guessing
131 2016-02-21 11:55:53 <yuppie> wtffff
132 2016-02-21 11:56:47 <murch> but what krisives suggests seems to be a better solution for your underlying problem. ;)
133 2016-02-21 11:57:17 <krisives> unless you want to send payments running a full node is not needed and i advise against it, with MPK you can take payment directly to cold storage securely
134 2016-02-21 11:57:27 <yuppie> krisives download electrum?
135 2016-02-21 11:57:38 <yuppie> send payments?
136 2016-02-21 11:57:43 <yuppie> i want to send recv btc
137 2016-02-21 11:57:44 <krisives> yes download electrum or use any wallet that generates a xpub key, some web wallets do this
138 2016-02-21 11:57:46 <yuppie> just like a cli wallet
139 2016-02-21 11:58:03 <yuppie> send and recv
140 2016-02-21 11:58:17 <krisives> if you need to have the wallet programmatically send then you need a cli unless you use a third party API
141 2016-02-21 11:58:42 <yuppie> how do i use bitcoin-cli to generate a wallet address?
142 2016-02-21 11:58:43 <krisives> (there are more complicated p2sh and multisig too)
143 2016-02-21 11:59:18 <yuppie> how do i use bitcoin-cli to generate a wallet address? <_<
144 2016-02-21 12:00:11 <krisives> bitcoin-cli getnewaddress
145 2016-02-21 12:00:28 <yuppie> error: incorrect rpcuser or rpcpassword (authorization failed)
146 2016-02-21 12:00:29 <yuppie> :/
147 2016-02-21 12:01:12 <krisives> yes you need to configure your bitcoind and bitcoin-cli to use the same RPC user/pass
148 2016-02-21 12:01:14 <yuppie> the user/pass match with /etc/bitcoin/bitcoin.conf though
149 2016-02-21 12:01:28 <krisives> its possible its loading a different config file
150 2016-02-21 12:01:42 <yuppie> where can i check that? ps aux?
151 2016-02-21 12:01:44 <krisives> also you would have to restart bitcoind
152 2016-02-21 12:01:56 <krisives> if you changed the config files
153 2016-02-21 12:02:00 <yuppie> datadir=/var/lib/bitcoin
154 2016-02-21 12:02:06 <yuppie> conf=/etc/bitcoin/bitcoin.conf
155 2016-02-21 12:02:30 <yuppie> error: {"code":-28,"message":"Loading block index..."}
156 2016-02-21 12:02:40 <krisives> it could be refusing to do RPC while it syncs
157 2016-02-21 12:06:02 <krisives> i am curious once you get a payment into the wallet you are generating what are you going to do with it ?
158 2016-02-21 12:06:18 <yuppie> lol
159 2016-02-21 12:06:21 <yuppie> just mess around
160 2016-02-21 12:06:42 <krisives> well i dont mean what are you going to spend your coins on lol
161 2016-02-21 12:06:55 <krisives> im just saying unless you have a need to fire a script that then spends some coins
162 2016-02-21 12:07:01 <krisives> you probably dont need bitcoind / bitcoin-cli
163 2016-02-21 12:08:07 <krisives> but if the goal is to learn how to use bitcoin tinker away
164 2016-02-21 12:08:26 <yuppie> error: no response from server
165 2016-02-21 12:08:46 <krisives> is bitcoind running ?
166 2016-02-21 12:08:48 <yuppie> yes
167 2016-02-21 12:09:28 <krisives> my advice is check the log with tail
168 2016-02-21 12:09:46 <krisives> tail /var/log/bitcoin*/log ?
169 2016-02-21 12:10:07 <krisives> log locations vary =(
170 2016-02-21 12:10:07 <yuppie> nothing there
171 2016-02-21 12:10:28 <yuppie> 2016-02-21 12:10:20 UpdateTip: new best=000000000000016fd5f7dd11c65a8119055360546b40ca72f42fad8c6da70164  height=
172 2016-02-21 12:10:29 <yuppie> 215594  log2_work=69.260777  tx=10837061  date=2013-01-07 17:01:03 progress=0.044907  cache=45.4MiB(71755tx)
173 2016-02-21 12:10:35 <yuppie> its /var/lib/bitcoin
174 2016-02-21 12:10:39 <krisives> it dpeends on how the package / proram was installed
175 2016-02-21 12:11:02 <krisives> you have about 3 more years of syncing
176 2016-02-21 12:11:05 <krisives> to go
177 2016-02-21 12:11:08 <krisives> ~_~
178 2016-02-21 12:11:30 <yuppie> kek
179 2016-02-21 12:11:41 <krisives> not sure how long it will take
180 2016-02-21 12:11:43 <yuppie> is that why it refuses to generate an address?
181 2016-02-21 12:11:50 <krisives> most likely yes
182 2016-02-21 12:12:09 <krisives> im not 100% sure but i think while its starting RPC isnt ready
183 2016-02-21 12:12:21 <krisives> its part of the init sequence
184 2016-02-21 12:12:38 <yuppie> damn this log file is moving
185 2016-02-21 12:12:40 <yuppie> but still on 2013
186 2016-02-21 12:13:02 <krisives> https://github.com/bitcoinclassic/bitcoinclassic/blob/0.11.2/src/init.cpp#L1118
187 2016-02-21 12:13:14 <yuppie> lol
188 2016-02-21 12:14:02 <krisives> it looks like its going to load those blocks first then wallet gets initialized, and the RPC is either not running yet or at least cant touch wallets yet because they arent loaded is my guess
189 2016-02-21 12:14:07 <yuppie> one guy is saying it takes aweek lol
190 2016-02-21 12:14:16 <yuppie> yeah
191 2016-02-21 12:14:27 <krisives> it depends on IO performance and network
192 2016-02-21 12:14:43 <krisives> is it running on a box you control or cloud ?
193 2016-02-21 12:15:02 <murch> yuppie: Depends on your hardware. Are you running 0.11.2 or 0.12.0?
194 2016-02-21 12:15:40 <yuppie> cloud
195 2016-02-21 12:15:41 <murch> The latter is much faster at synchronizing, x5 or x7 depending on what hardware you're running.
196 2016-02-21 12:15:53 <yuppie> murch how can i check the version?
197 2016-02-21 12:16:23 <yuppie> Bitcoin Core Daemon version v0.11.2.0-g7e27892
198 2016-02-21 12:16:29 <yuppie> where can i get 12?
199 2016-02-21 12:17:11 <krisives> bitcoin.org but ur running an rpm version right now so if you compile from source etc. you want to remove that first
200 2016-02-21 12:17:14 <yuppie> https://en.bitcoin.it/wiki/Bitcoind#Running
201 2016-02-21 12:17:20 <krisives> or find a newer rpm repo
202 2016-02-21 12:18:06 <yuppie> maybe i should use ubuntu instead too huh
203 2016-02-21 12:18:17 <yuppie> what do you think?
204 2016-02-21 12:18:19 <yuppie> doesn't matter?
205 2016-02-21 12:19:24 <krisives> it depends entirely on package managers
206 2016-02-21 12:19:36 <krisives> unless you want to extract it yourself and run it manually
207 2016-02-21 12:19:51 <krisives> the only problem is then you don't get service wrappers for /etc/init.d setup automatically for you etc.
208 2016-02-21 12:20:01 <yuppie> how do i install it from source?
209 2016-02-21 12:20:12 <krisives> you can download source or bin for linux32/64
210 2016-02-21 12:20:14 <krisives> i just checked
211 2016-02-21 12:20:21 <krisives> https://bitcoin.org/bin/bitcoin-core-0.11.2/
212 2016-02-21 12:20:46 <yuppie> https://www.ringingliberty.com/bitcoin/
213 2016-02-21 12:20:51 <yuppie> i want 12 though krisives
214 2016-02-21 12:21:01 <krisives> https://bitcoin.org/bin/bitcoin-core-0.12.0/
215 2016-02-21 12:21:01 <krisives> sorry pasted wrong link
216 2016-02-21 12:22:02 <yuppie> testrc3?
217 2016-02-21 12:22:36 <krisives> the link you gave doesnt seem to have 12.0 they have 11.2
218 2016-02-21 12:23:58 <yuppie> right
219 2016-02-21 12:23:59 <yuppie> well
220 2016-02-21 12:24:02 <yuppie> i downloaed 12
221 2016-02-21 12:24:05 <yuppie> how do i install it now?
222 2016-02-21 12:24:11 <yuppie> just run it manually? lol
223 2016-02-21 12:43:42 <aschildbach> Hi there, I've got a question about the Version, VersionAck handshake at the beginning of a P2P connection. Are the two directions of the handshake supposed to run in parallel, or is it ok for the node that was accepting the connection to defer his Version message until he sent his VersionAck (in response to the Version of the connecting node)?
224 2016-02-21 15:32:51 <JWU42> any timeframe on 0.12 going "live"?
225 2016-02-21 15:33:10 <JWU42> I see rc3 was released just over 2 weeks ago...
226 2016-02-21 15:33:27 <JWU42> ahh - rc5 on the 15th
227 2016-02-21 15:34:52 <paveljanik> tomorrow...
228 2016-02-21 15:37:26 <JWU42> paveljanik: thanks
229 2016-02-21 15:41:42 <buZz> any ops of #bitcoin awake? :/
230 2016-02-21 15:41:52 <buZz> realsolid is in there, pushing his latest scams
231 2016-02-21 15:42:34 <JWU42> hmm
232 2016-02-21 15:42:42 <JWU42> make fails - no makefile found
233 2016-02-21 15:47:40 <JWU42> no libevent installed on that box :/
234 2016-02-21 19:26:33 <JWU42> syncing with 0.12 versus 0.11.2 - much quicker
235 2016-02-21 19:26:43 <JWU42> good work gents
236 2016-02-21 19:37:49 <michagogo> JWU42 paveljanik: basically, 0.12 is tagged final, identical to rc5 (with a couple release note tweaks). Binaries have been built, too. The "official" release is waiting on cfields, who's in Hong Kong until Monday, because he's the one that does the codesigning for Windows and OS X. So I'd expect the release on Tuesday or Wednesday, most likely.
237 2016-02-21 19:38:24 <JWU42> michagogo: appreciate you following up on the question
238 2016-02-21 19:40:02 <michagogo> JWU42: so yeah, if you want to build your own binaries you can
239 2016-02-21 19:40:24 <michagogo> And you could probably just use rc5 for now, it's identical
240 2016-02-21 19:49:28 <JWU42> yep - have done so on 3 boxes so far - all good
241 2016-02-21 19:49:40 <JWU42> only minor issues was the need to install libevent
242 2016-02-21 19:56:30 <paveljanik> JWU42, what OS? Please check git grep libevent | grep ^doc ;-)
243 2016-02-21 19:58:22 <JWU42> paveljanik: configure would error out about libevent on a 14.04 and jessie box
244 2016-02-21 19:58:32 <JWU42> installed libevent-dev and now both work
245 2016-02-21 19:58:56 <JWU42> so maybe there was another dep pulled in by installing libevent-dev
246 2016-02-21 20:00:06 <paveljanik> JWU42, yes, as documented: doc/build-unix.md:    sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils
247 2016-02-21 20:01:17 <JWU42> got it
248 2016-02-21 20:01:36 <JWU42> that was new since 0.11.2 and a quick scan through the release notes didn't fine anything
249 2016-02-21 20:01:55 <JWU42> but yes - check the build-unix next time
250 2016-02-21 20:02:13 <paveljanik> :-)
251 2016-02-21 20:02:21 <paveljanik> but anyway, doog that it works.
252 2016-02-21 20:02:25 <paveljanik> good
253 2016-02-21 22:28:47 <krisives> tempted to poke around more with the idea of attaching txs to another
254 2016-02-21 22:29:06 <krisives> probably will never see a dime from any of that though will work on paid work instead
255 2016-02-21 22:29:26 <krisives> i made a forum post did what i could https://bitcointalk.org/index.php?topic=1372028
256 2016-02-21 22:29:30 <krisives> take care good luck guys