1 2014-10-23 00:18:42 <dcousens> is there a shortened name for a 'Satoshi' the unit?
  2 2014-10-23 00:19:03 <dcousens> (in popular usage anyway)
  3 2014-10-23 00:19:23 <justanotheruser> dcousens: #bitcoin
  4 2014-10-23 00:19:44 <dcousens> justanotheruser: well, true, but, it was related to some dev haha.. anyway...
  5 2014-10-23 00:20:25 <dcousens> justanotheruser: found https://en.bitcoin.it/wiki/Units
  6 2014-10-23 00:20:40 <justanotheruser> good, that should have your answer
  7 2014-10-23 01:54:40 <jeremyrubin> Hmm anyone know of any interesting bitcoin related security proposals? Looking for a class project.
  8 2014-10-23 02:28:10 <andytoshi> jeremyrubin: ask in #bitcoin-wizards
  9 2014-10-23 04:24:42 <ruste> Anyone here?
 10 2014-10-23 05:04:27 <Adlai> ruste: yes, that happens very frequently
 11 2014-10-23 05:05:08 <ruste> Adlai: Any idea how frequently? Rough estimate?
 12 2014-10-23 06:19:09 <McKayDavis> I'm having no luck getting the -rpcconnect= option to bitcoind to take a netmask/CIDR notation to allow a range of IP addresses.
 13 2014-10-23 06:19:36 <McKayDavis> most of the documentation is outdated and claims that wildcards are supported (they are not)
 14 2014-10-23 06:58:06 <wumpus> McKayDavis: you're using master?
 15 2014-10-23 06:58:22 <wumpus> McKayDavis: can you paste the arguments that you're giving?
 16 2014-10-23 07:16:17 <McKayDavis> wumpus: sorry for the delay, I was trying -rpcallowip=172.17.0.0/16 and -rpcallowip=172.17.0.0/255.255.0.0 (inside a docker container)
 17 2014-10-23 07:16:38 <wumpus> so you're using master?
 18 2014-10-23 07:16:43 <McKayDavis> yes
 19 2014-10-23 07:16:56 <wumpus> then those should work :/
 20 2014-10-23 07:17:18 <wumpus> anything related to it in debug.log?
 21 2014-10-23 07:18:16 <McKayDavis> I switched over to 0.0.0.0/0 and everything started working, lemme switch back, restart and check
 22 2014-10-23 07:21:47 <McKayDavis> wumpus: aye,aye,aye  it works now.  I must have had a typo somewhere in my scripts....argh.
 23 2014-10-23 07:22:08 <wumpus> McKayDavis: ok, thanks for testing it again, I was worried there for a bit
 24 2014-10-23 07:22:54 <McKayDavis> wumpus: but I am also pretty sure that getbalance on a watch only address is incorrect...
 25 2014-10-23 07:23:41 <wumpus> I guess we should add an explanation  of netmasks and how to use them to the 0.10 release notes
 26 2014-10-23 07:24:41 <wumpus> you do provide true for the includeWatchonly flag?
 27 2014-10-23 07:25:33 <McKayDavis> yep, lemme  try to track down a repro
 28 2014-10-23 07:33:01 <zerocool`> Will Greg and Pieter be stepping down as core maintainers now that they are working for a for-profit that is directly competing with the main chain?
 29 2014-10-23 07:33:07 <zerocool`> Is this on topic?
 30 2014-10-23 07:34:00 <McKayDavis> wumpus: ...still waiting for the imoprtaddress to finish rescan
 31 2014-10-23 07:35:17 <wumpus> zerocool`: no, the other way around, hopefully they will have more time to be core maintainers now
 32 2014-10-23 07:35:41 <zerocool`> wumpus:  conflict of interest is alright?
 33 2014-10-23 07:35:50 <phantomcircuit> lol @ u
 34 2014-10-23 07:36:01 <wumpus> which conflict of interest? everyone can hire developers to work on bitcoin core, it's an open source project
 35 2014-10-23 07:36:11 <zerocool`> if everyone pegs their BTC to blockstream chain, Austin Hill has a dictatorship on Bitcoin development
 36 2014-10-23 07:36:15 <wumpus> you know how many Intel people are working on Linux?
 37 2014-10-23 07:36:17 <McKayDavis> is it possible to get the % complete of a rescan via rpc?
 38 2014-10-23 07:36:30 <zerocool`> wumpus: Would it be alright if Gavin was working for Ethereum?
 39 2014-10-23 07:36:50 <wumpus> zerocool`: sure, he can work for whoever he wants
 40 2014-10-23 07:37:07 <wumpus> McKayDavis: I don't think so
 41 2014-10-23 07:37:13 <zerocool`> wumpus:  Not if he wants to keep his job as an unbiased person
 42 2014-10-23 07:37:33 <wumpus> zerocool`: so you somehow think he's some kind of unbiased angel right now?
 43 2014-10-23 07:37:45 <phantomcircuit> if you really think any of them are going to be doing anything differently
 44 2014-10-23 07:37:48 <phantomcircuit> you're mistaken
 45 2014-10-23 07:37:57 <zerocool`> wumpus: Let me rephrase: you see no conflict of interest in Core maintainers working on creating a competitor to bitcoin?
 46 2014-10-23 07:38:02 <phantomcircuit> this is smart people being funded to do what they wanted to do already
 47 2014-10-23 07:38:36 <zerocool`> phantoncircuit:  which is a very bad thing.  they're incentivized to reject PR's that would make bitcoin better then the sidechain
 48 2014-10-23 07:38:47 <phantomcircuit> zerocool`, you're an idiot
 49 2014-10-23 07:38:51 <wumpus> zerocool`: other "competitors" to bitcoin, such as altcoins, don't contribute anything back
 50 2014-10-23 07:39:02 <b-itcoinssg> wumpus: has any one suggested a bitcoin-suite of sorts? As in an open source software bundle that enables anyone with a full node to have a blockchain explorer. meta data viewer, miner stats right on their computer and without having to go to an external website like blockchain.info or cryptograffiiti etc..
 51 2014-10-23 07:39:09 <wumpus> everyone contributing code to bitcoin core is welcome, no matter who you work for, we'll judge mergability based on merits.
 52 2014-10-23 07:39:16 <zerocool`> phantoncircuit: please dont name-call. this is not a joke
 53 2014-10-23 07:39:57 <wumpus> b-itcoinssg: yes, has been suggested, we're still waiting for someone to build it though :)
 54 2014-10-23 07:40:03 <McKayDavis> wumpus: how does bitcoin-qt get the progress info from bitcoind then?
 55 2014-10-23 07:40:14 <wumpus> McKayDavis: a signal
 56 2014-10-23 07:40:40 <zerocool`> wumpus:  i dont know, i just saw reddit and people are concerned about a serious conflict of interest.  The problem is Greg and Pieter being maintainers.  They should step down, and continue to contribute whatever they want.  Unbiased people should take their place
 57 2014-10-23 07:41:26 <b-itcoinssg> wumpus: oh great, I think I might have something, atleast as a proof of concept. I'll try to post something on github when it's at a reasonble state. Thanks for the info!
 58 2014-10-23 07:41:34 <zerocool`> wumpus:  Just wondering, who will have commit access to Blockstream sidechain if its super succesful and everyone pegs their BTC there?
 59 2014-10-23 07:41:36 <McKayDavis> b-itcoinssg: like http://insight.is from bitpay?
 60 2014-10-23 07:41:39 <wumpus> be careful what you wish for... them 'stepping down' would be extremely bad for the project
 61 2014-10-23 07:41:58 <phantomcircuit> zerocool`, sidechains are not competition for bitcoin
 62 2014-10-23 07:42:08 <zerocool`> wumpus:  i'd rather take that risk then have the conflict of interest which is undeniable
 63 2014-10-23 07:42:23 <phantomcircuit> then you're terrible at analyzing risk
 64 2014-10-23 07:42:26 <zerocool`> phantomcircuit:  think about what you just said for a moment.
 65 2014-10-23 07:42:37 <wumpus> zerocool`: ok, I'm tired of this, you seem to be only interested in stirring here
 66 2014-10-23 07:42:42 <b-itcoinssg> McKayDavis: yes! that is a part of it, but I want some kind of one command line installation and configuration to incentive and decentralize informational reliance for anyone running a full node
 67 2014-10-23 07:42:50 <phantomcircuit> zerocool`, if anything sidechains will significantly benefit bitcoin
 68 2014-10-23 07:42:51 <zerocool`> phantomcircuit:  simple thought experiment. What happens if everyone pegs their BTC to blockstream sidechain?
 69 2014-10-23 07:43:26 <zerocool`> phantomcircuit:  the answer is bitcoin main chain dies. (incase you're struggling with that)
 70 2014-10-23 07:43:28 <phantomcircuit> nothing
 71 2014-10-23 07:43:30 <wumpus> McKayDavis: CWallet has a boost::signals2::signal<void (const std::string &title, int nProgress)> ShowProgress signal; nothing in RPC subscribes to it
 72 2014-10-23 07:44:15 <zerocool`> phantomcircuit:  do you think it would be a positive thing if all BTC were pegged to blockstream sidechain, and development of that was controlled by a for profit company who can be compelled by regulators to make code changes?
 73 2014-10-23 07:44:16 <McKayDavis> b-itcoinssg: I'd be interested in contributing.  I've had a similar notion myself..
 74 2014-10-23 07:44:25 <phantomcircuit> wumpus, im not really comfortable with signals for important wallet stuff
 75 2014-10-23 07:44:28 <wumpus> McKayDavis: there's a pull request for a 'warmup mode' which reports progress during startup through RPC, but nothing about rescan
 76 2014-10-23 07:44:32 <phantomcircuit> at least not without a lot of testing
 77 2014-10-23 07:44:40 <b-itcoinssg> McKayDavis: that's great to hear, are you on github?
 78 2014-10-23 07:44:41 <wumpus> phantomcircuit: this is not 'important wallet stuff' but just a progress indicator
 79 2014-10-23 07:44:48 <McKayDavis> wumpus: ah, very nice. thanks for the info
 80 2014-10-23 07:45:18 <McKayDavis> b-ticoinssg: github.com/McKayDavis (nothing much public there at the moment)
 81 2014-10-23 07:45:20 <wumpus> phantomcircuit: also we've used signals for important stuff in bitcoin core for years, so you could say it's tested alright
 82 2014-10-23 07:45:42 <wumpus> phantomcircuit: it's just a fancy dispatch mechanism nothing more
 83 2014-10-23 07:46:02 <wumpus> phantomcircuit: it's a pity C++ doesn't have something like it built in like C#
 84 2014-10-23 07:46:06 <b-itcoinssg> McKayDavis:that's ok, atleast I can ping you to check out the repo once I have it out, I'll start from a ideation perpective, so you can contribute from the get go.
 85 2014-10-23 07:46:12 <zerocool`> phantomcircuit:  You should proabbly prepare for community backlash on the reddit AMA tomorrow regarding Greg and Pieter's conflict of interest
 86 2014-10-23 07:46:36 <zerocool`> well, #blockstream-dev should at least
 87 2014-10-23 07:47:21 <zerocool`> And frankly, the Bitcoin Foundation probably won't be happy with it either (not like they have any power to do anything except write a blog post about their concerns)
 88 2014-10-23 07:48:30 <phantomcircuit> wumpus, iirc nearly all of the wallet functions recheck a bunch of state
 89 2014-10-23 07:49:06 <wumpus> "Unbiased people should take their place" so where do you think you can find all these cryptographically educated, experienced c++ programmers, willing to work on an experimental project like bitcoin? without being paid by an organization that could have 'an conflict of interest' of course...
 90 2014-10-23 07:49:19 <phantomcircuit> zerocool`, you realize sipa and gmaxwell do an enormous amount of the work on bitcoin core
 91 2014-10-23 07:49:35 <wumpus> please be realistic, or you'll sink the ship out of ideological purity?
 92 2014-10-23 07:49:40 <phantomcircuit> sipa has probably written more code than anybody else at this point
 93 2014-10-23 07:50:25 <Luke-Jr> this is more of a #bitcoin topic IMO
 94 2014-10-23 07:50:56 <wumpus> Luke-Jr: right... I say this one last time: Bitcoin Core is just like Linux. Any company can have devs working on it, more participation and contributions are better not worse
 95 2014-10-23 07:51:16 <McKayDavis> zerocool`: what exactly do you envision a worst case scenario as being?  sipa and gmaxwell somehow sabotaging the core?  the worst that could happen imo is they stop working on the project to focus on sidechains
 96 2014-10-23 07:51:31 <wumpus> phantomcircuit: not so much more code, but certainly the most important code
 97 2014-10-23 07:53:08 <phantomcircuit> McKayDavis, dollars to donuts he's mad because this makes his altcoin of choice worthless
 98 2014-10-23 07:53:15 <phantomcircuit> as you can see from his quit message
 99 2014-10-23 07:53:18 <McKayDavis> wumpus: okay, my simple case to repro the watch only getbalance error didn't repro.  I had a more complex wallet.dat earlier that will take me some time to whittle down to a simple case.
100 2014-10-23 07:53:57 <wumpus> McKayDavis: well if you find out specifics please open an issue on github, this is bound to get lost in the IRC crazyness otherwise
101 2014-10-23 07:54:08 <McKayDavis> will do
102 2014-10-23 07:56:44 <McKayDavis> okay,next question while the experts are online.  why does listtransactions only list category: "receive" txns and not sent?
103 2014-10-23 07:57:02 <phantomcircuit> McKayDavis, it does
104 2014-10-23 07:57:22 <McKayDavis> is that a statement or question?
105 2014-10-23 07:57:49 <Luke-Jr> McKayDavis: it shows both
106 2014-10-23 07:58:22 <McKayDavis> not in my build from master today with a single imported watch address.
107 2014-10-23 07:59:14 <Luke-Jr> McKayDavis: well, addresses only ever receive, not send..
108 2014-10-23 07:59:18 <phantomcircuit> McKayDavis, imported will only show receive
109 2014-10-23 07:59:21 <Luke-Jr> so that's probably why
110 2014-10-23 07:59:22 <phantomcircuit> adresses do not send
111 2014-10-23 07:59:33 <SomeoneWeird> inb4 'wut'
112 2014-10-23 07:59:49 <McKayDavis> ah
113 2014-10-23 08:00:41 <phantomcircuit> nah i think he gets it
114 2014-10-23 08:01:02 <Luke-Jr> McKayDavis: bitcoind *does* assume you're trying to do a watch-only-wallet with importaddress though, and *will* add the 'send' transactions for that wallet if you add all its addresses - but it has no way to guess the labels for them
115 2014-10-23 08:01:15 <Luke-Jr> so if you drop the 'label' part of listtransactions, you'll see them
116 2014-10-23 08:01:22 <Luke-Jr> but this only works if you import every address in the wallet
117 2014-10-23 08:01:35 <zerocool``> hen Bitcoin.  When I issue a PR to merge sidechain features into Bitcoin Core, they are either financially motivated on their own, or CEO Austin Hill will simply tell them not to ACK.
118 2014-10-23 08:01:35 <zerocool``> wumpus:  Here's what bothers me.  Suppose that greg and pieter are financially motivated by Blockstream's business model to have as many BTC pegged to their sidechain as possible, so they implement a bunch of great features and 51% of BTC moves over to their chain.  They can keep this competitive edge by ensuring their sidechain has more features t
119 2014-10-23 08:01:41 <Luke-Jr> zerocool``: #bitcoin
120 2014-10-23 08:02:32 <zerocool``> wumpus: and i will move this to #bitcoin if you think its off topic, but this is a serious concern.  (ignoring luke-jr who has already shown he wants a dictatorship on devleopment with his Gentoo fiasco)
121 2014-10-23 08:02:46 <gwillen> zerocool``: #bitcoin, please
122 2014-10-23 08:03:05 <wumpus> zerocool``: well that's exactly the idea; to keep the main blockhchain a stable place, while experiemental features (which may be dangerous) are introduced in sidechains first
123 2014-10-23 08:03:37 <wumpus> zerocool``: as you can move your bitcoins to sidechains, and back, they're not competitors but part of the same system
124 2014-10-23 08:03:38 <zerocool``> wumpus:  I agree with you.  But do you see where that leads?
125 2014-10-23 08:04:10 <zerocool``> wumpus:  of course, but nobody will want to move back to bitcoin core f the sidechain is significantly better.
126 2014-10-23 08:04:22 <wumpus> zerocool``: no, that's impossible to say yet, but it allows much-demanded experimentation that is impossible now
127 2014-10-23 08:04:51 <wumpus> zerocool``: better is not a one-dimensional property, the main chain may be seen as 'safest'
128 2014-10-23 08:06:04 <phantomcircuit> wumpus, dont bother, he's just a scamcoin shill
129 2014-10-23 08:06:52 <phantomcircuit> see
130 2014-10-23 08:06:54 <Luke-Jr> are those ragequits, I wonder?
131 2014-10-23 08:07:07 <phantomcircuit> Luke-Jr, he's spamming the quit message
132 2014-10-23 08:07:13 <McKayDavis> Luke-Jr: so you're saying that if the receiving address is in the wallet then listtransactions will list it for the 'sending' address?
133 2014-10-23 08:08:50 <McKayDavis> i.e. the transactions listed in listtransactions will also include input transactions to destinations if in the wallet?
134 2014-10-23 08:12:37 <Luke-Jr> McKayDavis: there is no sending address. if you fail to add every address in the wallet in question, you get "random sends"
135 2014-10-23 08:14:00 <zerocool`> wumpus: I think side-chains are great.  Its a perfect way to kill altcoins.  A lot of people are very concerned with Greg and Pieter having commit access to Bitcoin Core while being fiancnially incentivized to reject pull requests that would merge Blockstream side-chain features directly into Bitcoin Core
136 2014-10-23 08:14:25 <McKayDavis> I understand there is no sending address -- what's the correct terminology? input script?
137 2014-10-23 08:14:34 <McKayDavis> utxo?
138 2014-10-23 08:15:09 <wumpus> zerocool`: they don't have any incentive to sabotage bitcoin core, if they had they wouldn't be so transparent about it would they?
139 2014-10-23 08:15:38 <wumpus> zerocool`: anyhow, as said,I'm tired of this, I don't have time to partake in moral panics
140 2014-10-23 08:17:22 <zerocool`> wumpus:  unfortunately politics plays a role in every open-source project, it just comes with the territory.  I'd rather spend time coding as well. But I'm very concerned.  And nobody has explained why they are alright with the conflict of interest.  Deciding who has commit access on github is a serious thing.  This is a serious concern
141 2014-10-23 08:17:23 <wumpus> one day it's about the bitcoin foundation 'monopolizing' bitcoin development, then other companies finally start to contribute and it's their fault, can't you people work on something constructive?
142 2014-10-23 08:18:21 <wumpus> you know there is this nice 'fork' button on github that gives you an exact copy of the repository (plus history) with exactly the same admin rights that I have?
143 2014-10-23 08:19:16 <rubensayshi> zerocool`, look at how much discussion has gone into previous PRs, even small ones, do you really think a big one would be merged in without anyone caring
144 2014-10-23 08:19:24 <phantomcircuit> wumpus, dont bother, he's just a scamcoin shill
145 2014-10-23 08:19:29 <Luke-Jr> can we keep it on #bitcoin?
146 2014-10-23 08:19:48 <gwillen> yeah, please do take it to #bitcoin, wumpus, zerocool`
147 2014-10-23 08:19:49 <wumpus> phantomcircuit: sorry... I'm just so tired of this shit :/
148 2014-10-23 08:19:56 <rubensayshi> plus we have this beautiful consensus mechanism in the protocol, if people really don't want it they just don't install
149 2014-10-23 08:20:47 <zerocool`> phantomciruit: i've had more then one commit merged to bitcoin core. i'm not a troll, and hate altcoins.  Sidechains and treechains are the future.  My only concern is the conflict of interest
150 2014-10-23 08:21:17 <phantomcircuit> zerocool`, your quit message is a black coin site
151 2014-10-23 08:21:24 <phantomcircuit> nice try
152 2014-10-23 08:21:25 <wumpus> but yes, take this to #bitcoin
153 2014-10-23 08:21:45 <gwillen> zerocool`: #bitcoin, please (and I'd be curious to see a pointer to your merged commit(s).)
154 2014-10-23 08:23:06 <Pippp> anyone familiar with pyrpcwallet?
155 2014-10-23 08:23:26 <zerocool`> gwillen: i'm using tor and an alias for political reasons right now
156 2014-10-23 08:23:56 <zerocool`> phantomcircuit: i'm using blkfeed:7778 because it works with tor
157 2014-10-23 08:24:17 <wumpus> zerocool`: #bitcoin
158 2014-10-23 08:24:27 <Luke-Jr> wumpus: phantomcircuit just +q'd him there :/
159 2014-10-23 08:24:40 <zerocool`> I couldn't care less about blackcoin -- sorry about the quit message, if theres a better option let me know.  I'll move this to #bitcoin at the request of wumpus. Thanks for listening to the concern
160 2014-10-23 08:25:04 <wumpus> Pippp: no, hadn't heard if it yet, what is it, an SPV wallet?
161 2014-10-23 08:25:08 <zerocool`> well, if phantomcircuit would -q me, I could move it there.
162 2014-10-23 08:26:18 <Pippp> python for bitcoin
163 2014-10-23 08:27:45 <wumpus> Pippp: yes, it claims to be a wallet that offers a bitcoind-compatible RPC interface, but it doesn't mention how it works (except "no need to download the blockchain" which could imply SPV, but also something much worse like relying on a central service)
164 2014-10-23 08:28:22 <Pippp> it uses pycoin package
165 2014-10-23 08:28:56 <Pippp> you can just hit blockchain.info
166 2014-10-23 08:31:54 <SomeoneWeird> :X
167 2014-10-23 08:38:33 <McKayDavis> is it possible to remove a watch only address from the wallet? pywallet.py does not support watch addresses (yet)
168 2014-10-23 08:40:23 <Luke-Jr> McKayDavis: I don't believe so
169 2014-10-23 08:44:37 <McKayDavis> just to confirm before I file an issue w/ getbalance on github: getbalance for a watch only address should return the sum of all utxos correct? e.g. it should be equivalent to the 'Final Balance' field on blockchain.info?
170 2014-10-23 08:46:46 <phantomcircuit> McKayDavis, no
171 2014-10-23 08:47:03 <phantomcircuit> im not sure that getbalance is even meaningful for a wallet with a watch only address
172 2014-10-23 08:47:07 <Luke-Jr> McKayDavis: the 'Final Balance' field on blockchain.info is bogus
173 2014-10-23 08:47:32 <Luke-Jr> McKayDavis: sum of all utxos is only something with meaning for a wallet, not an address
174 2014-10-23 08:48:05 <Luke-Jr> also, getbalance doesn't take an address as an option, it takes an account - which is a feature that's going away
175 2014-10-23 08:48:05 <phantomcircuit> and actually
176 2014-10-23 08:48:15 <phantomcircuit> getbalance should always return 0 for wallets with only watch addresses
177 2014-10-23 08:48:18 <phantomcircuit> since it cant spend them
178 2014-10-23 08:49:38 <McKayDavis> sorry, yes I meant account.
179 2014-10-23 08:49:53 <Luke-Jr> McKayDavis: accounts don't make sense for watch-only wallets, because you're missing info
180 2014-10-23 08:51:00 <McKayDavis> okay, then what is the proper way to get the total amount available for spending from a watch only address.
181 2014-10-23 08:51:25 <phantomcircuit> McKayDavis, that isn't an operation that makes sense
182 2014-10-23 08:51:52 <McKayDavis> luke-jr: importaddress with a public address also takes an account parameter
183 2014-10-23 08:53:06 <Luke-Jr> McKayDavis: yes, that account is credited for receipt
184 2014-10-23 08:53:18 <Luke-Jr> McKayDavis: you can't spend from an address.
185 2014-10-23 08:53:32 <Luke-Jr> addresses only receive, they don't send
186 2014-10-23 08:54:22 <McKayDavis> someone else (another node say) can sign a script sending the coins with the private key associated with that address...
187 2014-10-23 08:54:44 <phantomcircuit> McKayDavis, it's bad to think of it that way
188 2014-10-23 08:58:10 <McKayDavis> why? is there a document that explains a better way to view this?
189 2014-10-23 08:59:22 <phantomcircuit> McKayDavis, transactions have outputs
190 2014-10-23 08:59:39 <phantomcircuit> a wallets balance is the set of unspent transaction outputs which the wallet can spend
191 2014-10-23 08:59:52 <phantomcircuit> regardless of what type of script is needed to spend them
192 2014-10-23 09:03:20 <McKayDavis> I do understand that part, really.  but I'm missing why it's 'bad' to view a balance of an address as the sum of UTXO's held by that address.
193 2014-10-23 09:04:15 <Luke-Jr> addresses don't have balances.
194 2014-10-23 09:04:21 <Luke-Jr> the private key does, but that's not the address.
195 2014-10-23 09:04:22 <phantomcircuit> McKayDavis, because it's only one type of transaction script
196 2014-10-23 09:04:27 <Luke-Jr> the address is an opaque token for receiving
197 2014-10-23 09:04:28 <McKayDavis> p2sh and multi-sig? is that the wrench in my view?
198 2014-10-23 09:04:31 <phantomcircuit> also what Luke-Jr said
199 2014-10-23 09:04:46 <phantomcircuit> a watch only wallet cant spend the coins
200 2014-10-23 09:04:47 <Luke-Jr> and an address is only supposed to be used once ever
201 2014-10-23 09:04:49 <phantomcircuit> so it has zero balance
202 2014-10-23 09:11:53 <McKayDavis> re: "the address is an opaque token for receiving" -- sure, but there's only one public address per private key right?  also, addresses are 'supposed' to be used once, but that's not true in practice.
203 2014-10-23 09:12:20 <phantomcircuit> McKayDavis, technically there are 2
204 2014-10-23 09:12:37 <Luke-Jr> McKayDavis: never design stuff contrary to what is supported/expected please :/
205 2014-10-23 09:13:50 <Jouke> McKayDavis: doesn't make it right.
206 2014-10-23 09:14:46 <McKayDavis> I cannot prevent the actions of others, I'm just trying to get a balance for an address I don't have the keys for, whether it has 1,2, or n txns associated with it.
207 2014-10-23 09:15:52 <Luke-Jr> McKayDavis: it doesn't make sense to do that.
208 2014-10-23 09:16:04 <McKayDavis> phantomcircuit: ah, 2 eh?
209 2014-10-23 09:16:28 <phantomcircuit> compressed and uncompressed
210 2014-10-23 09:16:29 <Luke-Jr> there is no reason for us to support showing the balance of a private key
211 2014-10-23 09:17:06 <McKayDavis> okay, starting to understand.... been ingrained to look at it the other way for so long.
212 2014-10-23 09:17:18 <phantomcircuit> oh actually
213 2014-10-23 09:17:20 <phantomcircuit> there are more
214 2014-10-23 09:17:30 <phantomcircuit> the address is the hash of the ASN.1 representation of the public key
215 2014-10-23 09:17:42 <phantomcircuit> but you can pad the public key with zeros and get a new address
216 2014-10-23 09:17:52 <phantomcircuit> so there are like thousands per private key
217 2014-10-23 09:17:58 <phantomcircuit> but like
218 2014-10-23 09:18:00 <phantomcircuit> dont do that
219 2014-10-23 09:19:10 <Luke-Jr> lol
220 2014-10-23 09:19:32 <McKayDavis> so, if someone underpays an an address for an invoice, the remaining debt needs to be sent to another address?
221 2014-10-23 09:19:52 <phantomcircuit> McKayDavis, that would be optimal
222 2014-10-23 09:21:24 <Luke-Jr> McKayDavis: yes, ideally. the payment protocol doesn't really allow undeypayment
223 2014-10-23 09:21:42 <Luke-Jr> McKayDavis: reusable addresses also have a builtin mechanism for multiple payments too
224 2014-10-23 09:22:36 <McKayDavis> yeah, payment protocol will be v0.0.2....
225 2014-10-23 09:23:52 <McKayDavis> I'm just trying to get a payment verification backend that doesn't depend on blockchain.info or other third-party
226 2014-10-23 09:28:23 <McKayDavis> thx everyone for their time!
227 2014-10-23 10:20:15 <finway> So,sidechain is the solution ?
228 2014-10-23 10:25:08 <finway> I see so many big names on the whitepaper
229 2014-10-23 11:04:17 <Adlai> in a fresh sync, after reaching height=87704, 0.9.3 has begun reporting orphans from ORPHAN BLOCK 155 through 420 and counting
230 2014-10-23 11:04:22 <Adlai> he ded?
231 2014-10-23 11:04:43 <Adlai> ah nvm, it's rolling again
232 2014-10-23 11:05:55 <justanotheruser> Adlai: happens to me a lot too.
233 2014-10-23 11:06:04 <justanotheruser> goes up to the 750 limit and the continues
234 2014-10-23 11:06:12 <justanotheruser> *then
235 2014-10-23 11:06:28 <wumpus> orphans are normal during initial sync
236 2014-10-23 11:06:42 <wumpus> headers-first will solve this
237 2014-10-23 11:06:47 <Adlai> 
ACTION has this sync on a timer

238 2014-10-23 11:07:02 <Adlai> wasn't headers-first merged?
239 2014-10-23 11:07:19 <wumpus> yes, but that doesn't help if you're using 0.9.3
240 2014-10-23 11:07:30 <wumpus> master has it, 0.10.x will have it
241 2014-10-23 11:09:52 <Adlai> now that you mention it, 0.9.3 is < 0.9.99 >_<
242 2014-10-23 11:17:29 <anton000> anyone got testnet coins?
243 2014-10-23 11:17:31 <anton000> msySzSNHTYwFVzmvUGQZ59h3pdZLDQfbak
244 2014-10-23 11:17:58 <Adlai> 
ACTION sends

245 2014-10-23 11:19:24 <anton000> thnx!
246 2014-10-23 11:19:57 <anton000> got 399
247 2014-10-23 11:20:12 <Adlai> i have 0.1 more if you need
248 2014-10-23 11:21:52 <anton000> i think i have enoguht to test with :) thnx!
249 2014-10-23 11:36:37 <deego> gmaxwell and Luke-Jr: Kudos on the sidechain paper. I'm still reading it (on my superficial level, of course.. I'm likely getting a whoosh on a lot of it). Can I ask a Q in the meanwhile: Does the implementation of sidechain technology need any patches to bitcoin itself, or does it work with bitcoin as it stands atm?
250 2014-10-23 11:37:39 <Luke-Jr> deego: a proper implementation really needs a softfork at least - but with the current master blockchain, it's possible to do "federated pegs" which basically means an automated N-of-M signs for transfers back
251 2014-10-23 11:38:22 <Luke-Jr> deego: the idea is to implement the softfork (or hardfork) necessary for the sidechains in a sidechain itself, and use a federated peg to link that sidechain to the current chain, until everyone is comfortable making that sidechain the new main chain
252 2014-10-23 11:40:15 <deego> Luke-Jr: thanks. Are other sidechains that never aim to always be a side chain viable? Such as namecoins?
253 2014-10-23 11:40:37 <Luke-Jr> you mean never aim to be a main chain? sure
254 2014-10-23 11:40:54 <deego> nice
255 2014-10-23 11:40:55 <Adlai> deego: you could implement a name registration sidechain, where you pay registration fees in bitcoin, rather than a separate currency
256 2014-10-23 11:40:55 <Luke-Jr> this first case is "special" because a federated peg isn't really a good idea to rely on long-term
257 2014-10-23 11:41:21 <Luke-Jr> (although future would-be-hardforks can use it too)
258 2014-10-23 11:44:53 <deego> Adlai and Luke-Jr: If sidechain assets are 1-1 exchange from bitcoins, where do "exchange rates" come in? Pardon my stupid Q, I'm having trouble understanding the concept atm :(
259 2014-10-23 11:48:05 <Adlai> deego: they don't, one of the main points of sidechains is to be able to use the parent chain's reward currency directly in sidechains
260 2014-10-23 11:48:29 <Adlai> if you issue assets in a sidechain (eg colored coins), that's a different story
261 2014-10-23 11:49:48 <deego> Adlai: Ah, I came across "exchange rates" in the paper. I guess that refers to an essentilly fixed rate..
262 2014-10-23 11:50:01 <deego> got you re colored coins
263 2014-10-23 11:54:45 <b-itcoinssg> deego, can you please provide a link for the paper?
264 2014-10-23 11:54:55 <Adlai> b-itcoinssg: http://www.blockstream.com/sidechains.pdf
265 2014-10-23 11:55:03 <b-itcoinssg> thanks Adlai
266 2014-10-23 11:55:15 <Adlai> deego: "Two-way peg refers to…  a fixed or otherwise deterministic exchange rate."
267 2014-10-23 11:55:23 <Adlai> (from 3.1 Definitions)
268 2014-10-23 11:58:05 <deego> Adlai: yeah
269 2014-10-23 12:00:48 <Luke-Jr> deego: someone might want their sidechain to be 1:111111 or something *shrug*
270 2014-10-23 12:06:28 <wumpus> Luke-Jr: may to allow dividing up bitcoins, if satoshis are no longer enough
271 2014-10-23 12:06:48 <wumpus> maybe*
272 2014-10-23 12:07:02 <Luke-Jr> wumpus: don't need to have an exchange rate for that :p
273 2014-10-23 12:07:23 <Luke-Jr> although I guess you might want one in such a scenario
274 2014-10-23 12:07:33 <wumpus> well, if both sides in base units, you'd have an 'exchange rate'
275 2014-10-23 12:07:40 <justanotheruser> when 1 satoshi isn't granular enough, I wonder if we will just move to a child chain with more granularity rather than hard forking
276 2014-10-23 12:07:59 <wumpus> justanotheruser: at least small transactions can move to that child chain
277 2014-10-23 12:31:36 <b-itcoinssg> sidechain consensus security within its eco-system is independent of Bitcoin right? or atleast can be, unless merged mining is implemented?
278 2014-10-23 12:35:21 <Adlai> b-itcoinssg: aiui, correct.
279 2014-10-23 12:37:30 <b-itcoinssg> I'm trying to look at this from a critical perspective, if the paper is accurately in modeling what will happen when implemented, the only people against this would be those that "burned" bitcoins in the past to issue their "asests"? Does anyone see any other detractors from the proposal, assuming it does work?
280 2014-10-23 12:38:39 <Adlai> those who clone, pump, and dump altcoins for rent money
281 2014-10-23 12:38:53 <b-itcoinssg> :-) right
282 2014-10-23 12:39:17 <finway> about side-chains:   could two-peg sidechains someday be able to  cut the peg or change to one-side peg sidechains ?
283 2014-10-23 13:11:51 <jgarzik> hum
284 2014-10-23 13:12:17 <jgarzik> Report:  Bitcoin-Qt cannot open wallet file after upgrade to OSX Yosemite.
285 2014-10-23 13:12:31 <jgarzik> When the wallet is copied to an older OSX machine, the wallet file opens just fine.
286 2014-10-23 13:14:36 <rdymac> Could the be corrupted?
287 2014-10-23 13:14:42 <rdymac> It*
288 2014-10-23 13:15:16 <timothy> <jgarzik> When the wallet is copied to an older OSX machine, the wallet file opens just fine.
289 2014-10-23 13:15:20 <rdymac> Any BitcoinTalk.org admin/ super moderator?
290 2014-10-23 13:16:15 <rdymac> timothy: I use two OSX, I have things working on one and it doesn't work in the other... Just because a new param is needed for the new os
291 2014-10-23 13:16:56 <rdymac> So, if the file is created in the new system it works, but if imported it doesn't
292 2014-10-23 13:17:08 <paveljanik> rdymac: which one? Is it documented?
293 2014-10-23 13:17:53 <rdymac> Mountain Lion and Mavericks... Huge jump, so maybe Yosemite has same problem.
294 2014-10-23 13:18:23 <rdymac> Exporting keys and labels, then importing them might do the trick
295 2014-10-23 13:19:14 <rdymac> I can't enter to #bitcoin (banned) where can I find a BitcoinTalk admin?
296 2014-10-23 13:20:16 <timothy> rdymac: why are you banned?
297 2014-10-23 13:22:00 <rdymac> Because I called to action when Venezuelans were being shot in the face by the government forces
298 2014-10-23 13:25:10 <iwilcox> rdymac: Unbanned, on the understanding that you won't push non-Bitcoin political stuff there again.
299 2014-10-23 13:25:48 <rdymac> Yeah, of course
300 2014-10-23 13:26:50 <rdymac> Ukraine is good to be discussed, Venezuela is not. Lesson learned :). Will look for a forum admin elsewhere too. Thanks for the unban
301 2014-10-23 13:27:41 <rdymac> Sorry for the offtopic at -dev
302 2014-10-23 13:48:32 <elichai2> hey
303 2014-10-23 13:48:36 <elichai2> why does the QT isn't running the deamon too?
304 2014-10-23 13:48:38 <elichai2> (I mean why does the QT isn't like a GUI above the deamon)
305 2014-10-23 13:48:57 <timothy> no
306 2014-10-23 14:04:57 <jgarzik> elichai2, Bitcoin-Qt may act as a server
307 2014-10-23 14:05:20 <jgarzik> Bitcoin-Qt is already a P2P node.  You may use the RPC console in the Qt GUI, or turn on the internal RPC server.
308 2014-10-23 14:05:30 <elichai2> jgarzik, but why? i mean, why i need to close the Qt and run the deamon just to make some commands
309 2014-10-23 14:05:51 <elichai2> no, i wrote a script that does some things for me via the CLI
310 2014-10-23 14:05:56 <jgarzik> elichai2, You do not need to do that.
311 2014-10-23 14:06:17 <elichai2> what do you mean?
312 2014-10-23 14:06:25 <jgarzik> elichai2, QT supports the cli.  Turn on the -server option
313 2014-10-23 14:06:39 <elichai2> ohhhh. ok, i'll try thx
314 2014-10-23 14:06:58 <b-itcoinssg> Jeff, I think he means, why doesn't the QT act as a top layer framework that uses the daemon as its engine
315 2014-10-23 14:07:31 <jgarzik> b-itcoinssg, I think we got it.  He wrote "why i need to close the Qt and run the deamon just to make some commands"
316 2014-10-23 14:07:42 <b-itcoinssg> right
317 2014-10-23 14:12:02 <elichai2> jgarzik, b-itcoinssg, i meant both btw, lol
318 2014-10-23 14:12:44 <elichai2> after i figured out i had to close the QT to run the deamon i asked myself why it's not act as a top layer above the deamon
319 2014-10-23 14:13:24 <jgarzik> QT == daemon + more
320 2014-10-23 14:13:30 <jgarzik> QT includes the daemon, internally.
321 2014-10-23 15:07:31 <wumpus> <jgarzik> Report:  Bitcoin-Qt cannot open wallet file after upgrade to OSX Yosemite. <- same version of berkeleydb?
322 2014-10-23 15:08:14 <wumpus> this sounds like the typical 'the wallet has been opened with bdb 5.1 then cannot be opened with 4.8 anymore' problem
323 2014-10-23 15:08:48 <jgarzik> wumpus, this guy doesn't do custom builds, just uses our release version downloads
324 2014-10-23 15:09:01 <jgarzik> a Mere User
325 2014-10-23 15:09:16 <kjj> why do so many things assume you want to perform an irreversible backup when you use them?
326 2014-10-23 15:09:17 <wumpus> what error does he get?
327 2014-10-23 15:09:25 <kjj> er, upgrade, not backup
328 2014-10-23 15:09:26 <jgarzik> I'm going to get ahold of the debug.log and have that answer soon, hopefully
329 2014-10-23 15:09:59 <wumpus> anyhow, I'd be surprised if you can't work around it with a combination of   db4.8_dump wallet.dat | db4.8_load wallet.dat.new
330 2014-10-23 15:11:46 <wumpus> kjj: indeed, downgrading is not usually considered an option at all
331 2014-10-23 15:12:43 <kjj> I seem to recall some versions of the ext filesystem pulling that crap before too
332 2014-10-23 15:17:48 <wumpus> kjj: yes, I remember as well, although it was possible to force using some mount option
333 2014-10-23 15:34:05 <Adlai> 
ACTION syncs bitcoind master on his home connection: 2h31m in, progress=0.269849

334 2014-10-23 15:34:33 <chmod755> Adlai, are you using bootstrap.dat?
335 2014-10-23 15:35:01 <Adlai> chmod755: nope, headfirst sync
336 2014-10-23 15:35:12 <chmod755> ohhh wow
337 2014-10-23 15:35:19 <Adlai> it's in github master now!
338 2014-10-23 15:36:36 <chmod755> should i start using it already?
339 2014-10-23 15:37:37 <sipa> it's it git master
340 2014-10-23 15:54:49 <Adlai> to learn of git master, first you must master git
341 2014-10-23 16:33:17 <chmod755> full node upgraded to version 99900
342 2014-10-23 16:36:51 <xiando> "It turns out that by exploiting a Bitcoin built-in reputation based DoS protection an attacker is able to force specific Bitcoin peers to ban Tor Exit nodes of her choice" http://arxiv.org/pdf/1410.6079v1.pdf  Is this claim true?
343 2014-10-23 16:45:45 <jgarzik> xiando, mostly true.  Devil is in the details and behavior.
344 2014-10-23 16:49:11 <helo> will tor-proxied nodes ever receive hidden service addresses through the network, if they don't use addnode/connect to one?
345 2014-10-23 17:26:08 <michagogo> helo: what do you mean?
346 2014-10-23 17:28:21 <helo> michagogo: when using -tor=[..] to proxy, will bitcoind just be connecting to ipv4 addresses through a tor relay, or will it somehow get rumored .onion hosts to connect to (thus avoiding exit relays and many of the problems in the pdf above)
347 2014-10-23 17:28:38 <michagogo> -tor=foo?
348 2014-10-23 17:28:42 <michagogo> That's deprecated
349 2014-10-23 17:28:48 <michagogo> (if it hasn't already been removed)
350 2014-10-23 17:29:07 <michagogo> It's replaced by onion=
351 2014-10-23 17:29:16 <michagogo> Because what it does isn't tell it to use tor
352 2014-10-23 17:29:40 <michagogo> If you want a tor-only node, you want proxy=127.0.0.1:9050
353 2014-10-23 17:29:49 <michagogo> or whatever address/port you have tor listening on
354 2014-10-23 17:30:16 <michagogo> The onion option, and previously the tor option, tells it what proxy to use specifically for tor addresses
355 2014-10-23 17:30:25 <michagogo> that is, for .onions
356 2014-10-23 17:31:01 <michagogo> So you can connect to ipv4 peers over ipv4 and onion peers over tor
357 2014-10-23 17:33:59 <helo> err right, does proxy=[..] alone allow the discover of .onion hosts?
358 2014-10-23 17:43:32 <Luke-Jr> BTW, in case anyone here is missing out…  http://www.reddit.com/r/IAmA/comments/2k3u97/we_are_bitcoin_sidechain_paper_authors_adam_back/
359 2014-10-23 17:50:27 <michagogo> helo: yes AIUI
360 2014-10-23 18:10:48 <gavinandresen> Opinions wanted: does IsInitialBlockDownload() make sense for regression-test mode?  Reason I ask: I’m writing a regression test that creates chains with specific block timestamps. That is more difficult because if I create blocks ‘in the past’ they are not relayed to peers, because they smell like IsInitialDownload()
361 2014-10-23 18:11:44 <gavinandresen> I’m waffling between implementing -regtest is never in initial download, and using getblock/submitblock instead of p2p to relay ‘old’ blocks
362 2014-10-23 18:24:16 <elichai2> petertodd was here lately?
363 2014-10-23 18:44:46 <gavinandresen> … SO tempted to answer elichai2 with “no, he’s not around right now, but I can answer for him. What’s up?”    …. must resist……
364 2014-10-23 18:45:06 <elichai2> gavinandresen, it's about his 'replace-by-fee' tool
365 2014-10-23 18:47:32 <btcdrak> gavinandresen: :)
366 2014-10-23 18:48:20 <jgarzik> heh
367 2014-10-23 18:48:43 <jgarzik> gavinandresen, RE IsInitiall.... IMO no 99% of the time :)
368 2014-10-23 18:48:46 <jgarzik> but not 100%
369 2014-10-23 18:49:20 <gavinandresen> jgarzik: yeah…  I decided to go with use getblock/submitblock to create the ‘old’ chain
370 2014-10-23 18:49:52 <jgarzik> gavinandresen, regtest turns off checkpoints, I presume?
371 2014-10-23 18:50:12 <gavinandresen> I think it just has a checkpoint that is the genesis hash
372 2014-10-23 18:51:32 <jgarzik> indeed
373 2014-10-23 19:49:33 <marek_> ahoy