1 2014-10-31 00:09:39 <edlin_> hey i got my first bitcoins today and spent them, thanks a million for the efforts everyone
  2 2014-10-31 00:11:28 <justanotheruser> s/a million/100million
  3 2014-10-31 03:27:47 <cfields>  /
  4 2014-10-31 03:27:57 <cfields> was bugging me :)
  5 2014-10-31 04:34:34 <fanquake> coreyfields are you around?
  6 2014-10-31 04:40:44 <cfields> yep
  7 2014-10-31 04:41:14 <cfields> fanquake: what's up?
  8 2014-10-31 04:41:46 <fanquake> Morning
  9 2014-10-31 04:42:08 <cfields> almost zzz time :)
 10 2014-10-31 04:42:45 <fanquake> I’ll make this snappy then ;)
 11 2014-10-31 04:43:16 <fanquake> Was wondering about your depends system. How do you plan to manage package versions within it? Just upgrade to new versions when available? Or are you keepin it inline with gitian?
 12 2014-10-31 04:43:47 <cfields> see https://github.com/bitcoin/bitcoin/pull/4727
 13 2014-10-31 04:43:59 <cfields> the main purpose of it was to replace gitian's scripts
 14 2014-10-31 04:44:06 <cfields> travis just got hooked up faster
 15 2014-10-31 04:45:40 <fanquake> ah fair enough.
 16 2014-10-31 04:46:41 <fanquake> So package versions are just bumped when necessary. Was just wondering because now the openssl versions are different after one was bumped?
 17 2014-10-31 04:46:56 <fanquake> btw re homebrew recipie. completely agree with you there.
 18 2014-10-31 04:47:20 <cfields> fanquake: that's just because we're about to drop the old gitian scripts in favor of #4727
 19 2014-10-31 04:47:45 <cfields> after that, there will be nothing to keep in sync. a bump in depends will mean that travis tests the bump, and gitian uses it as well
 20 2014-10-31 04:48:00 <fanquake> yep. That’ll be far better.
 21 2014-10-31 04:48:25 <cfields> some testing would be great ;)
 22 2014-10-31 04:48:51 <fanquake> heh I’m always testing.
 23 2014-10-31 04:49:10 <cfields> gitian builds with that PR, i mean
 24 2014-10-31 04:49:37 <cfields> though, travis has built/used the depends enough times that i'm pretty confident about them by now
 25 2014-10-31 04:50:18 <fanquake> dumb question. Are releases going to be built by travis?
 26 2014-10-31 04:50:48 <cfields> no, still gitian
 27 2014-10-31 04:51:06 <Luke-Jr> a better question is "will travis use gitian?" but I think that's no :P
 28 2014-10-31 04:51:14 <cfields> with #4727, travis pretty much does a full gitian build for each PR...
 29 2014-10-31 04:51:25 <cfields> but gitian is still needed for the deterministic bits. mainly the timestamps.
 30 2014-10-31 04:51:31 <Luke-Jr> fanquake: releases are only releases when the binaries are independently built and signed by multiple parties
 31 2014-10-31 04:51:54 <fanquake> Now we just need to be able to grab the binaries of travis and upload them somewhere so people can test easier.
 32 2014-10-31 04:51:55 <cfields> sorry, that first part was probably confusing. with #4727, travis pretty much builds the same way that gitian would for each PR
 33 2014-10-31 04:51:57 <fanquake> *off
 34 2014-10-31 04:52:19 <cfields> fanquake: yea :\. unfortunately we're still waiting for travis to add that feature
 35 2014-10-31 04:52:30 <Luke-Jr> eh, Travis supports that IIRC
 36 2014-10-31 04:52:36 <cfields> well, we could come close
 37 2014-10-31 04:52:36 <fanquake> I thought it did as well
 38 2014-10-31 04:52:44 <Luke-Jr> it has stuff to keep a private SSH key hidden so it can SCP the results
 39 2014-10-31 04:52:48 <cfields> they support hosted binaries for commits, but not for PR's
 40 2014-10-31 04:52:59 <Luke-Jr> cfields: they block scp for PRs? :P
 41 2014-10-31 04:53:17 <cfields> so we can upload binaries after merge, but not before
 42 2014-10-31 04:53:29 <Luke-Jr> oh
 43 2014-10-31 04:53:32 <cfields> Luke-Jr: you can't keep the private keys hidden for PRs.
 44 2014-10-31 04:53:44 <Luke-Jr> right, because otherwise I could PR a script uploading the key to my server.. XD
 45 2014-10-31 04:53:52 <cfields> Luke-Jr: anyone could PR a change that says "cat $priv.file"
 46 2014-10-31 04:54:07 <fanquake> heh
 47 2014-10-31 04:54:30 <cfields> there are ways around it, but they're slightly DOSable. So it depends how bad we want/need it
 48 2014-10-31 04:55:01 <fanquake> I wonder wether nightlies would actually be a good thing? Would it be better to pick times to build new “testing” releases?
 49 2014-10-31 04:55:06 <cfields> might be a decent idea to host post-merge binaries, though
 50 2014-10-31 04:56:00 <cfields> fanquake: not sure. With the last big project I worked on, releasing nightlies gave a *huge* boost to the number of people testing pre-release code
 51 2014-10-31 04:56:08 <cfields> not sure if that's a good thing for bitcoin, though
 52 2014-10-31 04:57:22 <Luke-Jr> cfields: meh, as long as it's only master and has a nice big warning at the top of the index page..
 53 2014-10-31 04:58:06 <justanotheruser> Luke-Jr: it could just be made to only connect to the testnet
 54 2014-10-31 04:58:08 <cfields> Luke-Jr: we also turned of nightlies after big nasty merges to lessen the noise after known-problematic changes
 55 2014-10-31 04:58:10 <fanquake> luke Are you still doing those tests builds you used to?
 56 2014-10-31 04:58:12 <cfields> headers-first as a good example
 57 2014-10-31 04:58:20 <cfields> *off
 58 2014-10-31 04:59:35 <Luke-Jr> fanquake: you mean next and next-test? not really
 59 2014-10-31 04:59:53 <Luke-Jr> fanquake: I went to just doing forks with things I care about merged, rather than trying to track every other PR
 60 2014-10-31 04:59:54 <fanquake> yep, couldn’t remember what you called them.
 61 2014-10-31 05:00:35 <Luke-Jr> (currently built off 0.9.3 rather than master: http://luke.dashjr.org/programs/bitcoin/files/bitcoind/luke-jr/0.9.x/0.9.3.ljr20141002/bitcoin-0.9.3.ljr20141002.patch.xz )
 62 2014-10-31 12:06:54 <dabura667> Quick question: would a non-nTimeLock tx with a non-0xffffffff sequence be considered standard? (ie. accepted by most nodes?)
 63 2014-10-31 12:11:42 <Luke-Jr> dabura667: IsStandard does not care about nTimeLock if sequence is ffffffff for all inputs IIRC
 64 2014-10-31 12:29:35 <Happzz> feature suggestion: an option to only use a proxy when broadcasting transactions
 65 2014-10-31 12:29:55 <Happzz> i know the client is supposed to be broadcasting transactions around the clock.
 66 2014-10-31 12:32:09 <Happzz> but im talking about specifically transcations that belong to that wallet.
 67 2014-10-31 12:32:14 <wumpus> I think that's been suggested before, but I'm not sure it makes sense
 68 2014-10-31 12:32:42 <wumpus> the idea is that by rebroadcasting other's transactions you hide them in the noise
 69 2014-10-31 12:32:53 <wumpus> if you submit your own transactions in a different way... that'd draw attention
 70 2014-10-31 12:33:24 <Happzz> you could always just see who broadcasted it first.
 71 2014-10-31 12:33:29 <Happzz> or try to, at least
 72 2014-10-31 12:33:45 <wumpus> it would be comparable with using tor for specific sites only, which wouldn't help privacy at all
 73 2014-10-31 12:34:24 <Happzz> using tor to broadcast transcations first, before re-broadcasting it all over the net would actually make sense
 74 2014-10-31 12:34:25 <wumpus> with help of cookies, and other ways, it can still be correlated that you're the same
 75 2014-10-31 12:35:42 <Happzz> technically, it's possible to identify who was the first one to broadcast the tx
 76 2014-10-31 12:35:52 <Happzz> let tor be the first.
 77 2014-10-31 12:36:05 <wumpus> if your node would is reachable over both tor and plainnet (even for a short time), it's possible to determine if you're the same node
 78 2014-10-31 12:36:06 <Happzz> tor wont be need for the further broadcasting
 79 2014-10-31 12:36:18 <Happzz> how so?
 80 2014-10-31 12:36:19 <wumpus> so if you want privacy it's better to be completely behind tor
 81 2014-10-31 12:37:37 <Happzz> the thing is, tor is slow and the excess data transfer over tor is bad for tor
 82 2014-10-31 12:37:55 <Happzz> so i thought, why not spare tor the unneeded bandwidth?
 83 2014-10-31 12:38:05 <wumpus> tor welcomes more usage at the moment
 84 2014-10-31 12:38:09 <wumpus> more noise = more to hide in
 85 2014-10-31 12:38:26 <wumpus> as for the initial sync just use the bootstrap.dat
 86 2014-10-31 12:43:04 <wumpus> it's *possible* to connect to both tor and mainnet peers by using -onion instead of -proxy, but you're giving up some privacy that way, as there are ways to discover that two endpoints end at the same nodes by marking them (from memory: unique orphan transactions, probably other ways as well)
 87 2014-10-31 12:46:14 <xiando> https://lists.torproject.org/pipermail/tor-talk/2014-October/035338.html
 88 2014-10-31 12:47:02 <wumpus> I guess you could work around that by connecting out only when you want to submit a transaction, submitting the transaction, then closing the connection (or even using something like blockchain.info's pushtx over tor)
 89 2014-10-31 12:47:51 <wumpus> or make a wallet that doesn't submit the transaction at all; gives you the hex, and leaves it up to you
 90 2014-10-31 12:48:29 <wumpus> (that's the same kind of setup as offline wallets; so you could likely do it with armory already)
 91 2014-10-31 12:49:20 <iwilcox> Could a node be fingerprinted by what stales it had, too?
 92 2014-10-31 12:49:39 <wumpus> iwilcox: I think so
 93 2014-10-31 12:49:41 <iwilcox> Guess that'd also leak info about uptime.
 94 2014-10-31 12:52:03 <iwilcox> Maybe even peer lists.
 95 2014-10-31 13:10:08 <wumpus> iwilcox: yes, many known and unknown ways to fingerprint bitcoin nodes
 96 2014-10-31 13:10:33 <wumpus> iwilcox: I have various nodes running on both tor and plainnet, but that's to offer a service to tor users and because I don't care about hiding them
 97 2014-10-31 13:13:55 <iwilcox> Yeah, more important for nodes-as-Tor-clients than nodes-as-HSs. Perhaps some sort of auto-linearise of blocks older than X would help towards stales-based fingerprinting.
 98 2014-10-31 13:14:16 <iwilcox> Though at the moment I guess that'd make you stand out /more/ :)
 99 2014-10-31 13:14:38 <wumpus> I'm sure that with a lot of work you could avoid fingerprinting, but it may be fighting the wrong battle
100 2014-10-31 13:15:42 <wumpus> disconnecting nodes and wallets already goes a long way; much less reasons to hide a pure infrastructure node
101 2014-10-31 13:16:46 <iwilcox> As an HS, sure.
102 2014-10-31 13:17:56 <iwilcox> The set of usually-up HS peers is pretty tiny and probably trivial to sybil right now (if it isn't already!).
103 2014-10-31 13:19:34 <wumpus> you could use the fingerprinting to *detect* sybil attacks ;)
104 2014-10-31 13:19:45 <wumpus> (cheap ones at least)
105 2014-10-31 13:24:16 <wumpus> iwilcox: you wouldn't even have to linearize, dropping old stale blocks from the block index would have the same effect without having to rewrite block files
106 2014-10-31 13:25:15 <iwilcox> Never having touched the code I still think in terms of external tools :)
107 2014-10-31 13:39:48 <wumpus> anyhow, in the end it's (users of) wallets that need privacy, not nodes, which just verify, store and forward  public information
108 2014-10-31 20:54:19 <cfields> sipa: ping. mind having a look at https://github.com/bitcoin/bitcoin/pull/5162 ?
109 2014-10-31 20:54:43 <cfields> that's the last major blocker for lib stuff. only the log/error removal remains after.