1 2015-08-06 00:43:09 <mushroomed> heyy
  2 2015-08-06 00:43:36 <mushroomed> I would like to start mining, is there any techy here who can help?
  3 2015-08-06 00:45:02 <Luke-Jr> mushroomed: #bitcoin-mining will inform you how you don't really want to start mining
  4 2015-08-06 00:45:39 <mushroomed> Luke-Jr: haha that's not encouraging
  5 2015-08-06 00:50:01 <Lightsword> right now its mainly massive commercial operations
  6 2015-08-06 00:52:27 <Luke-Jr> mushroomed: regardless, that's where to discuss it
  7 2015-08-06 00:52:48 <mushroomed> Luke-Jr: thanks dude
  8 2015-08-06 04:40:50 <dcousens> hey all,  where in the code base does the bitcoin/bitcoin wallet select inputs for creating a transaction?
  9 2015-08-06 04:43:41 <phantomcircuit> dcousens, SelectCoins
 10 2015-08-06 04:44:02 <dcousens> Thanks @phantomcircuit
 11 2015-08-06 04:56:20 <dcousens> Is there a BIP that outlines best practice for transaction creation such that privacy is preserved? Was just reading https://github.com/bitcoin/bitcoin/pull/2340 and while there is a lot of good information there and in the `CoinSelect`,  `FundTransaction` and various other places in bitcoin/bitcoin,  it would be nice if we could standardize the way
 12 2015-08-06 04:56:20 <dcousens> transactions are created such that privacy is preserved.
 13 2015-08-06 05:27:32 <wumpus> no, there is no BIP for that - could be useful to have an informative BIP that gives recomendations for input selection. But it boils down to: avoid linking inputs that aren't yet linked
 14 2015-08-06 05:30:46 <wumpus> (where "linked" can be defined as: parent inputs are not fed into the same transaction anywhere, within the wallet)
 15 2015-08-06 05:32:13 <wumpus> also make sure that the change output is as unrecognizable as possible, e.g. don't make the mistake of putting it in a fixed position
 16 2015-08-06 05:32:57 <wumpus> that's about everything you can do about privacy without invoking mechanism such as coinjoin.There have been some other ideas like randomly using multiple change outputs, and other ideas to split outputs and even transactions to improve unlinkability. But I'm not aware of any wallets implementing those.
 17 2015-08-06 05:44:51 <wumpus> (it's more than input selection alone, these require a change in how to communicate payments as well. Privacy in bitcoin is a multi-layered issue, input selection, transaction broadcast, communication for negotiation of payments... all these are potential privacy problem vectors)
 18 2015-08-06 06:11:21 <dcousens> assume transactions are by the same person)
 19 2015-08-06 06:11:21 <dcousens> wumpus: granted,  but as wallet diversity grows,  the subtleties in input selection and output ordering will become more and more obvious such that you will more easily be able to draw the barriers around transactions that stay within similar wallet ecosystems (deniable,  but,  combined with other factors greatly increases the probability with which you can
 20 2015-08-06 06:12:05 <phantomcircuit> dcousens, at this point any wallet that doesn't support some form of coinjoin (even if it's imperfect) is lame
 21 2015-08-06 06:12:18 <phantomcircuit> the problem is that by that definition all existing wallets are lame
 22 2015-08-06 06:12:41 <wumpus> diversity grows, that's a fact, but I don't think there's any other way in a decentralized ecosystem. But you could decide to write such a BIP, and maybe you can get people to heed it :)
 23 2015-08-06 06:13:34 <wumpus> there's no one in the world whose full time job is, for example 'bitcoin privacy'... it's all spread out over lots of projects and websites and research
 24 2015-08-06 06:14:37 <dcousens> phantomcircuit:  CoinJoin is a separate vector,  you could entirely base this on purely Transaction creation and stripping as much information from the proposed transaction as possible
 25 2015-08-06 06:14:37 <moa> is there a BIP for coinjoin or coinjoin-related?
 26 2015-08-06 06:15:14 <dcousens> For example,  if a BIP were to exist,  CoinJoin implementations could also follow the spec for the resultant transaction agreed between parties
 27 2015-08-06 06:16:10 <dcousens> wumpus: the problem there is certain scirpts require inputs at the same indexes
 28 2015-08-06 06:16:25 <dcousens> I guess you could enforce the inputs to be the same sort order though
 29 2015-08-06 06:16:42 <moa> think that one got diluted by a related discussionof similar output-ordering and then stalled?
 30 2015-08-06 06:16:45 <phantomcircuit> dcousens, ultimately that's a losing battle
 31 2015-08-06 06:16:48 <wumpus> nah - it applies to the common case, of course there are always edge cases
 32 2015-08-06 06:16:58 <phantomcircuit> dcousens, coinjoin is necessary to maintain long term privacy
 33 2015-08-06 06:17:17 <dcousens> phantomcircuit: I don't deny that that may be the case,  but its still a separate issue
 34 2015-08-06 06:17:17 <wumpus> moa: wouldn't be surprised - many people in bitcoin community have a problem defining scope, or sticking to it
 35 2015-08-06 06:18:22 <wumpus> moa: every proposal grows to enclose everything, then is abandoned because the author loses their motivation/ambition :)
 36 2015-08-06 06:18:33 <moa> hah so true
 37 2015-08-06 06:18:47 <phantomcircuit> wumpus, speaking of which
 38 2015-08-06 06:19:25 <phantomcircuit> was it the intention of the PR that required a rebase of the connlimit pr to make it so the node could exceed nMaxConnections?
 39 2015-08-06 06:20:08 <wumpus> I doubt it (but check the PR itself to be sure?)
 40 2015-08-06 06:20:56 <wumpus> sounds like a bug, I think the idea is that the whitelisted connections carves out a set of connection slots just for whitelisted connections, but nMaxConnections should still be the limit
 41 2015-08-06 06:21:21 <wumpus> "whiteconnections" I mean
 42 2015-08-06 06:21:32 <phantomcircuit> wumpus, ok i'll take another look at it to make sure
 43 2015-08-06 06:22:01 <phantomcircuit> the current logic in my pr will restrict to maxconns but will never evict a whitelisted peer
 44 2015-08-06 06:22:19 <wumpus> sounds correct
 45 2015-08-06 07:56:30 <jonasschnelli> does the libsecp256k1's secp256k1_ecdsa_sign() in the version in current bitcoin master produce a DER encoded sig?
 46 2015-08-06 07:56:58 <jonasschnelli> The current master of libsecp256k1 has a secp256k1_ecdsa_signature_serialize_der() but bitcoins master version is a bit behind.
 47 2015-08-06 07:57:37 <jonasschnelli> I assume "scriptSigRet << vchSig;" (vchSig is the output of secp256k1_ecdsa_sign()) means that the sig comming out of libsecp256k1 is DER encoded?
 48 2015-08-06 08:06:24 <wumpus> if it doesn't produce a DER encoded sig that's be a very nasty bug
 49 2015-08-06 08:06:38 <wumpus> I'm sure people would notice as no transaction would make it into a block anymore
 50 2015-08-06 08:15:26 <jonasschnelli> Indeed. Thanks
 51 2015-08-06 08:26:31 <jonasschnelli> I wasn't sure if the DER encoding was done somewhere outside libsecp256k1 (within bitcoin)
 52 2015-08-06 08:53:28 <wumpus> right. That's have been a possiblity
 53 2015-08-06 08:53:38 <wumpus> would have been
 54 2015-08-06 10:34:51 <hearn> cfields: hello. if you're around, did something change in gitian builds for OS X in 0.11? the DMG produced by gitian doesn't have the effect of the applescript run on it, i guess because applescript doesn't exist on linux
 55 2015-08-06 10:35:01 <hearn> cfields: but i noticed the Core DMG still has the prettification applied
 56 2015-08-06 10:41:31 <hearn_> jonasschnelli: maybe you know?
 57 2015-08-06 12:24:55 <hearn> jonasschnelli: thanks
 58 2015-08-06 12:25:05 <hearn> jonasschnelli: i guess i'm still not sure how the branded gitian-built DMG is being made though
 59 2015-08-06 12:25:10 <hearn> there must be an extra step that isn't mentioned somewhere
 60 2015-08-06 12:25:25 <jonasschnelli> the preforged DMG itself is done on a mac...
 61 2015-08-06 12:25:31 <jonasschnelli> (a bit complex)
 62 2015-08-06 12:25:52 <jonasschnelli> but gitian will just open the DMG, replace the binary and the background together with the .DS_Strore and re-dmg it.
 63 2015-08-06 12:26:14 <hearn> hmm
 64 2015-08-06 12:26:29 <jonasschnelli> Do you ask becuase we wan't to build bitcoin-xt over gitian and like to change the DMG?
 65 2015-08-06 12:26:35 <jonasschnelli> or lighthaus?
 66 2015-08-06 12:26:37 <jonasschnelli> lighthouse
 67 2015-08-06 12:26:43 <hearn> yeah. i already did change it: running "make deploy" creates a nicely rebranded DMG
 68 2015-08-06 12:26:56 <hearn> however, how to copy that across to the gitian built DMG isn't clear.
 69 2015-08-06 12:27:05 <hearn> Lighthouse doesn't use/need gitian. Java projects are inherently already reproducible
 70 2015-08-06 12:27:15 <hearn> (at least the jar is)
 71 2015-08-06 12:28:18 <jonasschnelli> okay... make deploy acts different on a mac then on a linux machine.
 72 2015-08-06 12:28:44 <hearn> yeah, on macos it scripts the finder to rearrange icons and set the background
 73 2015-08-06 12:28:51 <hearn> i guess the DMG itself doesn't have to be reproducible. only the .app
 74 2015-08-06 12:29:00 <jonasschnelli> on a mac is used the macdeployplus script ... together with some applescript magic...
 75 2015-08-06 12:29:11 <jonasschnelli> Right... you can have a .plist with icon positions...
 76 2015-08-06 12:29:19 <jonasschnelli> no i think i remember:
 77 2015-08-06 12:29:22 <hearn> so perhaps there's a way i can edit the gitian-built DMG afterwards. i thought DMGs are immutable, but perhaps I can just unpack, copy the .DS_Store or whatever, and then repack
 78 2015-08-06 12:29:36 <hearn> but i'm surprised such a step isn't in the release-process.md file .... it's pretty comphrensive
 79 2015-08-06 12:29:42 <jonasschnelli> the linux part will create a new DMG (with a linux dmg tool) and copy the background, binary and DS_Store to the new dmg
 80 2015-08-06 12:29:57 <jonasschnelli> the DS_Store needs to be created over macdeployplus (or manually)
 81 2015-08-06 12:30:10 <jonasschnelli> hearn: yeah. Should go in there.
 82 2015-08-06 12:30:26 <jonasschnelli> the DS_Store stuff is really a hack
 83 2015-08-06 12:31:09 <hearn> where does it do the copy?
 84 2015-08-06 12:31:09 <jonasschnelli> So all you need for your Bitcoin-XT fork would be a corresponding .DS_Store
 85 2015-08-06 12:31:43 <jonasschnelli> Makefile.am ~L119
 86 2015-08-06 12:31:48 <hearn> is it supposed to be in the bitcoin-osx-unsigned.tar.gz file?
 87 2015-08-06 12:32:06 <jonasschnelli> no.
 88 2015-08-06 12:32:09 <hearn> ah yes
 89 2015-08-06 12:32:09 <jonasschnelli> only in the DMG
 90 2015-08-06 12:32:16 <hearn> i know how it works when i run make deploy on a mac
 91 2015-08-06 12:32:29 <hearn> what i need to do is combine the linux/gitian world and the mac stuff together somehow
 92 2015-08-06 12:32:34 <jonasschnelli> then copy out the .DS_Store and replace it with the one in the contrib folder
 93 2015-08-06 12:32:42 <hearn> ideally not by hand :) but i can do that if necessary.
 94 2015-08-06 12:32:48 <jonasschnelli> just once...
 95 2015-08-06 12:33:06 <jonasschnelli> if you don't change the binary name it will work also with upcomming releases.
 96 2015-08-06 12:33:18 <hearn> ahhhhh
 97 2015-08-06 12:33:22 <hearn> i see what you're saying
 98 2015-08-06 12:33:37 <hearn> during the *linux* build, the DSStore file is copied
 99 2015-08-06 12:33:41 <jonasschnelli> The magic file is here: contrib/macdeploy/DS_Store
100 2015-08-06 12:33:46 <jonasschnelli> right
101 2015-08-06 12:34:18 <jonasschnelli> the DS_Store is a very strange fileformat. Forging it on linux would be possible.. but nobody invested into this direction..
102 2015-08-06 12:34:36 <jonasschnelli> once created it's pretty static
103 2015-08-06 12:35:13 <jonasschnelli> and don't try to hex edit the existing DS_Store and think you can change some chars there... :)
104 2015-08-06 12:35:39 <hearn> interesting. i see no branding at all ..... perhaps because the .app was renamed or the finder is unhappy in some other way
105 2015-08-06 12:35:49 <hearn> i had assumed if there was a step that did this, i'd see the grey background and icon positions correctly
106 2015-08-06 12:37:07 <jonasschnelli> the DS_Store does somehow store the name of your DMG (filename and title).
107 2015-08-06 12:37:24 <jonasschnelli> If you have changed the DMG name,... you might loose the background image link
108 2015-08-06 12:37:55 <jonasschnelli> so.. best would be, if your local make deploy create a correct DMG, copy out the DS_Store and double-check if your linux build part uses the same title/name
109 2015-08-06 12:38:10 <jonasschnelli> Last time i change this, it also took me some hours..
110 2015-08-06 12:38:32 <jonasschnelli> (and some disappointing moments when i got a unbranded DMG)
111 2015-08-06 12:41:17 <jonasschnelli> hearn: You missed: 
112 2015-08-06 12:41:22 <jonasschnelli> If you have changed the DMG name,... you might loose the background image link
113 2015-08-06 12:41:51 <jonasschnelli> hearn: also mind that the background.tiff (or is it a png) contains two images (for HiDPI retina screens and for normal screens)
114 2015-08-06 12:42:10 <hearn> yeah
115 2015-08-06 12:42:23 <jonasschnelli> another apple magic: https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html#//apple_ref/doc/uid/TP40012302-CH7-SW10
116 2015-08-06 12:42:25 <hearn> i got it working for the ordinary "make deploy". so i think it's just the DS_Store file that's wrong
117 2015-08-06 12:42:28 <hearn> i noticed it has your username in it!
118 2015-08-06 12:42:39 <hearn> and lots of temp paths from your computer. same for the one i made. very odd format indeed
119 2015-08-06 12:42:40 <jonasschnelli> tiffutil -cathidpicheck myimage.png myimage@2x.png -out myimage.tiff
120 2015-08-06 12:42:40 <jonasschnelli> you need that tool:
121 2015-08-06 12:42:52 <hearn> hm ok thanks
122 2015-08-06 12:43:20 <jonasschnelli> hearn: yeah... my username is there... and a path... which is bad.. you could probably strip it out over a hex editor
123 2015-08-06 12:47:02 <whatthe-bull> uh, the famous mike hearn
124 2015-08-06 13:35:36 <hearn> jonasschnelli: it worked, thanks a ton!
125 2015-08-06 13:35:44 <jonasschnelli> Yeah! Nice...
126 2015-08-06 13:36:50 <hearn> heh, yep
127 2015-08-06 13:37:07 <hearn> do you accept changetip? ;) or, are you eventually going to come to zurich where I can give you a proper beer in person?
128 2015-08-06 13:37:30 <teward> just send him a beer voucher good for one expensive beer xD
129 2015-08-06 13:37:36 <teward> in country of his choice
130 2015-08-06 13:37:38 <jonasschnelli> hah.. Yeah... i'm totally antisocial at the moment... we definitively need to meet.
131 2015-08-06 13:38:35 <hearn> beer voucher? seems kind of low tech compared to btc :)
132 2015-08-06 13:38:43 <jonasschnelli> Changetip is not necessary...
133 2015-08-06 13:40:30 <jonasschnelli> at the moment i'm pretty busy helping some friends from Basel to gain a breakthrough with their hardware wallet (digitalbitbox.com)
134 2015-08-06 13:40:55 <hearn> ah yes i remember
135 2015-08-06 13:40:58 <hearn> they brought one to a meetup once
136 2015-08-06 13:41:32 <hearn> it's not a bad design, but it lacks the screen of the trezor, and that seems kind of fundamental to me. no screen = can end up authorising a move of all your coins to the virus maker
137 2015-08-06 13:41:51 <jonasschnelli> The screen is your smartphone...
138 2015-08-06 13:42:18 <hearn> ah yes
139 2015-08-06 13:42:40 <jonasschnelli> It comes with a pre-printed AES key (QR code) so you can make sure your smartphone can be paired without your computer... On the smartphone you can verify your TX.
140 2015-08-06 13:42:46 <jonasschnelli> Much better than on a trezor screen.
141 2015-08-06 13:42:52 <hearn> right. as long as the smartphone is secure.
142 2015-08-06 13:43:03 <hearn> and if it is .... you can as well just use a mobile wallet.
143 2015-08-06 13:43:35 <jonasschnelli> The smartphone then must be compromised by the same identity than compromising your computer where the USB device is attached.
144 2015-08-06 13:43:59 <hearn> right. so it's sort of a way to avoid multisig between the two devices.
145 2015-08-06 13:44:54 <jonasschnelli> Multisig can still be used. It's more a 2FA/sign verification on top of multisig.
146 2015-08-06 13:45:52 <hearn> yeah
147 2015-08-06 13:46:09 <hearn> someone has turned up and wants to implement P2P lending in Lighthouse
148 2015-08-06 13:46:25 <hearn> so I've been doing a lot of code cleanup and optimisation etc, to prepare the ground for other people to contribute. looking forward to seeing what he comes up with
149 2015-08-06 13:47:00 <jonasschnelli> That sounds nice!
150 2015-08-06 13:47:22 <hearn> yeah! the idea is it can do sendmany transactions for the repayments and draw a nice graph of the repayment schedule, etc
151 2015-08-06 13:47:24 <hearn> track default status
152 2015-08-06 13:48:08 <hearn> then you can combine it with some kind of p2p lending website/gallery/community that handles ID verification, reputation etc. like BTCJam or BitLendingClub
153 2015-08-06 19:46:23 <paveljanik> coryfields_, can you please move trivial tree forward so I can PR some trivial change to it?
154 2015-08-06 20:15:58 <phantomcircuit> wumpus, is there anything else i should do for the connlimit-fix pr?