1 2015-02-22 00:14:47 <TwinWinNerD> Hey guys. Can someone please tell me who I need to contact for the Bitcoin wiki?
  2 2015-02-22 00:18:30 <netg2> write in bitcoin talk subforum
  3 2015-02-22 00:19:33 <Luke-Jr> TwinWinNerD: #bitcoin-wiki
  4 2015-02-22 00:20:22 <TwinWinNerD> Luke-Jr: Thanks. I really need to edit the german wiki. The instructions to buying coins from MTgox is a bit missleading ;)
  5 2015-02-22 00:20:43 <netg2> german section cant be editeed
  6 2015-02-22 00:20:49 <netg2> many community members tried
  7 2015-02-22 00:20:59 <netg2> no one got access
  8 2015-02-22 00:21:06 <Luke-Jr> please move this discussion to #bitcoin-wiki :/
  9 2015-02-22 01:48:42 <robbak> Just found a bug - the tests always fail with --without-utils. The tests seem to be trying to test them even if you don't build them.
 10 2015-02-22 04:20:50 <petertodd> Luke-Jr: my rbf patch doesn't attempt to implement fully cpfp - it evaluates all replaced fees/size including children, but doesn't change the relaying logic. As it turns out scorched earth is better done without cpfp, so I'm leaving that out.
 11 2015-02-22 04:21:38 <Luke-Jr> I don't follow. How do you include children without it being cpfp?
 12 2015-02-22 04:22:22 <petertodd> Luke-Jr: Bitcoin XT's double-spend relaying code does roughly the same thing as RBF, so it'll definitely remain a conflict. However the non-relaying part of it - the wallet changes - could potentially be rebased on top of RBF. I don't have any particular plans to do that though - would prefer not to have such a niche configuration shipping in the wild for lack of testing concerns.
 13 2015-02-22 04:22:51 <Luke-Jr> ok
 14 2015-02-22 04:22:52 <petertodd> Luke-Jr: children are included in the "should I replace or not?" calculation, however you'll always replace one-or-more transactions with a single transaction, not more than one transaction
 15 2015-02-22 04:23:32 <Luke-Jr> hm
 16 2015-02-22 04:23:44 <Luke-Jr> makes sense I suppose
 17 2015-02-22 04:25:09 <petertodd> Luke-Jr: yup. Thing is, the CPFP version of scorched earth is dangerous, as standard wallets aren't actually all that good at not accidentally double-spending, so I think we're better off making that something people opt-into via a payment protocol using the SIGHASH_ANYONECANPAY version of scorched earth.
 18 2015-02-22 04:26:36 <Luke-Jr> petertodd: eh, I was thinking if a double-spender pays another merchant with the coins, and that merchant sees the first one do SE, and therefore decides to do SE himself, causing a possible gain for the bad guy
 19 2015-02-22 04:26:37 <petertodd> Luke-Jr: for instance with coinjoin you can't guarantee a lack of double-spends directly, so promoting CPFP replace-by-fee now would limit coinjoin use in the future
 20 2015-02-22 04:26:43 <Luke-Jr> (have not fully thought this through)
 21 2015-02-22 04:27:21 <petertodd> Luke-Jr: that's exactly the kind of reason why naively jumping into SE is a bad idea ;)
 22 2015-02-22 05:36:24 <wallbroken> hi
 23 2015-02-22 05:36:32 <wallbroken> how to fix assertion failed error?
 24 2015-02-22 05:36:49 <wallbroken> hashPrevBlock == view.GetBestBlock()'
 25 2015-02-22 05:36:55 <wallbroken> then it crashes
 26 2015-02-22 05:39:56 <justanotheruser> wallbroken: do you have any blocks?
 27 2015-02-22 05:42:27 <wallbroken> justanotheruser, 25 gb of blocks
 28 2015-02-22 05:42:30 <wallbroken> 22 weeks left
 29 2015-02-22 05:42:47 <wallbroken> i'm running bitcoin core since 9 days
 30 2015-02-22 05:43:07 <wallbroken> now i'm at half, but now is continually crashing with that error
 31 2015-02-22 05:43:23 <wallbroken> is the fourth time in a day
 32 2015-02-22 05:43:57 <wallbroken> https://www.dropbox.com/s/ed1x3x5j6u99wzi/Immagine.JPG?dl=0
 33 2015-02-22 05:43:59 <wallbroken> here it is
 34 2015-02-22 05:45:56 <Luke-Jr> bad RAM?
 35 2015-02-22 05:46:18 <justanotheruser> Just in case debug.log says something interesting you could post that
 36 2015-02-22 05:46:29 <wallbroken> let me check
 37 2015-02-22 05:48:09 <justanotheruser> I don't know of anything interesting it might say though
 38 2015-02-22 05:48:14 <wallbroken> http://pastebin.com/0gxdnbrX
 39 2015-02-22 05:48:26 <wallbroken> could this be usefull?
 40 2015-02-22 05:48:53 <wallbroken> is the first time that you heard about that error?
 41 2015-02-22 05:50:38 <justanotheruser> no, but it is the first time I've heard the error from someone not trying to make an altcoin
 42 2015-02-22 05:51:18 <justanotheruser> std::bad_alloc might be a hardware issue?
 43 2015-02-22 05:51:22 <wallbroken> i just started bitcoin core
 44 2015-02-22 05:51:29 <wallbroken> i don't know
 45 2015-02-22 05:51:44 <justanotheruser> is it always the same block that you get it on?
 46 2015-02-22 05:52:00 <Luke-Jr> std::bad_alloc suggests a VPS with too little RAM
 47 2015-02-22 05:52:15 <justanotheruser> either that or a bug
 48 2015-02-22 05:52:28 <phantomcircuit> Luke-Jr, it can also be from bad ram causing the length of a field to be infinity
 49 2015-02-22 05:52:50 <Luke-Jr> ofc
 50 2015-02-22 05:52:52 <Luke-Jr> I said that first..
 51 2015-02-22 05:53:05 <phantomcircuit> i know
 52 2015-02-22 05:53:05 <wallbroken> 4 gb of ram
 53 2015-02-22 05:53:10 <wallbroken> 32 bit system
 54 2015-02-22 05:53:51 <wallbroken> ops, 3 gb, not 4
 55 2015-02-22 05:54:02 <phantomcircuit> something went wrong and it appears to be bad ram
 56 2015-02-22 05:54:16 <wallbroken> in the sense of damaged ram?
 57 2015-02-22 05:54:25 <phantomcircuit> yes
 58 2015-02-22 05:54:33 <phantomcircuit> im not sure how you could trigger that otherwise
 59 2015-02-22 05:54:34 <wallbroken> i can do a memtest
 60 2015-02-22 05:54:50 <phantomcircuit> that might not matter if it's a vps
 61 2015-02-22 05:55:02 <phantomcircuit> you cant test all the ram on the system just the portion which you've been allocated
 62 2015-02-22 05:55:05 <phantomcircuit> which probably changes
 63 2015-02-22 05:55:07 <phantomcircuit> fun
 64 2015-02-22 05:55:28 <justanotheruser> phantomcircuit: shouldn't a VPS do regular memtests so you don't have this problem?
 65 2015-02-22 05:56:45 <wallbroken> the fact is that in the first days all went good
 66 2015-02-22 05:56:46 <phantomcircuit> justanotheruser, lol
 67 2015-02-22 05:56:54 <wallbroken> the problem is in these last days
 68 2015-02-22 05:56:55 <phantomcircuit> justanotheruser, they might not even have ecc dude
 69 2015-02-22 05:57:15 <wallbroken> if there was a memory fail, why this not happened since the beginning?
 70 2015-02-22 05:58:15 <Luke-Jr> [05:56:23] <justanotheruser> phantomcircuit: shouldn't a VPS do regular memtests so you don't have this problem? <-- ROFL
 71 2015-02-22 05:59:18 <justanotheruser> I don't know how they operate, but given a memory problem I can never predict would piss me off to no bounds, so I at least hoped they did
 72 2015-02-22 06:02:00 <phantomcircuit> justanotheruser, most vps providers dont even have an SLA
 73 2015-02-22 06:02:05 <phantomcircuit> for example
 74 2015-02-22 06:02:16 <phantomcircuit> with momentovps the best you could get is credits for more service
 75 2015-02-22 06:02:20 <phantomcircuit> why?
 76 2015-02-22 06:02:25 <phantomcircuit> because the profit margin is like
 77 2015-02-22 06:02:27 <phantomcircuit> zero
 78 2015-02-22 06:04:36 <justanotheruser> I just googled momentovps and the first result was some bitcointalk thread asking for police reports involving you
 79 2015-02-22 06:05:32 <justanotheruser> oh ok, this is some bitcoinica drama
 80 2015-02-22 06:07:39 <Luke-Jr> "the guy is never on IRC" lol
 81 2015-02-22 06:14:14 <phantomcircuit> justanotheruser, my favorite is the guy asking for like $4k in compensation for $4 in vps services
 82 2015-02-22 06:14:19 <phantomcircuit> which were actually provided
 83 2015-02-22 07:18:57 <wallbroken> i
 84 2015-02-22 07:19:07 <wallbroken> i done a memtest
 85 2015-02-22 07:19:19 <wallbroken> and no errors are found
 86 2015-02-22 07:30:38 <ciemon> Luke-Jr: Thanks for the direction on my PR... it's way outside my area of knowledge but I'll give it a go.
 87 2015-02-22 09:17:49 <rubberduck> Good Morning Everyone
 88 2015-02-22 09:18:08 <rubberduck> I have a feature-Request fot the bitcoin-core client.
 89 2015-02-22 09:19:22 <rubberduck> When i start it then incoming connections work but when my provider changes my wan-ip incoming connections stop working. The Client needs a mechanism to detect the wan-ip-change an update it's public ip in the peer-to-peer network so that incoming is possible after reconnection again.
 90 2015-02-22 09:20:56 <rubberduck> Also Ipv6 should be enforced as i have static ip's on ipv6 but dynamically changing on ipv4
 91 2015-02-22 10:02:50 <wumpus> there is no reason why incoming connections would no longer work after an IP change, it's still bound to the same port, of course other peers may not be able to find you immediately
 92 2015-02-22 10:04:12 <wumpus> (but as I understand it, that's a matter of time, as you connect to other nodes your node learns its new IP and advertises that)
 93 2015-02-22 10:05:47 <gmaxwell> rubberduck: it works fine as far as I know (and have tested). It does take some time before other peers learn about your IP and bother connecting, but there is nothing wrong or surprising about that.
 94 2015-02-22 10:06:14 <wumpus> 'ipv6 should be enforced', how do you see that, worldwide ipv6 adoption at gunpoint?
 95 2015-02-22 10:07:30 <wumpus> if your goal is to force bitcoind to ipv6 only, you could use -onlynet=ipv6
 96 2015-02-22 10:15:54 <ciemon> A question on this project's github "procedure". Do devs expect ack of comments, or is implementation of comments enough?
 97 2015-02-22 10:17:21 <rubberduck> gmaxwell: i have no incoming v4 for around 7 Hours after reconnect
 98 2015-02-22 10:18:12 <rubberduck> wumpus: there are rare ipv6 bitcoin connections - as incoming/outgoing works better for ipv6 because of no nat necessary this should be a goal.
 99 2015-02-22 10:19:30 <wumpus> rubberduck: i think you're kind of preaching to the choir there
100 2015-02-22 10:19:41 <rubberduck> wumpus: what???
101 2015-02-22 10:19:47 <gmaxwell> rubberduck: It can often take >24 hours to get a non-trivial number of incoming connections normally.
102 2015-02-22 10:19:55 <wumpus> rubberduck: re: ipv6 adoption
103 2015-02-22 10:20:19 <rubberduck> wumpus: what?
104 2015-02-22 10:20:31 <rubberduck> gmaxwell: doesn't work here, ok?
105 2015-02-22 10:20:49 <wumpus> ciemon: I can't parse that
106 2015-02-22 10:21:29 <wumpus> ciemon: which pull is this about?
107 2015-02-22 10:22:45 <gmaxwell> rubberduck: So you've waited a couple days and still see no connections then?  What version are you running?
108 2015-02-22 10:23:12 <rubberduck> gmaxwell: i have a new public ipv4 every 24 Hours as this is usual in Germany
109 2015-02-22 10:23:20 <ciemon> wumpus: #5809 https://github.com/bitcoin/bitcoin/pull/5809
110 2015-02-22 10:23:24 <rubberduck> 0.10.0
111 2015-02-22 10:24:16 <ciemon> wumpus: I've made the changes, but wanted to make sure that those that have commented aren't/wouldn't be waiting for a response to comments
112 2015-02-22 10:24:21 <gmaxwell> rubberduck: Address propagation is non-eager enough in Bitcoin that you will likely never have many inbound connections with address changes that frequently.
113 2015-02-22 10:24:29 <wumpus> rubberduck: in that case it is pointless to even accept incoming connections on ipv4, that P2P/address gossip system assumes semi-static IPs
114 2015-02-22 10:24:35 <rubberduck> when i start my client the first time after booting first incomming ipv4 appear after 10 minutes.
115 2015-02-22 10:25:03 <wumpus> rubberduck: in any case you're no worse off without incoming connections, or only incoming connections on ipv6
116 2015-02-22 10:25:40 <rubberduck> but bitcoin needs incoming - outgoing-only is not possible für p2p, right?
117 2015-02-22 10:25:53 <rubberduck> i don't want to be a 'leecher-only'
118 2015-02-22 10:26:04 <gmaxwell> rubberduck: yes, because it does an initial push update, but after that it will not attempt again for 24 hours, except when you get different outbound peers and thats only trickled to avoid spamming the addr broadcasts up.
119 2015-02-22 10:26:29 <rubberduck> gmaxwell: ok - thankyou
120 2015-02-22 10:26:45 <gmaxwell> rubberduck: the protocol is symmetrical the only thing an 'inbound' only peer is different in terms of is adding more inbound sockets to the network, which your dynamic IP is not very useful for in any case.
121 2015-02-22 10:28:02 <rubberduck> gmaxwell: ok - i'm using ipv6 for incoming - that's stable.
122 2015-02-22 10:29:15 <wumpus> rubberduck: you could still run a tor hidden service node
123 2015-02-22 10:29:37 <rubberduck> not really interested in tor-hidden-services
124 2015-02-22 10:29:54 <wumpus> hidden services are a good way to remain connectable given unstable ips
125 2015-02-22 10:30:08 <gmaxwell> rubberduck: other bitcoin nodes with IPv6 will happily connect to you via that, there just aren't that many of them.
126 2015-02-22 10:31:16 <wumpus> rubberduck: well the other option wouldb e to switch ISP to one that does offers a stable ipv4 address
127 2015-02-22 10:31:41 <wumpus> or some other VPN based construction
128 2015-02-22 10:32:18 <rubberduck> wumpus: i'd need my client on one of my root-servers but i'd need something like headless-mode for that - as i don't like the commandline-interface something like quassel-core/quassel-client does for IRC
129 2015-02-22 10:32:20 <wumpus> ssh tunnels work too but are suboptimal, as bitcoind will think all connections come from 127.0.0.1
130 2015-02-22 10:33:11 <rubberduck> i could do some policy based routing and route all my port 8333 traffic via my rootie via vpn?
131 2015-02-22 10:33:41 <wumpus> yes, for example
132 2015-02-22 10:34:47 <rubberduck> what port is used for advertising the ip as this also has to be policy-routed via the vpn?
133 2015-02-22 10:34:51 <wumpus> make bitcoind listen on the VPN interface
134 2015-02-22 10:35:19 <wumpus> advertising addreses happens through the P2P protocol
135 2015-02-22 10:35:32 <rubberduck> vpn is terminated on a seperate router - a pcengines APU
136 2015-02-22 10:35:42 <wumpus> in any case, let's move this to #bitcoin, it has nothing to do with development
137 2015-02-22 10:36:56 <rubberduck> ok
138 2015-02-22 10:38:11 <wumpus> ciemon: maybe change "+\fB\-?\fR +This help message" in the manpage to "Show the help message"
139 2015-02-22 10:38:33 <wumpus> ciemon: apart from the the manpage looks good to me, as far as I get manpage syntax
140 2015-02-22 10:41:21 <wumpus> ciemon: also why is -? under SSL options
141 2015-02-22 10:41:46 <wumpus> (just checked using man ./bitcoin-cli.1)
142 2015-02-22 10:42:46 <wumpus> you could remove the "SSL options" header completely, it only has one option in it so grouping it doesn't add anything
143 2015-02-22 11:00:29 <ciemon> wumpus: thanks for all of that.
144 2015-02-22 11:25:17 <wallbroken> another crash...
145 2015-02-22 11:25:28 <wallbroken> looks like impossible to complete
146 2015-02-22 11:25:51 <Diablo-D3> https://developer.apple.com/news/?id=02202015a
147 2015-02-22 11:25:56 <Diablo-D3> this will not end well
148 2015-02-22 11:48:31 <wumpus> apple breaking compatibility again, news at 11
149 2015-02-22 11:50:57 <Diablo-D3> best news Ive herd
150 2015-02-22 11:51:12 <Diablo-D3> office on osx not only uses GC, but is still a 32 bit app
151 2015-02-22 14:41:27 <gdistasi> hi
152 2015-02-22 15:56:59 <whaack> petertodd: thank you for making replace-by-fee I don't know why everyone is crying about it
153 2015-02-22 15:57:49 <petertodd> whaack: thanks!
154 2015-02-22 15:58:20 <whaack> and thank you in general for pushing for the correct although unpopular ideas
155 2015-02-22 15:59:27 <petertodd> whaack: ...and thanks to everyone else for doing the much less interesting (to me!) work of pushing correct and not-unpopular ideas :)
156 2015-02-22 16:01:04 <whaack> petertodd: do you envision the blockchain being an "interbank" settlement system in the future? This is the vision I have for bitcoin that a lot of people really don't like
157 2015-02-22 16:01:47 <petertodd> whaack: that's basically 100% guaranteed if it's going to stay decentralized with the current architecture - global consensus just doesn't scale
158 2015-02-22 16:02:16 <petertodd> whaack: that said, there's other potential architectures you can use - it's an enormouse design space, filled with fun tradeoffs to argue about :P
159 2015-02-22 16:02:40 <whaack> petertodd: That's exactly how I believe. Like - even if everyone WANTED it to be this huge global consesus mechanism I don't think it would even be possible
160 2015-02-22 16:02:42 <kanzure> "global consensus just doesn't scale" or rather, i would argue that instant global consenuss has no meaning
161 2015-02-22 16:02:56 <kanzure> *consensus
162 2015-02-22 16:03:26 <petertodd> kanzure: it's *both* a time and space issue
163 2015-02-22 16:03:32 <sipa> whaack: scalable global consensus is trivial; it's called paxos :)
164 2015-02-22 16:03:39 <kanzure> time? i can't go back there.
165 2015-02-22 16:04:11 <whaack> petertodd: but bitcoin being an interbank settlement system is still a massive, massive step forward for society. Anyone who accumulates enough capital can become their own bank, there will be so much more competition so we'll probably still get instant and free microtransactions (like changetip)
166 2015-02-22 16:04:14 <petertodd> kanzure: instant global consensus is prohibited by the speed of light; global consensus over every participants "everything" has O(n^2) scaling and falls over eventually
167 2015-02-22 16:04:54 <sipa> well, the problem with the "interbank settlement" view is that it doesn't fit any interesting use case
168 2015-02-22 16:05:00 <sipa> banks don't need trustless systems to settle
169 2015-02-22 16:05:04 <petertodd> whaack: yup, and I'm convinced that so long as we don't do anything stupid eventually the debate over what's the 'right' blocksize will be meaningless, because the blockchain won't be structured as a monolith anymore
170 2015-02-22 16:05:24 <kanzure> sipa: banks are usually in various jurisdictions that have different regulations due to competing nations, so there's definitely problems they run into
171 2015-02-22 16:05:41 <sipa> let me rephrase
172 2015-02-22 16:05:56 <petertodd> sipa: you'd be surprised about that... most of the cost in interbank settlement on a *global* scale ends up involving issues of trust
173 2015-02-22 16:06:18 <whaack> sipa: but the blockchain allows the people to audit their banks by forcing the banks to provide a proof of some reserve > their amount
174 2015-02-22 16:06:21 <sipa> i think the most interesting future is one which is somewhere between interbank settlement and micropayment-for-every-coffee
175 2015-02-22 16:06:22 <petertodd> sipa: equally, blockchain supports banks w/o trust between each other, with is a huge step forward given we already know how to have banks without trusting them using crypto
176 2015-02-22 16:06:37 <sipa> where that is exactly is up to the future users of the system
177 2015-02-22 16:06:56 <kanzure> sipa: i think that a micropayment for every coffee can happen, but i don't have any evidence that bitcoin is a good idea for that
178 2015-02-22 16:07:03 <rubberduck> wumpus: gmaxwell: thank you for your help with ipv6
179 2015-02-22 16:07:15 <petertodd> sipa: modulo stuff like jdillon's voting proposal, there's no reasonable way for the future users of the system to come to agreement about that tradeoff
180 2015-02-22 16:07:35 <sipa> petertodd: tough luck, i have no solution either
181 2015-02-22 16:07:47 <kanzure> there's also an amusing aspect to it.. all this work for coffee transactions? :)
182 2015-02-22 16:07:55 <petertodd> kanzure: something bitcoin people often miss is that in 99% of situations no-one gives a shit that you involved trust
183 2015-02-22 16:08:33 <petertodd> kanzure: e.g. "we'll put airmiles on the blockchain!" proposals are bonkers - airmiles systems already get away with horrendous fraud on the part of the people holding the ledgers, and 99% of their customers don't care
184 2015-02-22 16:08:35 <kanzure> yesterday in -wizards i proposed a question regarding physical limits to the number of financial transactions in a healthy civilization (with no answers)
185 2015-02-22 16:08:37 <whaack> I also in general don't think people should have to worry about defending a private key. Most people will not want that responsibility
186 2015-02-22 16:08:48 <kanzure> so how many coffee transactions per second is too many? a trillion? a hundred trillion?
187 2015-02-22 16:09:07 <petertodd> sipa: which gives us the status quo where we solve the problem with incremental technical improvements that don't require consensus - great!
188 2015-02-22 16:09:24 <kanzure> at some point the design costs of supporting a micropayment system like that are going to be dramatically higher than the costs of simply settling multiple transactions at once in larger bundles
189 2015-02-22 16:09:41 <petertodd> kanzure: "Once we build the Grand Ultra Ring Connector Highway our traffic problems will be solved!"
190 2015-02-22 16:10:00 <kanzure> i am not familiar with this. are traffic planners that bad?
191 2015-02-22 16:10:08 <sipa> The solution is obvious though. All humans should live within the same nanometer cube.
192 2015-02-22 16:10:26 <kanzure> sipa: computronium can theoretically support that, but the implementation is presently lacking
193 2015-02-22 16:10:27 <petertodd> kanzure: it's pretty much a known fact that no matter how many roads you build, traffic will always be bad
194 2015-02-22 16:10:42 <kanzure> petertodd: do subways help
195 2015-02-22 16:11:02 <sipa> i want superways
196 2015-02-22 16:11:09 <petertodd> kanzure: similarly there's probably infinite demand for a magic trustworthy ledger
197 2015-02-22 16:11:17 <kanzure> i want catapaults sponsored by the government but nobody listens
198 2015-02-22 16:11:31 <petertodd> kanzure: yes, because it lets you introduce tolls while still having options for poor people
199 2015-02-22 16:12:00 <kanzure> hmm your infinite demand is a good point,
200 2015-02-22 16:12:08 <sipa> In other news, GCC can apparently optimize some byte-swapping workaround code in C to a bswap instruction.
201 2015-02-22 16:12:28 <kanzure> -,
202 2015-02-22 16:12:38 <petertodd> kanzure: it's always eye-opening to talk to banks about this stuff - "Oh, you mean we could secure our audits in the blockchain?! How much? We cay pay $50/tx no problem."
203 2015-02-22 16:13:03 <kanzure> petertodd: are they at all worried abut the other side of the audits? e.g. the non-blockchain-intersecting parts. do they care?
204 2015-02-22 16:13:26 <petertodd> kanzure: nah, this is even more boring: just proving that they're keeping one and only one set of books
205 2015-02-22 16:17:30 <kanzure> here's an idea.. what about a coffee subscription instead of paying every time? that would eliminate the requirement for zeroconf or whatever.
206 2015-02-22 16:17:48 <petertodd> kanzure: payment channel
207 2015-02-22 16:18:42 <kanzure> my way has the advantage of not requiring a transaction per coffee
208 2015-02-22 16:18:57 <petertodd> kanzure: payment channels aren't a transaction per coffee
209 2015-02-22 16:19:03 <whaack> Why not just use a centralized solution? Right now the world has it backwards. We have hard-to-cheat micropayments (cash) and easy-to-cheat macropayments (bank wires)
210 2015-02-22 16:19:05 <kanzure> huh? i thought you sign a transaction and give it to the other side?
211 2015-02-22 16:19:53 <petertodd> kanzure: yeah, and then you sign another one, which *replaces* the previous one - only when the channel is closed do any of those transactions end up getting broadcast
212 2015-02-22 16:20:15 <kanzure> why should i prefer that over paying upfront for a month of coffee?
213 2015-02-22 16:20:37 <sipa> kanzure: payment channels create a transaction per payment, but only the final one hits the blockchain
214 2015-02-22 16:20:37 <whaack> kanzure: maybe you're not sure you want all the coffee
215 2015-02-22 16:20:40 <petertodd> kanzure: because you don't have to actually pay upfront - you just reserve some money and are guarnateed to get the unused funds back
216 2015-02-22 16:20:57 <sipa> kanzure: you're renegotiating the same transaction over and over, increasing the amount paid
217 2015-02-22 16:21:02 <kanzure> sipa: right, i understand that
218 2015-02-22 16:21:19 <kanzure> please note none of my statements violated that
219 2015-02-22 16:21:54 <sipa> i for one would not object to a coffee subscription, but i'm not sure how viable that is economically
220 2015-02-22 16:22:31 <kanzure> haha you could argue that starbucks would save money by not spending time swiping cards when processing their lines of customers
221 2015-02-22 16:22:55 <sipa> they'll still have to swipe your subscription card :p
222 2015-02-22 16:22:56 <petertodd> kanzure: not gonna happen; centrally managed schemes are zillions of times more efficient
223 2015-02-22 16:23:19 <kanzure> petertodd: hm? i mean eliminating the physical time spent swiping cards.
224 2015-02-22 16:23:33 <kanzure> as a way to show the viability of subscriptions
225 2015-02-22 16:23:37 <petertodd> kanzure: yeah, and eliminating that doesn't require bitcoin
226 2015-02-22 16:23:42 <kanzure> correct
227 2015-02-22 16:24:48 <kanzure> maybe there's some sort of natural incentive that could be introduced to promote settlements or clumps of transactions compressed into one.
228 2015-02-22 16:25:08 <petertodd> even just applying crypto auditing techniques to retail transactions is probably going to mostly go nowhere - getting bitcoin adoption beyond enthusists is mostly hopeless
229 2015-02-22 16:25:12 <kanzure> (without requiring many consenting parties)
230 2015-02-22 16:25:15 <petertodd> kanzure: like... tx fees?
231 2015-02-22 16:25:36 <kanzure> transaction fees are an incentive for that, but they do not allow you to arbitrarily settle things that cancel each other out
232 2015-02-22 16:26:00 <petertodd> kanzure: huh? tx fees are an incentive *in general* to build better systems
233 2015-02-22 16:26:13 <kanzure> for example, if you wanted to reduce 10,000 transactions into a single tiny transaction that ultimately amounts to "A -> B", you would have to communicate with the participants of the 10k transactions, which is not something that transaction fees cover.
234 2015-02-22 16:26:27 <petertodd> equally, tx fees are often low enough that no-one cares - why ripple has such a hard time catching on the way it was originally designed to be used
235 2015-02-22 16:26:45 <kanzure> perhaps i don't mean an incentive, just a mechanism for collapsing multiple transactions using some scheme that i haven't invented yet.
236 2015-02-22 16:27:02 <petertodd> kanzure: yeah, you're confusing economic incentive with something else
237 2015-02-22 16:27:06 <kanzure> yep
238 2015-02-22 16:30:23 <whaack> petertodd: getting btc adoption is pretty easy amongst non-enthusiasts once people start to learn about this http://imgur.com/AIjxOWq
239 2015-02-22 16:30:49 <sipa> lol
240 2015-02-22 16:31:17 <sipa> s/counterfeit/print/
241 2015-02-22 16:31:26 <petertodd> ha
242 2015-02-22 16:31:44 <whaack> the dark net markets are already going to town selling counterfeit for btc
243 2015-02-22 16:34:14 <whaack> ((Everyone in the channel feigns being surprised))
244 2015-02-22 17:15:28 <gdistasi_> are micropa
245 2015-02-22 17:16:00 <gdistasi_> are micropayment channels currently not feasible in bitcoin? I mean, at the moment, IIRC, it is not possible to setup a micropayment channel, right?
246 2015-02-22 17:16:42 <sipa> define "in bitcoin"
247 2015-02-22 17:17:02 <gdistasi_> in the current bitcoin network
248 2015-02-22 17:17:13 <sipa> sure they are
249 2015-02-22 17:17:22 <sipa> there's even software to do so, afaik
250 2015-02-22 17:17:36 <gdistasi_> wasn't there a problem with nLocKTime not being saved in nodes?
251 2015-02-22 17:18:26 <sipa> ah, i haven't followed up on the details
252 2015-02-22 17:19:11 <petertodd> gdistasi_: that problem refers to a very old and obsolete way of implementing payment channels; jspilman's design doesn't have that issue
253 2015-02-22 17:21:33 <gdistasi_> ok. I wonder why, e.g., haven't coinbase and circle, set up a micropayment channel among them to settle transactions amoung their users
254 2015-02-22 17:21:43 <gdistasi_> ok. I wonder why, e.g., haven't coinbase and circle, set up a micropayment channel among them to settle transactions among their users
255 2015-02-22 17:21:55 <petertodd> gdistasi_: not enough cross-platform demand to make it worth it yet
256 2015-02-22 17:22:00 <petertodd> gdistasi_: give it time
257 2015-02-22 17:22:06 <kanzure> also because they have an implementation of something else already (their database)
258 2015-02-22 17:22:17 <petertodd> gdistasi_: remember that you need a *lot* of transactions to make the developer time worthwhile
259 2015-02-22 17:23:29 <gdistasi_> it should be a piece of cake... maybe they don't want to cooperate
260 2015-02-22 17:23:45 <petertodd> gdistasi_: *anything* involving money at that scale isn't a "peice of cake"
261 2015-02-22 17:24:31 <kanzure> why would they need settlement for their internal transactions anyway
262 2015-02-22 17:24:52 <petertodd> kanzure: coinbase <-> circle
263 2015-02-22 17:25:04 <kanzure> couldn't they just use bitcoin?
264 2015-02-22 17:25:14 <kanzure> oh
265 2015-02-22 17:27:27 <gdistasi_> maybe someone should provide a software that can be used to create a payment processor/gateway that can be federated with other of the same kind. Is there any effort in that sense?
266 2015-02-22 17:30:42 <petertodd> gdistasi_: probably not - no market demand for it yet
267 2015-02-22 17:43:53 <gdistasi_> I am not sure of that. Aren't we getting to the point where block size become an issue? What's the plan for that?
268 2015-02-22 17:46:48 <Luke-Jr> gdistasi_: not nearly
269 2015-02-22 17:46:59 <Luke-Jr> maybe in a few years we'll max out 1 MB blocks
270 2015-02-22 19:56:02 <jtimon> so cfields can you help me understand why do you think skipPow shouldn't be part of Consensus::Params ?
271 2015-02-22 19:58:08 <jtimon> and be a parameter of CheckBlockHeader() and ContextualCheckBlockHeader() instead?
272 2015-02-22 19:59:33 <jtimon> I mean I don't have good reasons one way or another, the best reason I have is putting it on the params for cleaner commits...
273 2015-02-22 20:00:08 <crypto_guy> hi, how bitcoin softwares can do operations with float numbers safely like comparison?
274 2015-02-22 20:03:01 <sipa> crypto_guy: they don't
275 2015-02-22 20:05:04 <crypto_guy> sipa: so how the "satoshi number" stored ?
276 2015-02-22 20:06:55 <copumpkin> fixed point math?
277 2015-02-22 20:07:24 <crypto_guy> copumpkin: maybe it is all INT ...
278 2015-02-22 20:07:36 <copumpkin> that's what I mean
279 2015-02-22 20:11:31 <sipa> crypto_guy: all integers
280 2015-02-22 20:12:39 <crypto_guy> thanks :)
281 2015-02-22 20:15:42 <cfields> jtimon: mainly because you're creating a separation of actual consensus params and things that control runtime behavior
282 2015-02-22 20:16:05 <cfields> if there's not going to be a clean separation, i don't understand the reason behind the split
283 2015-02-22 20:16:31 <jtimon> how is that runtime behaviour? it is consensus for unittestparams
284 2015-02-22 20:17:27 <jtimon> I agree there has to be separation, I'm not convinced the param is not consensus
285 2015-02-22 20:18:21 <jtimon> (given that it's used in the consensus functions CheckBlockHeader() and ContextualCheckBlockHeader())
286 2015-02-22 20:18:56 <cfields> only as a runtime optim, no?
287 2015-02-22 20:19:22 <jtimon> as said they could take it as an optional parameter, but I'm not convinced that will be better
288 2015-02-22 20:20:11 <jtimon> well, it could just as well be true by default in unitest mode (that would actually make more sense to me)
289 2015-02-22 20:21:12 <cfields> jtimon: i suppose the question to answer is: is it conceivable to have a chain that operates (functionally and purposefully) with no pow
290 2015-02-22 20:21:57 <jtimon> I think the answer is "yes, unitestparams"
291 2015-02-22 20:21:59 <cfields> if yes, then it's a reasonable chain param. If no, then it's just a runtime option for testing/optim
292 2015-02-22 20:22:14 <sipa> (still haven't looked at the code, ignore if necessary) isn't that exactly what unittestparams does?
293 2015-02-22 20:23:04 <jtimon> btw sipa now the code is easier to review (no a huge pile of commits as before) #5812
294 2015-02-22 20:24:06 <jtimon> I'm not sure but maybe it could always be true for unittestparams instead of having a setter
295 2015-02-22 20:24:16 <cfields> mm, i guess so. Still seems strange to me
296 2015-02-22 20:24:50 <jtimon> well, unittestparams in general seems a little bit strange to me (the setters part)
297 2015-02-22 20:25:24 <cfields> jtimon: i think it seems strange to me because testparams could want to trigger pow on/off as part of its testing
298 2015-02-22 20:25:57 <jtimon> maybe...
299 2015-02-22 20:26:12 <cfields> so it seems like less of a param and more of a runtime option...
300 2015-02-22 20:26:27 <cfields> but i suppose at this point this is just bikeshedding. so i'll stop :)
301 2015-02-22 20:26:33 <jtimon> not sure if that makes it more reasonable to make it an argument for the functions mentioned
302 2015-02-22 20:27:08 <sipa> the whole unittestparams is strange, it's a mutable global
303 2015-02-22 20:28:58 <sipa> and none of its fields should actually ever be changed within the scope of a validation
304 2015-02-22 20:29:20 <sipa> so from that regard, neither should the skippow one
305 2015-02-22 20:29:54 <sipa> which makes it as much a consensus property as the other ones, and not just an optimization
306 2015-02-22 20:31:05 <cfields> sipa: ok, that's a fair argument. So we're talking about 2 things then: the chain param _and_ the runtime optim
307 2015-02-22 20:31:11 <cfields> which aren't necessarily related
308 2015-02-22 20:32:34 <cfields> er, that came out a bit more... obtuse than it should've :)
309 2015-02-22 20:33:11 <cfields> jtimon: ok then. thanks for discussing
310 2015-02-22 20:34:34 <jtimon> you're welcomed, I have a clearer idea of it now as well
311 2015-02-22 20:35:12 <jtimon> unitest shouldn't have setters at all, maybe we need several unittest modes though
312 2015-02-22 20:37:24 <cfields> jtimon / sipa: so by that logic, should fCheckpointsEnabled get the same treatment ?
313 2015-02-22 20:38:39 <jtimon> mhmm, maybe...I'll look into that
314 2015-02-22 20:39:40 <cfields> jtimon: in my refactor i moved fCheckpointsEnabled into main as another nasty global. Maybe it should move to a param instead. But it's a bit different in that tests switch it on/off
315 2015-02-22 20:40:08 <cfields> maybe instead it should be fCheckpointsExist as a chain param, where fCheckpointsEnabled is flipped separately at runtime
316 2015-02-22 20:40:15 <sipa> cfields: we should just get rid of checkpoints :p
317 2015-02-22 20:41:02 <jtimon> mhmm, is that param new? can't find it on my consensus2 branch
318 2015-02-22 20:41:18 <cfields> jtimon: it's not a param atm, i moved it in there
319 2015-02-22 20:41:18 <cfields> sec
320 2015-02-22 20:42:02 <cfields> jtimon: CCheckpoints::fEnabled. checkpoints.h
321 2015-02-22 20:43:29 <cfields> jtimon: see 8d84893 and 568bb8b in my consensus-refactor2 branch
322 2015-02-22 20:44:13 <jtimon> mhmm, my Consensus::ContextualCheckBlockHeader() is currently using Checkpoints::CheckBlock and Checkpoints::GetLastCheckpoint...both depend on Params().Checkpoints()...that's not good
323 2015-02-22 20:44:46 <jtimon> thanks, I'll take a look at that
324 2015-02-22 20:45:46 <cfields> jtimon: yes, my changes make Checkpoints into a class and move it into params
325 2015-02-22 20:46:16 <cfields> sounds like it'd fix your issue there as well?
326 2015-02-22 20:46:44 <jtimon> merging #5812 as it is should make our collaboration easier though
327 2015-02-22 20:47:24 <cfields> agreed, that one's nice and localized
328 2015-02-22 20:48:35 <jtimon> but probably part of the checkpoints stuff should become part of Consensus::Params after your fixes on checkpoints
329 2015-02-22 20:50:01 <cfields> jtimon: ok, i'll rebase after 5812. Sounds like a good way forward.
330 2015-02-22 20:50:21 <jtimon> I assume you're getting rid of boost for the checkpoints stuff
331 2015-02-22 20:50:35 <jtimon> great thanks
332 2015-02-22 20:51:01 <cfields> yes, boost is gone from checkpoints/chainparams/pow/a few others
333 2015-02-22 20:52:25 <cfields> also chainparams drops its globals, and its dependency on net
334 2015-02-22 21:00:40 <cfields> sipa: ah! nice job on the hash changes. I was trying to do the same thing yesterday but never managed to make it quicker.
335 2015-02-22 21:03:18 <sipa> cfields: i was surprised to find that gcc actually recognizes that byteswapping pattern and turns it into a bswap
336 2015-02-22 21:03:38 <cfields> sipa: hmm, maybe that was my problem then...
337 2015-02-22 21:03:45 <cfields> did you check to see if clang does the same?
338 2015-02-22 21:04:05 <sipa> no, didn't have clang installed and i was a slow network connection
339 2015-02-22 21:04:23 <cfields> ok
340 2015-02-22 21:04:23 <sipa> cfields: the old code and the old PR aren't recognized, though
341 2015-02-22 21:05:05 <cfields> what's the difference ( i don't have the code handy)? The de-reference ?
342 2015-02-22 21:06:04 <sipa> old.code was p[0] << 24 | p[1] << 16 | ...
343 2015-02-22 21:06:37 <sipa> doing 4 dereferences, and shifting
344 2015-02-22 21:06:48 <cfields> ah
345 2015-02-22 21:06:58 <sipa> the new code does one dereference, and does an in-word swap
346 2015-02-22 21:07:38 <sipa> anyway, we can still use bswap where available of course
347 2015-02-22 21:07:58 <sipa> if it turns out that not every platform does that optimization
348 2015-02-22 21:54:42 <phroziac> hi
349 2015-02-22 21:55:00 <phroziac> just came to watch
350 2015-02-22 23:54:44 <denisx> I try to build bitcoin 0.10 on freebsd 9 but I get “Error: Initialization sanity check failed”
351 2015-02-22 23:54:51 <denisx> how can I nail down the actual problem?