1 2015-09-19 01:59:49 <dcousens> is all bitcoin (as a system) discussion focused on the mailing list?
  2 2015-09-19 02:13:36 <Luke-Jr> dcousens: ?
  3 2015-09-19 02:16:02 <dcousens> Luke-Jr: just in reference to lannwj closing the OP_MOXIE issue
  4 2015-09-19 02:16:37 <Luke-Jr> oh, ML and here then IMO
  5 2015-09-19 02:18:21 <dcousens> Luke-Jr: fair enough, what do you use to read the ML? Compare to GH I've always found it difficult to keep up with
  6 2015-09-19 02:18:50 <dcousens> End up just skpiping most of it atm :/
  7 2015-09-19 02:20:36 <Luke-Jr> dcousens: yeah, I skip most of it too nowadays :/
  8 2015-09-19 02:20:43 <Luke-Jr> too much noise
  9 2015-09-19 02:21:17 <prosodyC> °
 10 2015-09-19 02:23:37 <Luke-Jr> dcousens: nobody wants to moderate the ML because "ohnoes censorship"
 11 2015-09-19 02:24:09 <dcousens> Luke-Jr: which is fair enough, but the problem is I can't filter it on my own accord
 12 2015-09-19 02:24:20 <Luke-Jr> dcousens: it's an ongoing problem
 13 2015-09-19 05:06:49 <maaku> dcousens: imho it was inappropriate as an issue as it is not on the face of it obvious OP_MOXIE is a good idea
 14 2015-09-19 05:07:19 <maaku> the sort of "is this even a good idea to do?" question shouldn't be relegated to an issue tracker that only a small subset of the stakeholders pay attention to
 15 2015-09-19 05:27:07 <wumpus> issues should be actionable, and pertain specifically to the bitcoin core implementation
 16 2015-09-19 05:28:02 <wumpus> so in case anyone interprets it as me being against the idea: no, that's not the point
 17 2015-09-19 05:29:18 <wumpus> a proposal to introduce a whole VM into bitcoin consensus should come with BIP(s), research papers, experiments on test chains, and happen on a whole different level than GH issueso ons
 18 2015-09-19 05:31:13 <wumpus> I like the Moxie arch, I've experimented with it and was even cause for adding a 32*32->64 mult as well as carry functionality
 19 2015-09-19 05:44:41 <wumpus> Luke-Jr: not only because of "ohnoes censorship" but also time demands to moderate a list properly. There have been many suggestions to create a more serious and focused, moderated list, but I don't think there are any takers :)
 20 2015-09-19 05:46:00 <wumpus> jcorgan: LOL at meeting length suggestion
 21 2015-09-19 05:49:14 <wumpus> in a caricature of the bitcoin community, we can't agree on a meeting time and length so let's find a math-based decentralized consensus algorithm to schedule it
 22 2015-09-19 05:51:48 <midnightmagic> WoT mechanisms might be able to help with some of that problem via implicit moderation, so individual notes wouldn't need to be moderated, but rather authors.
 23 2015-09-19 05:57:58 <wumpus> possibly - that's far outside my area of expertise
 24 2015-09-19 05:59:16 <wumpus> at least with a mailing list, people can do their own author-based filtering
 25 2015-09-19 06:01:11 <CodeShark> would these meetings have any particular format? just free discussion on anything? or with some agenda?
 26 2015-09-19 06:01:26 <wumpus> let's just see...
 27 2015-09-19 06:01:32 <CodeShark> and how do we develop a decentralized math-based algorithm to determine the agenda?
 28 2015-09-19 06:03:34 <wumpus> decentralized consensus bureaucracy
 29 2015-09-19 06:04:09 <midnightmagic> I'll get my GPUs on it right away
 30 2015-09-19 06:04:53 <wumpus> the new PoW algorithm will use optimal meeting scheduling?
 31 2015-09-19 06:05:41 <CodeShark> optimal by what criteria? :)
 32 2015-09-19 06:05:44 <wumpus> google agenda is much to centralized, we need MeetingAgendaCoin
 33 2015-09-19 06:06:01 <wumpus> google calendar I mean
 34 2015-09-19 06:07:42 <jcorgan> the winner of the bullshit bingo game each meeting gets to set the agenda of the next
 35 2015-09-19 06:07:48 <CodeShark> you could just stop at google, wumpus
 36 2015-09-19 06:07:57 <CodeShark> no need for a product name
 37 2015-09-19 06:08:17 <wumpus> CodeShark: haha "you lost me at 'google'"
 38 2015-09-19 06:10:04 <jcorgan> wumpus, jgarzik: can you summarize what is left to do for the zmq stuff?
 39 2015-09-19 06:12:02 <CodeShark> who asked for the zmq stuff? and why is that part of Core?
 40 2015-09-19 06:12:25 <wumpus> https://github.com/bitcoin/bitcoin/issues/6681 https://github.com/bitcoin/bitcoin/issues/6679  , as well as adding documentation, at least to doc/release-notes.md and doc/build-unix.md about the new optional dependency
 41 2015-09-19 06:12:42 <jcorgan> i'll get on it
 42 2015-09-19 06:13:19 <wumpus> CodeShark: it is an alternative to the launch-a-process notification mechanism, not sure zmq is the best choice either, but it's been open for ages and no one implemented anything else
 43 2015-09-19 06:14:04 <wumpus> and, looking at the pull request, lots of people were using it already
 44 2015-09-19 06:15:34 <wumpus> the alternative was a simple socket protocol that sends a message on a notification, I would have preferred that, but never got around to actually implementing it
 45 2015-09-19 06:15:46 <CodeShark> I implemented that as a separate process
 46 2015-09-19 06:16:07 <wumpus> that just shifts the problems doesn't it - how does that process get notified?
 47 2015-09-19 06:17:11 <CodeShark> [bitcoind] <-- p2p --> [other process] <-- some transport --> [application]
 48 2015-09-19 06:17:14 <wumpus> the point would be to build the simplest notification mechanism into bitcoin core itself then have specific adapters (eg to zmq/websocket/...) as external processes. But the question is then how to communicate to those processes, otherwise theere's a chicken egg problem.
 49 2015-09-19 06:17:40 <jcorgan> #6679 seems straightforward, i'm pretty clueless about #6681
 50 2015-09-19 06:17:42 <CodeShark> the other process in this architecture must be aware of high level events
 51 2015-09-19 06:17:48 <wumpus> no, the point is that bitcoind can set notifications like 'new tip' to processes
 52 2015-09-19 06:18:06 <CodeShark> yes, that's what the other process does as well in this architecture
 53 2015-09-19 06:18:08 <wumpus> anyhow, too late for this discussion
 54 2015-09-19 06:18:15 <CodeShark> it always is :(
 55 2015-09-19 06:18:24 <wumpus> no, it isn't always. This has been open for years
 56 2015-09-19 06:18:33 <wumpus> it has been discussed at least since I came into the project
 57 2015-09-19 06:18:59 <wumpus> zmq is the only the thing that actually got implemented, and so it won
 58 2015-09-19 06:19:55 <CodeShark> the zmq thing isn't mutually exclusive with these other approaches
 59 2015-09-19 06:20:05 <CodeShark> it's optional anyhow
 60 2015-09-19 06:20:18 <wumpus> no, it isn't. Other software could listen for zmq and propagate the notifications to some other medium.
 61 2015-09-19 06:21:04 <wumpus> something like a three-line python script (at least zmq has lots of language support and bindings). And indeed, it is optional.
 62 2015-09-19 06:22:14 <CodeShark> if you wanted to run it in-process you can also have specific pluggable adaptors, I suppose
 63 2015-09-19 06:22:25 <wumpus> sure
 64 2015-09-19 06:22:48 <wumpus> though it would have my preference to push things out of the process, not into it
 65 2015-09-19 06:23:20 <CodeShark> but then the second process must keep track of state (i.e. maintain a block header tree)
 66 2015-09-19 06:23:52 <CodeShark> at least if you want to use p2p
 67 2015-09-19 06:23:59 <wumpus> bitcoind does that for you, that is the point that it exists
 68 2015-09-19 06:24:49 <wumpus> it can be queried over RPC for that information. The notifications are just simple 'hey, I got some new information' so that there is less need for periodical polling.
 69 2015-09-19 06:26:12 <jcorgan> my original use case was to simply let bitcoind become a "trusted" daemon to listen to p2p and do consensus checks, then forward the raw blocks and txes to listeners.  this means they can get raw data from the p2p that is sanitized by bitcoind, but with only a (very) few lines of code
 70 2015-09-19 06:26:43 <wumpus> it's no different than e.g. -blocknotify, but without forkbomb launcher attached
 71 2015-09-19 06:26:46 <wumpus> jcorgan: right
 72 2015-09-19 06:28:09 <wumpus> although you could do a similar thing by listening on a whitelisted connection to P2P on the node, but this indeed requires less code
 73 2015-09-19 06:29:56 <midnightmagic> forkbomb launcher :-) heh
 74 2015-09-19 06:32:47 <wumpus> midnightmagic: heh :) another advantage of this notification mechanism is that clients can subscribe and unsubscribe to it at will, with -blocknotify the bitcoind process has to be restarted to add a new script
 75 2015-09-19 06:33:17 <CodeShark> I think we can generally agree that -blocknotify is bad :p
 76 2015-09-19 06:36:35 <wumpus> heh, and still it survives for so long because it's simple to use and required no decision on a library or protocol
 77 2015-09-19 06:36:45 <BW^-> guys, how many bytes of script/blockchain data does the spending of one UTXO take?
 78 2015-09-19 06:36:55 <BW^-> so say that I have a Bitcoin address Y, to which 10 000 sends of 0.00001BTC were made.
 79 2015-09-19 06:37:03 <BW^-> now I want to send 1.0 BTC from address Y to address X
 80 2015-09-19 06:37:12 <BW^-> i.e. make a transaction that spends all those 10000 UTXO:s
 81 2015-09-19 06:38:15 <jcorgan> keep this on #bitcoin, pls
 82 2015-09-19 06:38:23 <BW^-> ok
 83 2015-09-19 06:38:26 <BW^-> jcorgan: can you let me know there?
 84 2015-09-19 14:34:50 <Luke-Jr> wumpus: well, an invite-only list would probably be fairly simple.
 85 2015-09-19 14:40:52 <Luke-Jr> moderation of posters is far easier than moderation of posts. but also more politically problematic.
 86 2015-09-19 14:41:54 <wiw> anyone know where i can find a block explorer with raw blocks/txns?
 87 2015-09-19 14:42:07 <wiw> (blockexplorer dot com used to have, but they upgraded to bitpay's insight software)
 88 2015-09-19 14:42:08 <prosodyC> Luke-Jr: In no uncertain terms..
 89 2015-09-19 14:43:05 <morcos> wumpus: ping?
 90 2015-09-19 14:43:20 <morcos> i'm not sure that the libevent stuff is still quite at 100%
 91 2015-09-19 14:43:40 <morcos> did you see this reference: http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html
 92 2015-09-19 14:44:08 <morcos> there seem to be 3 separate things going on.
 93 2015-09-19 14:44:44 <morcos> logging is something that just happens, so for all code we need to set event_set_log_callback
 94 2015-09-19 14:45:25 <morcos> if the library was compiled with debugging support then i'm not sure what happens in 2.0 (which is the latest stable as far as i can tell)
 95 2015-09-19 14:46:08 <morcos> but in 2.1 you can use event_enable_debug_logging to specify that debug log messages should also be logged
 96 2015-09-19 14:47:25 <morcos> additionally in 2.0 and 2.1 there is event_enable_debug_mode which adds expensive debugging checks.  i don't know how that works as far as what compilation options were needed
 97 2015-09-19 14:47:41 <morcos> but the point is that the error i'm getting has nothing to do with debugging
 98 2015-09-19 14:49:41 <Luke-Jr> wiw: blockexplorer.com's "raw" was never raw FWIW
 99 2015-09-19 14:52:04 <wiw> Luke-Jr, yeah I know...
100 2015-09-19 15:10:08 <wumpus> morcos: but it still doesn't work?
101 2015-09-19 15:10:45 <wumpus> morcos: the code does two things now a) redirect the logging b) enable/disable the logging completely, if possible,  I think a and b together catch all
102 2015-09-19 15:13:05 <wumpus> (both in old and new libevent, except in new libevent it will also avoid doing any extra checking, if compiled with debug messages support)
103 2015-09-19 15:19:01 <wumpus> not sure about event_enable_debug_mode - as you say, it adds even more extensive debugging, but those messages will be sent through the same mechanism (controlled by event_enable_debug_mode /  event_set_log_callback)
104 2015-09-19 15:20:23 <wumpus> second event_enable_debug_mode is "event_enable_debug_logging"
105 2015-09-19 15:22:55 <morcos> wumpus: it works for me but it would not work for someone running libevent 2.1 (one sec)
106 2015-09-19 15:23:15 <wumpus> why not? (a) is done unconditionallly
107 2015-09-19 15:23:44 <morcos> oh sorry
108 2015-09-19 15:23:47 <morcos> you're right i misread that
109 2015-09-19 15:24:11 <wumpus> so any logging message ends up in our log system, which filters it. Disabling the debug messages is just 'extra', it may be unnecessary, but I thought it'd avoid some messages being generated in the first place
110 2015-09-19 15:26:09 <morcos> ok, yeah maybe its fine, its not clear to me you'd ever really want the libevent debug log messages, but the way you wrote it you're not going to get them unless you compile for it AND do debug=libevent
111 2015-09-19 15:26:36 <morcos> thx for fixing...  the DEFAULT_DEBUG_LIBEVENT isn't used right?
112 2015-09-19 15:27:07 <morcos> btw, the numeric version you had me look up is a bit misleading
113 2015-09-19 15:27:29 <morcos> i actually have 2.0.21, but for some reason the numeric version lags  .. latest stable is only 2.0.22
114 2015-09-19 15:27:58 <wumpus> right, 2.1 is -alpha, it's not officially out yet
115 2015-09-19 15:29:16 <wumpus> right - DEFAULT_DEBUG_LIBEVENT isn't used anymore
116 2015-09-19 15:32:01 <wumpus> I think when you want to debug some subsystem it makes sense to enable as many log messages for it as possible, but you're right the libevent needs to be compiled with "EVENT_DEBUG_LOGGING_ENABLED" too
117 2015-09-19 15:32:58 <wumpus> a point could be made to always log [warn] and [error] level messages, even when not debug=libevent, but I'm afraid if those are too spammy they'll just distract users (e.g. not being able to bind ipv6 isn't even a problem)
118 2015-09-19 15:34:49 <wumpus> oh! event_err is for unrecoverable errors, we should definitely always log those...
119 2015-09-19 15:36:24 <morcos> ok, i agree not warn though, unless -debug.  ok got to run.  will ACK the PR a bit later today.
120 2015-09-19 15:36:50 <dcousens> Luke-Jr: merge-rebased?
121 2015-09-19 15:36:54 <dcousens> why :P
122 2015-09-19 15:37:25 <Luke-Jr> dcousens: it's nicer and preserves history
123 2015-09-19 15:38:25 <dcousens> I guess,  but only the history in terms of that PR
124 2015-09-19 16:37:38 <wumpus> hah (in llibevent) test/regress_util.c:    LOGEQ(EVENT_LOG_WARN, "Far too many wombats (99)");
125 2015-09-19 16:42:06 <crescendo> a while back, there was an excellent bitcoin script stack visualizer.  anyone recall where it is?  by a while back, I mean maybe 2 years
126 2015-09-19 16:48:23 <wumpus> I don't remember
127 2015-09-19 16:49:40 <wumpus> github.com/siminchen/bitcoinIDE maybe?
128 2015-09-19 21:22:20 <shesek> has anyone read http://gavinandresen.svbtle.com/are-bigger-blocks-dangerous ?
129 2015-09-19 21:22:34 <belcher> yes
130 2015-09-19 21:22:39 <shesek> is it just me, or are big parts of that articles simply factually wrong?
131 2015-09-19 21:23:08 <belcher> which parts?
132 2015-09-19 21:23:32 <shesek> that "you don't need the whole history, just get the utxos from random peers, and if they lie to you, its okay - you'll just see the transaction doesn't get confirmed" has circular logic
133 2015-09-19 21:23:44 <belcher> well iv already been downvoted to -2 for my view on reddit so what do i know
134 2015-09-19 21:24:13 <belcher> i saw that part as advocating spv
135 2015-09-19 21:24:37 <shesek> for other nodes to know that the transaction isn't valid, they must hold their own valid copy of the history. if everyone [or large parts of the network] behave in the manner he's describing, bitcoin would be utterly broken
136 2015-09-19 21:25:23 <shesek> you'll have nodes that have no way to know which transactions are valid and should be relayed/mined, other than trusting other nodes to do so (and, again, not being able to validate they're behaving correctly)
137 2015-09-19 21:26:10 <shesek> also, his "this is the same behavior we already have today due to the possibility of double spend" argument seems nonsensical
138 2015-09-19 21:27:23 <shesek> and the two explanations he's giving for why people claim bitcoin scales as O(n^2) are explanations that i never saw before anywhere... the explanation that is being commonly used (which originated from adam, I believe) is referenced only at the very end
139 2015-09-19 21:27:42 <shesek> am I missing something completely obvious? this makes no sense to me
140 2015-09-19 21:29:22 <shesek> this is just... weird. I must be missing something, right?
141 2015-09-19 21:31:27 <Luke-Jr> shesek: no
142 2015-09-19 21:31:51 <gmaxwell> shesek: I don't think you are. (Actually that particular argument isn't originally from adam, most people know it via petertodd, though it's older than petertodd's use-- maybe dan kaminsky? who knows it's a fairly straight forward observation)
143 2015-09-19 21:32:34 <shesek> that whole post seems to be really, utterly, obviously, factually wrong
144 2015-09-19 21:33:11 <Luke-Jr> shesek: maybe someone should make a list of problems with the article(s) ? :p
145 2015-09-19 21:33:45 <gmaxwell> shesek: if you assume miners follow the protocol faithfully then the claims are less obviously busted.
146 2015-09-19 21:34:36 <shesek> gmaxwell, but then you can just drop to SPV-level security. why bother getting the utxo set at all?
147 2015-09-19 21:34:51 <shesek> this adds no security over SPV
148 2015-09-19 21:34:55 <gmaxwell> shesek: Yup.
149 2015-09-19 21:36:43 <gmaxwell> shesek: some of that arises from not having good language to talk about adversarial models... especially about conditions which are in-bettwen maximally adversarial (under which the system probably just doesn't work at all) or maximally honest (under which you might as well just have a single centeralized server).
150 2015-09-19 21:38:05 <shesek> Luke-Jr, re-worded my text here into a comment: https://www.reddit.com/r/Bitcoin/comments/3llj0j/bigo_scaling_gavin_andresen/cv7aa7r
151 2015-09-19 21:39:00 <Luke-Jr> shesek: don't forget his mis-application of NTS :p
152 2015-09-19 21:39:29 <gmaxwell> shesek: generally when people come up with utxo commitments thats one of the issues that come up; basically in many cases they reduce, precisely, to the SPV security assumptions. And if you're okay with those, well-- you can already use that.
153 2015-09-19 21:40:06 <gmaxwell> But perhaps there is some middle ground that is interesting. It's hard to say for sure.  Though thus far proposed utxo commitment structures all have really high performance costs.
154 2015-09-19 21:41:02 <gmaxwell> Though bramc suggested a design to me last week that I think is asymtopically just a two fold IO increase, so perhaps that will be more interesting...
155 2015-09-19 21:42:42 <shesek> I can see some good reasons for on-chain utxo commitments which are controlled by the hashing power majority, but just querying them from random peers makes absolutely no sense to me o_O
156 2015-09-19 21:50:25 <maaku> can someone point to an explanation of why the O(n^2) total network work result is relevant?
157 2015-09-19 21:59:00 <gmaxwell> maaku: I dunno that it is, other than a general intution that a global flooding network is not an inherently very scalable design.
158 2015-09-19 21:59:46 <maaku> gmaxwell: well i've been able to construct reasons why centralization effects in mining would scale O(N log N) with number of network participants
159 2015-09-19 21:59:52 <gmaxwell> shesek: random peers can be codeword for trusted parties too.. though I think with BIP66 recently we had some nice evidence how even absent malicious behavior thats not a great bet.
160 2015-09-19 21:59:55 <maaku> so it is certainly a superlinear relationship
161 2015-09-19 22:00:33 <maaku> but the observation that "total work done = number of nodes * work done by node = O(n^2)" seems like irrelevant academic wankery, to be honest
162 2015-09-19 22:01:16 <maaku> i've never said anything out of politeness, but I've seen people being dismissive of others in this space because of their failure to agree with O(n^2) scaling, and I don't understand that
163 2015-09-19 22:03:19 <shesek> how has bip66 shown that?
164 2015-09-19 22:04:22 <gmaxwell> shesek: network worked and something like half of the high profile "API" things were on the losing side of the fork.
165 2015-09-19 22:05:25 <shesek> you mean API-as-a-service things? or something else?
166 2015-09-19 22:05:59 <belcher> given all this can we continue to do soft forks?
167 2015-09-19 22:06:18 <belcher> if every time a soft fork is attempted the spv miners screw it up
168 2015-09-19 22:06:57 <gmaxwell> shesek: yea.
169 2015-09-19 22:07:41 <gmaxwell> belcher: I think so-- I mean, upgraded full nodes just didn't even _see_ any of that nonsense.
170 2015-09-19 22:07:51 <gmaxwell> and SPV clients that were enforcing version progression wouldn't have either.
171 2015-09-19 22:08:51 <gmaxwell> maaku: I do think it's wanky, but at the same time I don't think anyone arguing it has been arguing it with much force.
172 2015-09-19 22:23:34 <gmaxwell> maaku: perhaps a more concrete (but I think still fundimentally not that interesting way of looking at it is this):  Even if you assume SPV security (e.g. that either >50% miners are altruists or that miners are rational but no information advantage or >25% miners exist, etc.) each node can handle some upper number of thin clients. (e.g. inbound sockets / 4 * uptime level) and each thin client presen
173 2015-09-19 22:23:40 <gmaxwell> ts some constant increased transaction load... then you get O(N^2) from that alone.  Though this can be easily mooted by having servers with huge numbers of clients, diminishing the quadratic term to irrelevance.
174 2015-09-19 22:39:44 <Luke-Jr> yeah, I think version bits theoretically deals with bad miners in a softfork situation at least
175 2015-09-19 22:41:26 <belcher> how did the july 4th fork actually end?
176 2015-09-19 22:41:37 <belcher> there were two forks iirc
177 2015-09-19 22:41:41 <belcher> but a third never appeared
178 2015-09-19 22:41:58 <gmaxwell> well there were more than two, but there were two of non-trivial length.
179 2015-09-19 22:42:16 <gmaxwell> most of the others went unnoticed because after that point most of the explorers had upgraded to ignore them.
180 2015-09-19 22:42:36 <Luke-Jr> it ended by the headers-only miners adding trust to the mix
181 2015-09-19 22:43:37 <belcher> i see
182 2015-09-19 22:43:58 <belcher> so they'd only build on top of headers made by pools they trusted
183 2015-09-19 22:44:38 <Luke-Jr> yep
184 2015-09-19 22:45:06 <Luke-Jr> I think they actually had that all along, but one of the trusted pools neglected to upgrade one of their nodes or something