1 2015-03-18 01:25:02 <gmaxwell> Greetings all, it would be useful if everyone could start up some testing on the v0.10 branch, as we may be forced into a short turn around release by the pending OpenSSL security announcement. (we were planning to do a 0.10 release soon in any case).
  2 2015-03-18 01:27:02 <petertodd> gmaxwell: what specifically on github are you asking us to test?
  3 2015-03-18 01:27:38 <gmaxwell> petertodd: there is a branch of the bitcoin repo on github called 0.10
  4 2015-03-18 01:28:04 <petertodd> gmaxwell: right, so https://github.com/bitcoin/bitcoin/tree/0.10
  5 2015-03-18 01:28:05 <gmaxwell> What we'd release would be that, plus anything that goes in at the last minute (e.g. any changes triggered by openssl)
  6 2015-03-18 01:28:09 <gmaxwell> Yes.
  7 2015-03-18 01:29:26 <stevedekorte> petertodd: enjoyed your talk yesterday at the SF bitcoin dev meetup but didn't understand why you didn't think sidechains were a potential scaling solution
  8 2015-03-18 01:31:32 <petertodd> stevedekorte: I was probalby being a bit unclear there - federated sidechians are, merge-mined sidechains are worse than a blocksize increase IMO
  9 2015-03-18 01:33:06 <stevedekorte> petertodd: thanks for the clarification. Are federated chains described in the paper?
 10 2015-03-18 01:34:25 <petertodd> stevedekorte: yup, and I've described them before using the term "fidelity bonded ledgers" and/or "fidelity bonded banks"
 11 2015-03-18 01:36:21 <stevedekorte> something that seemed vague in the paper is how side chains (the network of active nodes) would be discovered
 12 2015-03-18 01:36:50 <petertodd> stevedekorte: it'd be just like bitcoin - seed nodes/dns + peer discovery via gossip
 13 2015-03-18 01:36:51 <stevedekorte> and how many the main chain would support, how those would be chosen , etc
 14 2015-03-18 01:37:21 <petertodd> stevedekorte: chosen by miners in the merge-mined really - why I object to calling merge-mined sidechains "permissionless development"
 15 2015-03-18 01:37:59 <petertodd> stevedekorte: in the non-merged-mined case w/ federated chains, you can do it in such a way it's impossible for non-members to even know the sidechain exists
 16 2015-03-18 01:38:15 <gmaxwell> stevedekorte: Sidechains are not a major scaling solution. Potentially they could help scaling in the form of allowing multiple tradeoffs to exist, or by lubricating the deployment of new tech that has better scaling properties, but there is no free lunch in engineering.
 17 2015-03-18 01:38:46 <stevedekorte> petertodd: right but there must be some limit on these for various reasons 1) if they are merged mined, the hashes take up room on the main chain blocks so we can't have an unlimited number 2) the main chain needs to sync with the side headers for verify and those resources are lmited, etc
 18 2015-03-18 01:39:02 <gmaxwell> Well to be clear non-federated sidechains ^. As petertodd notes, federated ones can do some interesting scaling things; but at the expense of an orthorgonal security model from Bitcoin.
 19 2015-03-18 01:39:16 <petertodd> stevedekorte: merge-mining can commit to a merkle tree of hashes, so it's O(1) scaling for n sidechains, modulo other considerations
 20 2015-03-18 01:39:24 <gmaxwell> stevedekorte: no, the hashes do not take up any space on the main chain.
 21 2015-03-18 01:39:30 <gmaxwell> As petertodd says, indeed.
 22 2015-03-18 01:39:31 <gmaxwell> 
ACTION shuts up.

 23 2015-03-18 01:39:56 <petertodd> gmaxwell: I keep meaning to do a "sidechains demystified" paper :P
 24 2015-03-18 01:47:29 <stevedekorte> I'll take a look at the federated peg notes in the paper appendix - thanks
 25 2015-03-18 04:57:11 <gmaxwell> uh why are we leaving up outbound connections to hosts without node-network set?
 26 2015-03-18 04:58:21 <gmaxwell> bleh, I think I just hit an rpc deadlock.
 27 2015-03-18 05:01:06 <gmaxwell> I believe I may have been running getpeerinfo concurrently with a node getting stalling disconnected.
 28 2015-03-18 05:06:15 <gmaxwell> oh good not actually deadlocked, just took minutes to run getpeerinfo
 29 2015-03-18 05:06:38 <gmaxwell> (while catching up)
 30 2015-03-18 05:07:44 <gmaxwell> (two minutes, in fact)
 31 2015-03-18 06:31:40 <wumpus> yes, while catching up that can happen, thought it was something specific to my slow hosts though
 32 2015-03-18 06:32:24 <wumpus> it makes sense now that block download is so efficient:-) the main lock will be continously contended
 33 2015-03-18 06:42:13 <gmaxwell> yep.
 34 2015-03-18 07:49:48 <fanquake> There’s a few sig pulls for 0.10 left to merge at the gitian repo
 35 2015-03-18 07:56:43 <wumpus> ok, will take a look
 36 2015-03-18 08:15:41 <wumpus> merged them all
 37 2015-03-18 08:15:52 <wumpus> wish it was that easy for bitcoin/bitcoin :-)
 38 2015-03-18 08:17:42 <fanquake> heh if only
 39 2015-03-18 08:18:10 <sipa> a button "merge everything" would be so nice
 40 2015-03-18 08:18:23 <sipa> which merges what is mergable, and closes fhe rest
 41 2015-03-18 08:19:02 <wumpus> I'm not sure nice is the right word, it would be convenient, but the result is not going to be pretty :)
 42 2015-03-18 08:19:23 <fanquake> Just make sure you call it a test release ;)
 43 2015-03-18 08:20:31 <fanquake> I’ve actually been looking for a tool we could use that has a much more useful ui than the one on GH.
 44 2015-03-18 08:21:01 <gmaxwell> we do not use the github ui to merge in the actual projects.
 45 2015-03-18 08:21:18 <wumpus> we're kind of bumping up against the limitations of github though, especially with regard to delegating privileges
 46 2015-03-18 08:21:33 <wumpus> and github has shown little interest in extending the feature set there
 47 2015-03-18 08:21:37 <fanquake> Yes, I know. I’m thinking more towards managing pull requests.
 48 2015-03-18 08:22:12 <gmaxwell> I was always kinda surprised that people liked github much to begin with. Seems to provide help for all the parts that don't really need help. :)
 49 2015-03-18 08:22:16 <wumpus> I'd e.g. like to give someone the ability to label and close issues, but not to merge things
 50 2015-03-18 08:22:37 <fanquake> It’d be great to be able to visualize stacks of pull requests. Be able to see what pull conflicts with each other, then you can have a better view of the merge workflow
 51 2015-03-18 08:22:56 <fanquake> wumpus It’s a shame there is no such feature
 52 2015-03-18 08:23:38 <gmaxwell> wumpus: setup another repo, have the PRs there?
 53 2015-03-18 08:23:42 <wumpus> fanquake: yes we had that at a previous employer (but was custom built), a PERT diagram of patches
 54 2015-03-18 08:24:10 <fanquake> wumpus any chance of opening sourcing :) It’d be an awesome tool to have.
 55 2015-03-18 08:25:05 <gmaxwell> wumpus: was it just dumb-mechnical? most merge conflicts are pretty trivally resolved... knowing when there is some serious incompatiblity is probably more interesting.
 56 2015-03-18 08:25:12 <wumpus> gmaxwell: well it's better than having a mailing list people dump patches on, but it seems improvement stopped there a bit...
 57 2015-03-18 08:25:40 <wumpus> github is the new monopolist so now they can rest back and enjoy
 58 2015-03-18 08:26:10 <gmaxwell> wumpus: mailing list of patches (or "hey, go suck this from my tree" isn't so bad with a really good threading MUA that lets you flag/tag/filter.  But at least it's better than if you don't have a good MUA.
 59 2015-03-18 08:26:47 <wumpus> gmaxwell: it wasn't terribly smart but still useful to see; it could detect both overlap in source code and impact on the binary
 60 2015-03-18 08:26:55 <gmaxwell> I guess with the rise of webmail no one has a really good mua anymore. :)
 61 2015-03-18 08:27:11 <wumpus> gmaxwell: well my experiences with it have been hell in busy projects, everything gets lost
 62 2015-03-18 08:28:28 <gmaxwell> hm. works a lot like github though: each PR is a thread, it gets bumped if someone responds in it. If the patch is merged or closed, you have a script that moves the thread to another folder.
 63 2015-03-18 08:28:44 <gmaxwell> (I'm not arguing that we should do this.)
 64 2015-03-18 08:29:09 <wumpus> well a horse cart works pretty much like an automobile... but.... :)
 65 2015-03-18 08:29:18 <fanquake> How about something like this https://prs.paas.allizom.org/bitcoin:bitcoin A somewhat better way to checkout the current pull cue?
 66 2015-03-18 08:29:54 <fanquake> *queue
 67 2015-03-18 08:30:11 <gmaxwell> wumpus: I just mean that its an interface relatively similar to the GH pulls view if used that way. But with the potential benfit of not having a laggy website in the inner loop. (and a lot of downsides too)
 68 2015-03-18 08:31:09 <wumpus> gmaxwell: so any sane mail program you can recommend these days?
 69 2015-03-18 08:32:25 <wumpus> fanquake: could be useful
 70 2015-03-18 08:34:00 <gmaxwell> Well I like mutt. There are fancier things other people use. (but it supports the kinds of things needed for the above: threading, multiple folders, tagging, policy per folder)
 71 2015-03-18 08:36:35 <wumpus> I've regressed back to (al)pine after getting tired of gmail's interface, it's terribly old-fashioned and has no threading model to speak of, but but at least it's fast, ignores html and javascript, and can be controlled easily using the keyboard. Have to try mutt some time.
 72 2015-03-18 08:40:21 <wumpus> I'm generally moving away from web applications or anything involving the browser. But github is pretty nice in that it has a very low threshold for contributors. A manual mailing-list setup may be great if it's set up, but for new people it must be even more dazzling.
 73 2015-03-18 08:40:38 <gmaxwell> I've never used more modern pine, but I'd easily recommend mutt over the pine I used >15 years ago.  :)
 74 2015-03-18 08:41:46 <gmaxwell> yea, dunno how to bridge that gap. Certantly something like github could have been designed to better interface to a different workflow, and perhaps it would be possible to bridge it, but that sounds like a lot of work.
 75 2015-03-18 08:42:36 <wumpus> there is no 'modern pine', at least very little has changed. Just choosing the evil I know :)
 76 2015-03-18 08:46:25 <sipa> i've used mutt for a long time, until i joined google
 77 2015-03-18 09:01:31 <lclc> What is the difference between gavinandresen double-spend relay in Bitcoin-XT and petertodds Replace-by-fee?   With replace-by-fee, will the node drop the tx with the lower fee and only relay the higher one?
 78 2015-03-18 09:04:44 <wumpus> I'd find it harder to formulate what they have in common
 79 2015-03-18 09:08:00 <lclc> Well, both relay a double spend?           but I'm not sure if the purpose is the same. The on in Bitcoin-XT is to show the other party that there was a double spend and the replace-by-fee is to make double spend possible with a higher fee?
 80 2015-03-18 09:09:53 <wumpus> replace-by-fee relays transactions spending the same inputs if they have a higher fee
 81 2015-03-18 09:10:42 <wumpus> in the mempool the new transaction replaces the conflicting transactions
 82 2015-03-18 09:11:58 <wumpus> as for double-spend relay that is meant as a signaling side-channel only, nodes are not supposed to enter the double-spends into the mempool
 83 2015-03-18 09:13:52 <wumpus> (though they could, of course, do so if e.g. the fee is higher, but it's a bandwidth limited channel so it'd be less reliable for that)
 84 2015-03-18 09:15:04 <lclc> ah ok, thanks for clarifying
 85 2015-03-18 09:15:14 <lclc> how good are the chances that replace-by-fee will ever be in upstream?
 86 2015-03-18 09:16:39 <wumpus> well there is a lot of work by especially @jtimon and @luke-jr to make the relaying policy more configurable, by helping test and review their work you could help land it
 87 2015-03-18 09:21:04 <lclc> Nice, where can I find it?
 88 2015-03-18 09:22:08 <wumpus> as always, in the giant pull request list https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+policy
 89 2015-03-18 09:46:36 <lclc> Thanks!
 90 2015-03-18 09:49:55 <petertodd> lclc: the oddity about the difference between RBF and double-spend relaying is that both make it much easier to doublespend even if miners don't adopt either
 91 2015-03-18 09:50:59 <wumpus> petertodd: yes, that had me confused, you've found a commonality between them
 92 2015-03-18 09:51:02 <petertodd> lclc: however the latter isn't meant to make double-spending easier, rather, just to detect double-spends; the former is meant to make it clear that unconfirmed txs are unreliable and set a precident that miners have no responsibility with regard to them
 93 2015-03-18 09:51:26 <petertodd> wumpus: from the perspective of someone trying to rip someone off, anything that relays double-spends helps you out
 94 2015-03-18 09:51:56 <petertodd> wumpus: miner mempool policy is very inconsistent, so it's very easy to get a doublespend mined so long as you can get it propagated to miners
 95 2015-03-18 09:52:42 <petertodd> wumpus: that's why my RBF code *also* preferentially peers with BitcoinXT nodes to help get double-spends relayed to as much of the network and hashing power as possible
 96 2015-03-18 09:53:06 <sipa> wumpus: that's why i opposed relay by fee- if you consider double spending bad, it doesn't help at all in an attavk scenario
 97 2015-03-18 09:53:30 <sipa> as the communication channel is trivial to flood
 98 2015-03-18 09:53:33 <petertodd> sipa: you mean, opposed relaying double-spends? (ie not replace-by-fee)
 99 2015-03-18 09:53:42 <sipa> petertodd: ugh, yes!
100 2015-03-18 09:53:55 <petertodd> sipa: yeah, I pointed that out repeatedly as well
101 2015-03-18 09:54:40 <sipa> i mean, either we want double spending, and you use replace by fee (which enforces incremental relay fees etc)
102 2015-03-18 09:54:42 <wumpus> petertodd: indeed, if you look at the result relaying is relaying, although relaying all transactions with a higher fee is a more reliable mechanism
103 2015-03-18 09:55:04 <petertodd> wumpus: yup
104 2015-03-18 09:55:21 <petertodd> wumpus: unconfirmed txs aside, replace-by-fee is useful in many scenarios
105 2015-03-18 09:55:53 <wumpus> sipa: indeed, either the channel is easy to flood, or the network is easy to flood using it
106 2015-03-18 09:56:10 <sipa> yes, just detecting double spends may make sense
107 2015-03-18 09:56:10 <wumpus> sipa: there's not really a compromise that makes sense
108 2015-03-18 09:56:23 <sipa> but the p2p network is not the place to do it
109 2015-03-18 09:56:40 <wumpus> apart from replace-by-fee, which has other applications as well
110 2015-03-18 09:57:08 <gmaxwell> 'detecting' alone instantly sends you out in the "now I need to sybil attack the whole network and/or suck up all its sockets so that I don't miss anything" mode.
111 2015-03-18 09:58:07 <wumpus> gmaxwell: ugh, yes
112 2015-03-18 09:58:11 <gmaxwell> RBF does also get you the unsticking transactions, though thats also achievable by a reduced mode that increases the values of all outputs.
113 2015-03-18 09:58:37 <petertodd> gmaxwell: meanwhile, anyone relying on first-seen "security" incentivises the attackers do sybil attack the network - which appears to have actually happened against dice sites
114 2015-03-18 09:59:35 <gmaxwell> petertodd: oh what for? just to make sure the dice site makes a false observation?  yea, socket sucking begats sybils.
115 2015-03-18 10:00:28 <gmaxwell> if your goal is to get better visibility by connecting to more stuff, as though that were critically important, an attacker can just give you more crap to connect to and eat up all the honest sockets himself.
116 2015-03-18 10:01:01 <petertodd> gmaxwell: last summer there were double-spends getting mined that strongly suggested either multiple pools were attacking a dice site, or someone was sybil attacking the network
117 2015-03-18 10:01:02 <gmaxwell> not an arms race you can win, esp since if there are multiple defenders they're actually competing with themselves for capacity, not just with the attackers.
118 2015-03-18 10:02:47 <gmaxwell> wumpus: 0.10 branch needs a 0.10.1 bump (not sure if you do that right before the release or what?)
119 2015-03-18 10:02:59 <petertodd> kinda telling ultimately how nearly no-one but newbies actually relies on unconfirmed "first-seen" security :/
120 2015-03-18 10:03:22 <wumpus> gmaxwell: yes
121 2015-03-18 10:03:34 <sipa> 0.10.0.99 first?
122 2015-03-18 10:03:42 <wumpus> could do that now, no problem
123 2015-03-18 10:03:55 <wumpus> sipa: that'd be new :)
124 2015-03-18 10:04:00 <sipa> no
125 2015-03-18 10:04:24 <sipa> but point releases were usually "oh let's do one now", with less planning
126 2015-03-18 10:04:25 <wumpus> at least RCs are not 0.10.0.99
127 2015-03-18 10:04:45 <wumpus> so I'm not sure I see the point in such a intermediate state
128 2015-03-18 10:04:51 <sipa> ok
129 2015-03-18 10:05:10 <wumpus> (there's a point in doing it just after a release, not before one)
130 2015-03-18 10:05:32 <sipa> well it only makes sense if we expect further changes before rc
131 2015-03-18 10:06:14 <wumpus> bumping the version number is quite annoying (needs to be done in various places) so I'd like to avoid doing it unnecessarily
132 2015-03-18 10:06:32 <sipa> ok
133 2015-03-18 10:06:41 <wumpus> so not if there is so little time between now and the release
134 2015-03-18 10:06:50 <wumpus> we could set 0.10.1.99 after the 0.10.1 release
135 2015-03-18 10:07:01 <sipa> ok
136 2015-03-18 10:09:01 <wumpus> (although fortunately the number of places it needs to be changed was reduced with the autotools introduction)
137 2015-03-18 10:27:21 <Muis> Is there a way I can find the X-th transacion since genesis easily?
138 2015-03-18 10:28:00 <Muis> Because blocks have incremental numbers, but tx seem always refered by their txid instead of a number
139 2015-03-18 10:29:34 <Muis> Right now I locate the block, and sum up all tx-counts from all the blocks before, which is not very efficient. Is there something in bitcoind which returns what i need?
140 2015-03-18 10:53:43 <sipa> Muis: bitcoin core keeps track of the number of transactions since genesis in every block
141 2015-03-18 10:55:39 <Muis> sipa: tnx, then I must have overlooked something
142 2015-03-18 10:56:40 <sipa> nChainTx in CBlockIndex
143 2015-03-18 10:57:15 <sipa> it's not exposed anywhere except debug logs, afaik