1 2011-11-25 00:00:40 <graingert> tcatm: heya
  2 2011-11-25 00:00:59 <graingert> tcatm: https://github.com/graingert/bitcoin.org Created new download system, based off of Pidgin.im
  3 2011-11-25 00:02:22 <graingert> not yet finished
  4 2011-11-25 00:02:25 <tcatm> *clones repo*
  5 2011-11-25 00:02:31 <graingert> just showing direction
  6 2011-11-25 00:03:19 <graingert> not sure if it will work - as I don't want to push it live
  7 2011-11-25 00:03:35 <graingert> have you got a dev host?
  8 2011-11-25 00:03:40 <graingert> only added ubuntu
  9 2011-11-25 00:04:05 <graingert> and no scripts yet
 10 2011-11-25 00:04:22 <graingert> but I'm trying to get it to degrade nicely with <noscript>
 11 2011-11-25 00:04:24 <luke-jr_> graingert: Pidgin.im only has one program
 12 2011-11-25 00:04:36 <luke-jr_> graingert: Bitcoin.org should have all the functional Bitcoin clients (3 so far)
 13 2011-11-25 00:04:45 <tcatm> graingert: jekyll --server --auto -> localhost:4000
 14 2011-11-25 00:04:55 <luke-jr_> and probably both stable and development versions at least
 15 2011-11-25 00:06:48 <tcatm> I'd suggest using the same layout as in post.html (span5 as sidebar + span11 for content)
 16 2011-11-25 00:06:57 <graingert> ah
 17 2011-11-25 00:06:59 <graingert> kk
 18 2011-11-25 00:07:07 <graingert> not the built in sidebar?
 19 2011-11-25 00:08:06 <graingert> yo
 20 2011-11-25 00:08:20 <tcatm> nope. that's for the fluid layout but I think we should use a fixed layout for now
 21 2011-11-25 00:08:25 <graingert> okay
 22 2011-11-25 00:09:13 <tcatm> you can add class="unstyled" to <ul> to remove the bullets
 23 2011-11-25 00:09:25 <graingert> ah yes
 24 2011-11-25 00:09:30 <graingert> send me une pull
 25 2011-11-25 00:09:33 <luke-jr_> graingert: how's it show the multiple clients/versions? :p
 26 2011-11-25 00:12:26 <graingert> it doesn't at the moment
 27 2011-11-25 00:12:32 <graingert> as it only works for ubuntu
 28 2011-11-25 00:12:42 <graingert> but you could add the clients to each page
 29 2011-11-25 00:12:46 <graingert> eg
 30 2011-11-25 00:13:20 <graingert> download/windows.html > could have a list of versions
 31 2011-11-25 00:13:35 <luke-jr_> >_<
 32 2011-11-25 00:13:44 <graingert> I'm not sure people are really that bothered about old versions
 33 2011-11-25 00:13:57 <luke-jr_> not talking about old.
 34 2011-11-25 00:14:09 <graingert> do you mean things like MultiBit?
 35 2011-11-25 00:14:13 <luke-jr_> like 0.5.0 and 0.6.0 beta 1
 36 2011-11-25 00:14:31 <luke-jr_> for clients, I mean bitcoind, wxBitcoin, and Bitcoin-Qt
 37 2011-11-25 00:14:38 <luke-jr_> (probably in reverse order)
 38 2011-11-25 00:15:04 <graingert> keep bitcoind, any unsupported or unreleased versions hidden
 39 2011-11-25 00:15:15 <graingert> technical people will know how to get those
 40 2011-11-25 00:15:48 <luke-jr_> well, at least RCs probably need more end user testing
 41 2011-11-25 00:16:07 <luke-jr_> in any case, that still leaves Bitcoin-Qt 0.5.0 and wxBitcoin 0.4.1
 42 2011-11-25 00:16:25 <graingert> keep bitcoind, any unsupported, unreleased or unmaintained versions hidden
 43 2011-11-25 00:16:26 <tcatm> I don't think we should hide information. Just make the important stuff more promiment.
 44 2011-11-25 00:16:39 <graingert> that's what I meant by hidden
 45 2011-11-25 00:16:48 <graingert> beta etc can be seen on github
 46 2011-11-25 00:17:01 <graingert> and when you see the ubuntu repo you can see the release channels
 47 2011-11-25 00:17:56 <luke-jr_> graingert: RC isn't beta; RC needs testing
 48 2011-11-25 00:18:04 <luke-jr_> and again, that still leaves Bitcoin-Qt 0.5.0 and wxBitcoin 0.4.1
 49 2011-11-25 00:18:23 <tcatm> agreed, though RC should *never* be used in production
 50 2011-11-25 00:18:50 <luke-jr_> yes, RCs should be clearly noted as such
 51 2011-11-25 00:19:06 <luke-jr_> but should be more prominent so people DO test them
 52 2011-11-25 00:19:19 <tcatm> I imagine some kind of table layout could work for older versions and RCs
 53 2011-11-25 00:19:28 <luke-jr_> so when 0.6 RCs come out, keep 0.5.x as the main release, but show RCs as a testing option
 54 2011-11-25 00:19:29 <tcatm> rows for versions, columns for operating system download links
 55 2011-11-25 00:19:53 <luke-jr_> tcatm: sounds like a good idea, but what about multiple clients?
 56 2011-11-25 00:19:59 <graingert> wxBitcoin is unmaintained
 57 2011-11-25 00:20:01 <tcatm> multiple clients?
 58 2011-11-25 00:20:06 <luke-jr_> graingert: 0.4.1 was just released.
 59 2011-11-25 00:20:06 <tcatm> like 0.4.1 and 0.5.0?
 60 2011-11-25 00:20:14 <graingert> who maintains it?
 61 2011-11-25 00:20:21 <luke-jr_> tcatm: like wxBitcoin and Bitcoin-Qt, and bitcoind
 62 2011-11-25 00:20:31 <luke-jr_> graingert: Gavin and I cobbled together 0.4.1
 63 2011-11-25 00:20:36 <tcatm> I'd just show 0.4.1 under older versions for now (as it has a lower version number than 0.5.0)
 64 2011-11-25 00:20:47 <graingert> keep bitcoind, any unsupported, unreleased, unmaintained or cobbled together versions hidden
 65 2011-11-25 00:20:58 <tcatm> maybe add a terse changelog below each version with the most important stuff
 66 2011-11-25 00:21:40 <luke-jr_> graingert: all Bitcoin clients today are cobbled together :0
 67 2011-11-25 00:21:58 <luke-jr_> wxBitcoin should be just as prominent than Bitcoin-Qt right now
 68 2011-11-25 00:22:07 <graingert> keep bitcoind, any unsupported, unreleased, unmaintained or wx versions hidden
 69 2011-11-25 00:22:14 <luke-jr_> Bitcoin-Qt may be the future, but wxBitcoin is what most people use and has been much better tested
 70 2011-11-25 00:22:32 <graingert> this is now way too political for me
 71 2011-11-25 00:22:42 <luke-jr_> graingert: you're the only one forcing politics on it :P
 72 2011-11-25 00:23:05 <graingert> I advocate a simple download interface
 73 2011-11-25 00:23:13 <graingert> with only the latest stable version provided
 74 2011-11-25 00:24:10 <luke-jr_> graingert: you advocate a centralized system
 75 2011-11-25 00:24:20 <luke-jr_> wxBitcoin 0.4.1 is more stable than Bitcoin-Qt 0.5.0
 76 2011-11-25 00:24:42 <graingert> we're going to need a blockchain for bitcoin clients
 77 2011-11-25 00:25:04 <luke-jr_> nonsense, just don't run bitcoin.org in a biased manner
 78 2011-11-25 00:25:15 <graingert> against whom?
 79 2011-11-25 00:25:20 <graingert> or for whom?
 80 2011-11-25 00:25:24 <tcatm> luke-jr_: contribute actual code. that will get us somewhere :)
 81 2011-11-25 00:25:42 <luke-jr_> graingert: the point is NO bias.
 82 2011-11-25 00:25:50 <luke-jr_> tcatm: fair enough :P
 83 2011-11-25 00:26:45 <graingert> and overcomplicate the site
 84 2011-11-25 00:26:54 <graingert> perhaps
 85 2011-11-25 00:26:59 <luke-jr_> http://xmpp.org/xmpp-software/clients/ <-- better for bitcoin.org at least in the long run
 86 2011-11-25 00:27:02 <graingert> /download/advanced.html
 87 2011-11-25 00:27:18 <tcatm> /download/archive.html would be good I think
 88 2011-11-25 00:27:27 <luke-jr_> graingert: two options "original client" and "next gen client" is not overcomplicated
 89 2011-11-25 00:27:41 <luke-jr_> tcatm: we're talking about two CURRENT clients :p
 90 2011-11-25 00:27:48 <graingert> I want to include clients like bitcoinj, MultiBit etc
 91 2011-11-25 00:27:57 <tcatm> I'm thinking about all previous versions.
 92 2011-11-25 00:28:02 <graingert> perhaps in alternative-clients.html
 93 2011-11-25 00:28:05 <tcatm> i.e. down to 0.1.5
 94 2011-11-25 00:28:10 <graingert> we could show a list like xmpp have
 95 2011-11-25 00:28:24 <graingert> and then in archive.html we show older versions
 96 2011-11-25 00:28:26 <luke-jr_> afaik BitcoinJ/MultiBit don't work yet
 97 2011-11-25 00:28:45 <tcatm> so one purpose of the archive page would to show release dates for all bitcoin versions
 98 2011-11-25 00:28:47 <luke-jr_> tcatm: in the case of Bitcoin, I don't think we should help anyone get old stuff
 99 2011-11-25 00:28:48 <graingert> not what the site shows
100 2011-11-25 00:29:06 <luke-jr_> old stuff = security/compatibility issues
101 2011-11-25 00:29:16 <graingert> luke-jr_: just downloading MultiBit
102 2011-11-25 00:29:29 <tcatm> luke-jr_: a warning message will suffice
103 2011-11-25 00:29:36 <graingert> you're the one advocating old stuff
104 2011-11-25 00:29:46 <luke-jr_> graingert: no, I'm only advocating current releases
105 2011-11-25 00:29:51 <luke-jr_> wxBitcoin 0.4.1 and Bitcoin-Qt 0.5.0
106 2011-11-25 00:31:24 <graingert> luke-jr_: multibit seems to work fine with me
107 2011-11-25 00:31:42 <graingert> syncing with network is unnervingly fast
108 2011-11-25 00:32:04 <graingert> I thought it was an SPV anyway
109 2011-11-25 00:33:44 <tcatm> graingert: wget -O- http://pastebin.com/raw.php?i=ReH3Sq9L|git am
110 2011-11-25 00:33:56 <graingert> ?
111 2011-11-25 00:33:57 <luke-jr_> graingert: 0.1.3?
112 2011-11-25 00:34:18 <luke-jr_> if their latest stable release works, I see no reason not to put it on the site too
113 2011-11-25 00:34:30 <graingert> tcatm: what's wrong with github :p
114 2011-11-25 00:34:49 <tcatm> it's easier this way :)
115 2011-11-25 00:35:06 <graingert> I'd recommend making a new branch on the official repo
116 2011-11-25 00:35:53 <luke-jr_> MultiBit seems to use "nanocoins" to refer to satoshis :|
117 2011-11-25 00:35:54 <luke-jr_> ugly
118 2011-11-25 00:36:08 <graingert> right I'm off to bed
119 2011-11-25 00:36:09 <luke-jr_> why do people love SI so much yet fail so hard at using it right?
120 2011-11-25 00:38:45 <tcatm> ;;later tell graingert download page branch: https://github.com/bitcoin/bitcoin.org/tree/downloadpage
121 2011-11-25 00:38:46 <gribble> The operation succeeded.
122 2011-11-25 02:37:44 <Diablo-D3> lol
123 2011-11-25 02:37:48 <Diablo-D3> I almost have 666 karma on HN
124 2011-11-25 02:38:59 <btginsb> has anyone been having issues with the mtgox api lately?
125 2011-11-25 02:51:58 <btginsb> has anyone been having issues with the mtgox api lately?
126 2011-11-25 02:52:21 <BlueMatt> ask in #mtgox maybe?
127 2011-11-25 02:52:34 <btginsb> alright
128 2011-11-25 02:52:35 <BlueMatt> I think MagicalTux might be online
129 2011-11-25 07:27:45 <FellowTraveler> hi all
130 2011-11-25 07:59:49 <Lolcust_Backup> FellowTraveler hi fellow traveler !
131 2011-11-25 08:38:17 <CIA-89> bitcoinj: hearn@google.com * r261 /trunk/src/com/google/bitcoin/core/Message.java: Minor comment reformatting, dead code elimination.
132 2011-11-25 08:57:01 <CIA-89> bitcoinj: hearn@google.com * r262 /trunk/tests/com/google/bitcoin/core/SpeedTest.java: Remove SpeedTest as it's not generally useful to have in the test suite.
133 2011-11-25 08:58:27 <CIA-89> bitcoinj: hearn@google.com * r263 /trunk/ (TODO tests/com/google/bitcoin/core/Manipulator.java): Delete some dead code.
134 2011-11-25 09:12:34 <CIA-89> bitcoinj: hearn@google.com * r264 /trunk/src/com/google/bitcoin/core/Message.java: Make bitcoinSerialize() return a copy by default, provide an unsafeBitcoinSerialize() method for high performance applications that are willing to deal with the extra API complexity.
135 2011-11-25 09:34:59 <c_k> hmm, still only seeing ~12 connections with vanilla 0.5.0 daemon configured for maxconnections=256 -_-
136 2011-11-25 09:39:38 <SomeoneWeird> port forwardeedd?
137 2011-11-25 09:44:07 <c_k> SomeoneWeird: it won't do over 8 without port forwarded, right?
138 2011-11-25 09:44:18 <c_k> hmm
139 2011-11-25 09:44:20 <c_k> actually
140 2011-11-25 09:44:20 <SomeoneWeird> not sure
141 2011-11-25 09:44:25 <c_k> you're right
142 2011-11-25 09:44:34 <c_k> I opened the port on an aliased IP
143 2011-11-25 09:44:47 <c_k> not the IP others will see the connection coming from
144 2011-11-25 09:45:15 <c_k> thanks ;)
145 2011-11-25 09:45:19 <SomeoneWeird> :)
146 2011-11-25 10:37:34 <CIA-89> bitcoinj: hearn@google.com * r265 /trunk/pom.xml: POM for 0.3 release
147 2011-11-25 11:41:41 <wereHamster> what? google interested in bitcoin?
148 2011-11-25 11:50:10 <wumpus> not so much google itself, I think, but a google employee wrote bitcoinj
149 2011-11-25 11:53:36 <dennisn> i posted yesterday, about troubles after upgrading to 0.5
150 2011-11-25 11:54:20 <dennisn> my node doesn't seem to be working properly... i can't "listaccounts" or do most commands. (I can still "getinfo")
151 2011-11-25 11:54:37 <dennisn> in bitcoind, if i try to "listaccounts", all i get is: error: {"code":-2,"message":"Safe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."}
152 2011-11-25 11:55:01 <dennisn> debug.log continuously shows error messages like: ERROR: ConnectInputs() : 4fa541d5e3 mapTransactions prev not found c45e2db502
153 2011-11-25 11:55:10 <dennisn> ERROR: AcceptToMemoryPool() : ConnectInputs failed 4fa541d5e3
154 2011-11-25 11:55:19 <dennisn> and i don't think it's downloading any blocks since i upgraded
155 2011-11-25 11:55:23 <dennisn> (from 0.3.24)
156 2011-11-25 11:55:38 <dennisn> "getblockcount" says 153681
157 2011-11-25 11:57:42 <denisx> dennisn: maybe you should start with a fresh blockchain
158 2011-11-25 11:57:50 <denisx> seems corrupt
159 2011-11-25 11:58:03 <dennisn> i will try that :p
160 2011-11-25 12:05:07 <dennisn> denisx, deleting and restarting the blockchain seemed to fix it
161 2011-11-25 12:05:21 <denisx> good
162 2011-11-25 12:05:27 <dennisn> so, in conclusion, my upgrade to 0.5 screwed up my blockchain :(
163 2011-11-25 12:55:22 <CIA-89> bitcoinj: hearn@google.com * r266 /wiki/UsingMaven.wiki: Edited wiki page UsingMaven through web user interface.
164 2011-11-25 13:04:04 <CIA-89> bitcoinj: hearn@google.com * r267 /trunk/src/com/google/bitcoin/core/VersionMessage.java: Set version to 0.3 in the version message
165 2011-11-25 13:04:14 <CIA-89> bitcoinj: hearn@google.com * r268 /trunk/pom.xml: Correct typo in the POM file.
166 2011-11-25 13:14:03 <CIA-89> bitcoinj: hearn@google.com * r269 /trunk/ (pom.xml src/com/google/bitcoin/core/VersionMessage.java): Bump version to 0.4-SNAPSHOT, switch the subVer field to use genjixs BIP 14 format.
167 2011-11-25 13:23:50 <CIA-89> bitcoinj: hearn@google.com * r270 /wiki/ReleaseNotes.wiki: Added a release notes page
168 2011-11-25 15:06:24 <Rahar> Hi ppl! We are porting bitcoin client to ANSI C and my question is , is there any additional functionality that users want to see in bitcoin client?
169 2011-11-25 15:19:37 <luke-jr> &
170 2011-11-25 15:20:18 <roconnor> does porting to ANSI C make the code portable to other endianness?
171 2011-11-25 15:20:46 <[Tycho]> I really like ANSI C.
172 2011-11-25 15:20:53 <luke-jr> ANSI C is deprecated.
173 2011-11-25 15:20:58 <luke-jr> C99 is current.
174 2011-11-25 15:21:14 <[Tycho]> Well, any C without ++ will do.
175 2011-11-25 15:21:29 <edcba> C# ?
176 2011-11-25 15:21:33 <lianj> he should port his irc connection to native
177 2011-11-25 15:22:14 <luke-jr> dunno, I think C++ might be a better fit for Bitcoin clients
178 2011-11-25 15:22:25 <luke-jr> doesn't preclude a C-compatible API ofc
179 2011-11-25 15:22:31 <[Tycho]> !# is managed, AFAIK. Managed code is bad.
180 2011-11-25 15:26:07 <edcba> why ?
181 2011-11-25 15:27:13 <[Tycho]> I like direct execution, without overhead and additional possible bugs.
182 2011-11-25 15:27:24 <edcba> haha
183 2011-11-25 15:27:31 <edcba> you like buffer overflows :)
184 2011-11-25 15:28:32 <[Tycho]> I don't do buffer overflows :)
185 2011-11-25 15:32:33 <roconnor> [Tycho]: how do you avoid buffer overflows?
186 2011-11-25 15:34:00 <[Tycho]> By using some special street magic.
187 2011-11-25 15:35:39 <roconnor> I learned this week that (software) buffer overflows in infusion pumps have killed people.
188 2011-11-25 15:36:10 <[Tycho]> Yeah, you can even kill people with C !
189 2011-11-25 15:36:30 <roconnor> ANSI C!
190 2011-11-25 15:38:37 <luke-jr> managed code doesn't avoid buffer overflows
191 2011-11-25 15:38:45 <luke-jr> it just means you have someone else to blame when you encounter them
192 2011-11-25 15:38:47 <luke-jr> :p
193 2011-11-25 15:39:18 <roconnor> luke-jr: C# isn't garbage collected?
194 2011-11-25 15:39:27 <luke-jr> roconnor: irrelevant
195 2011-11-25 15:39:37 <[Tycho]> It just doesn't feels like something serious. Closer to bytecode BASIC :)
196 2011-11-25 15:41:20 <roconnor> luke-jr: doesn't C# use memory management?
197 2011-11-25 15:41:47 <[Tycho]> But may be soon I'll have to use it for making deepbit app on Windows Phone :)
198 2011-11-25 15:43:16 <roconnor> oh I guess bounds checking and garbage collection are technically unrelated.
199 2011-11-25 15:45:09 <roconnor> [Tycho]: I think that if you care about direct execution you should be writing mircocode rather than using C.
200 2011-11-25 15:45:38 <[Tycho]> It's not platform-independent.
201 2011-11-25 15:46:00 <roconnor> [Tycho]: direct execution is clearly platform dependent.
202 2011-11-25 15:47:54 <[Tycho]> http://cs10310.vk.com/u711677/92580232/y_4f95b9de.jpg
203 2011-11-25 15:48:20 <abragin> :-))))
204 2011-11-25 15:49:10 <roconnor> :)
205 2011-11-25 15:50:45 <[Tycho]> abragin, it's all your fault.
206 2011-11-25 15:51:33 <luke-jr> roconnor: C# is implemented in unmanaged code.
207 2011-11-25 15:51:58 <abragin> btw, there is a so-called Managed C
208 2011-11-25 15:52:08 <abragin> which indeed sucks deeply
209 2011-11-25 15:52:30 <[Tycho]> Quake C ?
210 2011-11-25 15:52:55 <abragin> Quake C brings good memories
211 2011-11-25 15:55:26 <CIA-89> bitcoinj: hearn@google.com * r271 /trunk/pom.xml: Switch to JDK logging and add a simple formatter that is more concise than the default Java one.
212 2011-11-25 15:56:39 <CIA-89> bitcoinj: hearn@google.com * r272 /trunk/src/com/google/bitcoin/ (utils utils/BriefLogFormatter.java examples/PingService.java): Switch to JDK logging and add a simple formatter that is more concise than the default Java one.
213 2011-11-25 17:18:17 <graingert> abragin: you mean Managed C++
214 2011-11-25 17:18:30 <abragin> Yes certainly
215 2011-11-25 18:01:04 <osmosis> I like the new qt gui, but i has a loss of display information. There should be a way to toggle on blockcount displays.
216 2011-11-25 18:03:01 <BlueMatt> but it is also a number that most users dont need to care about
217 2011-11-25 18:04:18 <nanotube> time for "advanced mode" option that turns on extra info display :)
218 2011-11-25 18:05:07 <luke-jr> osmosis: it's in the tooltip
219 2011-11-25 18:05:36 <BlueMatt> which is (imho) a pretty good compromise
220 2011-11-25 18:16:20 <osmosis> ok, tooltip is easier then right clicking to properties like i was doing
221 2011-11-25 18:22:49 <luke-jr> lol
222 2011-11-25 18:23:04 <luke-jr> there is no rightclick& O.o
223 2011-11-25 18:25:58 <[Tycho]> Is there anyone planning to use green addresses ?
224 2011-11-25 18:28:42 <BlueMatt> green addresses?
225 2011-11-25 18:39:38 <[Tycho]> BlueMatt: yes
226 2011-11-25 18:41:59 <BlueMatt> what are those again?
227 2011-11-25 18:42:10 <[Tycho]> You are joking, right ? :)
228 2011-11-25 18:44:14 <[Tycho]> It's a trust-related idea, supported by mtgox, instawallet and me.
229 2011-11-25 18:44:39 <gmaxwell> BlueMatt: this is that crazy thing that mtgox does where they pay you by first sending the funds to a well known address. Then you 'know' the funds come from a trusted source based on the pubkey signing the input on the payment to you.
230 2011-11-25 18:44:58 <[Tycho]> We publish our carefully selected "green" address and others may accept 0-confirmation TXes if they trust the owner.
231 2011-11-25 18:45:29 <[Tycho]> MtGox is doing it completely wrong, with 2 TXes per operation.
232 2011-11-25 18:46:26 <gmaxwell> As I mentioned before, they do it that way intentionally in order to avoid keeping a bunch of funds tied to the green address. ::shrugs::
233 2011-11-25 18:47:08 <BlueMatt> gmaxwell: oh, thats worthless
234 2011-11-25 18:47:59 <gmaxwell> BlueMatt: I tried to convince mtgox they should be using something like sipa's payment protocol, but MagicalTux said that it wasn't sufficiently arms length with the payee. They don't want to know who you're paying.
235 2011-11-25 18:48:58 <[Tycho]> Also, they don't need to keep bunch of funds tied to it. Adding 0.01 input from green address will be enough to "sign" the trasaction.
236 2011-11-25 18:51:36 <gmaxwell> They keep a bunch of funds tied to other addresses anyways. ::shrugs:: The additional input still bloats the blockchain, though not as bad as two txn.
237 2011-11-25 18:51:37 <BlueMatt> gmaxwell: Id bet the reason they do that is so that eligius can easily identify which txes to accept blindly, not because they think anyone cares what src their coins come from
238 2011-11-25 18:51:45 <BlueMatt> gmaxwell: which is retarded
239 2011-11-25 18:52:04 <gmaxwell> BlueMatt: nah, has nothing to do with eligius there they already have a socket based thing to tell eligius which txn to accept.
240 2011-11-25 18:52:25 <BlueMatt> then why do they bother?
241 2011-11-25 18:52:48 <BlueMatt> oh, heh good point if they had been doing it that way, those broken txes wouldnt have gone through...
242 2011-11-25 18:53:00 <gmaxwell> BlueMatt: so people (merchants) will accept zero confirm payments from them.
243 2011-11-25 18:53:42 <gmaxwell> (as they, reasonably, trust mtgox to not double spend)
244 2011-11-25 18:58:10 <BlueMatt> heh, thats not the right way to be doing it...if two merchants are trying to setup a system by which their users can pay each others quickly, they should just carry a balance between each other and just transfer that (they already trust each other...)
245 2011-11-25 18:59:51 <gmaxwell> BlueMatt: Magicaltux wants to pretend he doesn't know funds are being sent to silkroad.
246 2011-11-25 19:02:13 <BlueMatt> heh, thats true...
247 2011-11-25 19:02:31 <[Tycho]> Oh, so that's the cause...
248 2011-11-25 19:03:17 <BlueMatt> though I would argue he should actively inconvenience silkroad users by not doing it...
249 2011-11-25 19:03:38 <graingert> how does green addressing mean he won't know about it
250 2011-11-25 19:03:42 <[Tycho]> Why ?
251 2011-11-25 19:04:01 <gmaxwell> graingert: because there is no communication with the reciever of the funds.
252 2011-11-25 19:04:11 <gmaxwell> graingert: it's just an opaque address.
253 2011-11-25 19:04:33 <graingert> I don't see how that's worse than not doing it at all
254 2011-11-25 19:04:34 <BlueMatt> if he carried a balance for silk road he would know where the funds are going
255 2011-11-25 19:04:49 <graingert> okay
256 2011-11-25 19:04:57 <gmaxwell> carried a balance, or used some other trust confirming payment protocol.
257 2011-11-25 19:04:57 <graingert> I doubt he wants to make a deal with SR
258 2011-11-25 19:05:11 <graingert> Green addressing is clearly better than carried balence
259 2011-11-25 19:05:26 <graingert> works in the general
260 2011-11-25 19:05:33 <graingert> and requires minimal aggreement
261 2011-11-25 19:05:55 <gmaxwell> It's not better, it increases to doubles the load on the blockchain.
262 2011-11-25 19:06:08 <gmaxwell> And it harms privacy.
263 2011-11-25 19:06:18 <gmaxwell> Becuase the whole world can see one party to the transaction.
264 2011-11-25 19:06:18 <graingert> it's optional
265 2011-11-25 19:06:22 <graingert> so who cares
266 2011-11-25 19:06:41 <gmaxwell> graingert: and do you think I'd make that accusation lightly?
267 2011-11-25 19:06:44 <graingert> and they have to pay the fee like everyone else
268 2011-11-25 19:06:50 <graingert> yes
269 2011-11-25 19:07:07 <gmaxwell> graingert: mtgox doesn't pay a fee.
270 2011-11-25 19:07:19 <graingert> yes they do
271 2011-11-25 19:07:24 <graingert> just not in band
272 2011-11-25 19:07:38 <graingert> I presume luke-jr makes money from the mtgox deal
273 2011-11-25 19:07:57 <gmaxwell> graingert: No, they provide free hosting to a pool, which is net profitable for them because luke also pays half the fees he gets.
274 2011-11-25 19:08:09 <graingert> ah I ssee
275 2011-11-25 19:08:13 <graingert> see*
276 2011-11-25 19:08:20 <graingert> okay so they pay for hosting
277 2011-11-25 19:08:26 <graingert> it's still a "fee"
278 2011-11-25 19:08:55 <gmaxwell> Yes, but they have pretty unequal access to this method compared to other bitcoin users.
279 2011-11-25 19:08:55 <[Tycho]> There was even a link to Eligius at the mtgox.
280 2011-11-25 19:09:00 <[Tycho]> But not now.
281 2011-11-25 19:09:48 <[Tycho]> What method ?
282 2011-11-25 19:10:58 <gmaxwell> [Tycho]: bouncing the funds through a green address and using a zero confirm input in the process.
283 2011-11-25 19:11:23 <[Tycho]> Other users don't need to do it.
284 2011-11-25 19:11:39 <gmaxwell> ...
285 2011-11-25 19:11:51 <[Tycho]> They can 1) keep some spare coins at the green address and just direct the change at it.
286 2011-11-25 19:12:12 <[Tycho]> 2) use 0.01 green inputs
287 2011-11-25 19:12:20 <[Tycho]> 3) other ways to do it
288 2011-11-25 19:12:48 <[Tycho]> MtGox uses the worst possible method.
289 2011-11-25 19:14:26 <graingert> green inputs is a cool ide
290 2011-11-25 19:14:29 <graingert> a
291 2011-11-25 19:14:40 <gmaxwell> It's all still terrible.
292 2011-11-25 19:15:25 <gmaxwell> You're burdening the whole bitcoin network to store your ephemerial trust data _forever_... and diminishing your own privacy at the same time, because now everyone knows the identity of one party of the transaction.
293 2011-11-25 19:16:07 <[Tycho]> All other data is also stored forever, it's somehow has more rights to be stored ?
294 2011-11-25 19:16:32 <Eliel> gmaxwell: hmm? I thought old transactions can be pruned once they're spent.
295 2011-11-25 19:16:35 <gmaxwell> Yes! because the other data is important to everyone because it's required to prove that no one is cheating and inflating the balance of bitcoins.
296 2011-11-25 19:16:35 <[Tycho]> Some guy buys a candy for 0.01 and this info will be stored FOREVER !
297 2011-11-25 19:17:08 <gmaxwell> Eliel: they can't be completely forgotten or you can't bring a new node online.
298 2011-11-25 19:17:48 <[Tycho]> This trust data is important too.
299 2011-11-25 19:17:56 <gmaxwell> [Tycho]: I don't think its crazy to draw a hard line for information which is necessary for running the currency and preventing double spending and information which is a _private_ _communication_ between two parties and irrelevant to bitcoin.
300 2011-11-25 19:18:05 <gmaxwell> It is important but only to the reciever. No one else.
301 2011-11-25 19:18:21 <gmaxwell> Making it highly public damanages the reciever's privacy, in fact. He'd rather it not be.
302 2011-11-25 19:18:33 <graingert> simply signing transaction ID's would be lighter on the bitcoin chain
303 2011-11-25 19:18:41 <[Tycho]> My green implementation is not making my TXes bigger. Even 9% smaller.
304 2011-11-25 19:19:07 <Eliel> [Tycho]: how does that work?
305 2011-11-25 19:19:10 <[Tycho]> And everyone already knows who the sender is.
306 2011-11-25 19:19:21 <gmaxwell> [Tycho]: false comparison. You could use pubkey change without green addresses.
307 2011-11-25 19:19:40 <[Tycho]> gmaxwell: at least it's not bigger.
308 2011-11-25 19:19:44 <Eliel> oh, compressed pubkey?
309 2011-11-25 19:19:47 <gmaxwell> You're taking an additional input.
310 2011-11-25 19:20:13 <[Tycho]> Eliel: http://blockexplorer.com/tx/866bc08c929d5df1de1d80380edbf60d54a5b260845d57e19a9a93ed03edcd38
311 2011-11-25 19:20:19 <[Tycho]> No, I'm not.
312 2011-11-25 19:21:35 <gmaxwell> Fine enough, in your case you can actually do a zero overhead implementation.. presumably you mine directly to that pubkey too?
313 2011-11-25 19:21:58 <[Tycho]> Not currently, but this is possible.
314 2011-11-25 19:23:25 <gmaxwell> This still requires overhead (either a bounce txn, or generating a bunch of 0.01 dust inputs) for parties that need to use multiple payment addresses for their inputs to distinguish input targets.
315 2011-11-25 19:23:51 <[Tycho]> What do you mean ?
316 2011-11-25 19:24:17 <[Tycho]> They can refill the green address once per many sends, not every time.
317 2011-11-25 19:24:55 <[Tycho]> By the way, do Instawallet owner visits IRC ?
318 2011-11-25 19:25:01 <gmaxwell> They need to refill it with many inputs, or they'll be stuck respending zero confirm change. I agree not every time. But also not 'once ever'.
319 2011-11-25 19:25:46 <gmaxwell> And I don't understand why you've dismissed the privacy concern it's _usually_ not the case that everyone knows who one party to the txn is. Bitcoin software works fairly hard to hide that.
320 2011-11-25 19:26:05 <gmaxwell> This is the only source of privacy in the system at all. Without it your nosey inlaws know your every purchase.
321 2011-11-25 19:26:24 <[Tycho]> In MY case everyone already knows the source of funds.
322 2011-11-25 19:27:23 <gmaxwell> ::nods:: Right, I don't mean to argue that your usage is terrible, but that doesn't make this a good general mechenism. For _your_ case you could simply put up a file with a list of your recent txn ids and people could check against it, too.
323 2011-11-25 19:27:59 <gmaxwell> (but that doesn't necessarily work more generally)
324 2011-11-25 19:28:47 <[Tycho]> Well, I can invent a scheme to use another addresses for change, and then re-mint it.
325 2011-11-25 19:29:24 <[Tycho]> Or something less dangerous.
326 2011-11-25 19:30:20 <[Tycho]> I hope someone will come up with appropriate ideas, but currently there is only one - green addresses.
327 2011-11-25 19:30:48 <[Tycho]> Additional signatures may work too, but it's more difficult to use.
328 2011-11-25 19:31:02 <gmaxwell> No, there is a whole other proposal.  https://gist.github.com/1237788
329 2011-11-25 19:32:24 <[Tycho]> It's out-of-band ?
330 2011-11-25 19:32:43 <gmaxwell> Yes.
331 2011-11-25 19:35:41 <[Tycho]> That's not funny :(
332 2011-11-25 19:45:02 <osmosis> cool proposal
333 2011-11-25 20:01:35 <luke-jr> [Tycho]: nonsense.
334 2011-11-25 20:01:42 <[Tycho]> Where ?
335 2011-11-25 20:01:48 <luke-jr> [Tycho]: I suggested days ago, that you can just sign the transaction with an extraneous key.
336 2011-11-25 20:02:06 <luke-jr> this also doesn't bloat the block chain, since miners can strip it off
337 2011-11-25 20:02:18 <luke-jr> but since it is relayed, the receiving end will see it
338 2011-11-25 20:03:30 <[Tycho]> How can they strip it ?
339 2011-11-25 20:03:45 <luke-jr> &
340 2011-11-25 20:03:49 <luke-jr> by removing it.
341 2011-11-25 20:04:08 <luke-jr> even if they can't strip it, it's still cheaper than adding an input
342 2011-11-25 20:04:10 <[Tycho]> Where this signature should be ?
343 2011-11-25 20:04:19 <[Tycho]> Not in the script ?
344 2011-11-25 20:04:33 <luke-jr> wherever signatures usually are
345 2011-11-25 20:08:10 <[Tycho]> I doubt about stripping
346 2011-11-25 20:55:24 <batouzo> about the conference - will there be any transmission, video or audio??
347 2011-11-25 21:05:14 <roconnor> [Tycho]: oh nice, are you using compressed public keys now, or was that just a test?
348 2011-11-25 21:05:30 <[Tycho]> No, it's not compressed.
349 2011-11-25 21:05:56 <roconnor> ah oops
350 2011-11-25 21:06:02 <roconnor> I read a bit hastily
351 2011-11-25 21:06:19 <[Tycho]> Sending AND receiving on plain pubkey takes less bytes than sending and receiving to an address.
352 2011-11-25 21:06:48 <[Tycho]> Short pubkeys can't be used in the main chain.
353 2011-11-25 21:07:05 <roconnor> AFAIK compressed keys can be used on the main chain
354 2011-11-25 21:07:12 <roconnor> in principle
355 2011-11-25 21:07:23 <roconnor> but yes, the current bitcoin client won't support them
356 2011-11-25 21:07:37 <roconnor> in that you won't see the coins in your wallet
357 2011-11-25 21:08:26 <roconnor> [Tycho]: Right, I guess there isn't a much of an advantage if any for you to use them yet.
358 2011-11-25 21:11:16 <graingert> what are compressed keys?
359 2011-11-25 21:14:06 <roconnor> graingert: they are public keys that are roughly half the size of the normal uncompressed encoding of public keys
360 2011-11-25 21:14:20 <roconnor> graingert: they take somewhat more CPU time to process, but not a lot.
361 2011-11-25 21:14:44 <graingert> link?
362 2011-11-25 21:15:10 <roconnor> https://github.com/bitcoin/bitcoin/pull/649
363 2011-11-25 21:18:19 <osmosis> whats the benefit of compressedpubkeys ?   short paste size?
364 2011-11-25 21:19:14 <osmosis> less bytes in blockchain?
365 2011-11-25 21:21:48 <roconnor> osmosis: less bytes in the blockchain
366 2011-11-25 21:22:03 <roconnor> smaller QR codes???
367 2011-11-25 21:22:09 <roconnor> I don't know, maybe they are as small as they can be
368 2011-11-25 21:23:43 <roconnor> Hmm, I thought I documented compressed keys on the wiki ... maybe I fogot to save my changes
369 2011-11-25 21:24:12 <luke-jr> lol
370 2011-11-25 21:31:20 <[Tycho]> Won't work for QR codes
371 2011-11-25 21:31:39 <graingert> a mechanism for detecting updates would be very usefull
372 2011-11-25 21:32:06 <graingert> otherwise we'll start having an IE6 issue on our hands
373 2011-11-25 21:32:11 <roconnor> [Tycho]: oh, maybe QR codes are addresses not public_keys
374 2011-11-25 21:32:19 <graingert> not sure how to do this without centralization
375 2011-11-25 21:32:31 <[Tycho]> IE6 is cool!
376 2011-11-25 21:32:46 <gmaxwell> IE6 is The Standard.
377 2011-11-25 21:32:55 <[Tycho]> This.
378 2011-11-25 21:33:00 <graingert> Standard what?
379 2011-11-25 21:33:18 <gmaxwell> graingert: It's the internet. Says so under the icon.
380 2011-11-25 21:33:20 <[Tycho]> roconnor: it's possible to use public keys in QR code, but any public key will be longer that address.
381 2011-11-25 21:33:28 <roconnor> graingert: blocks and transactions have version numbers, but they are unused at the moment.
382 2011-11-25 21:33:29 <roconnor> [Tycho]: yep
383 2011-11-25 21:33:41 <gmaxwell> Obviously satoshi screwed up. He should have called bitcoin "money".
384 2011-11-25 21:33:42 <roconnor> graingert: I've taken to inserting random version numbers in my transactions.
385 2011-11-25 21:33:48 <Diablo-D3> gm
386 2011-11-25 21:33:50 <Diablo-D3> er
387 2011-11-25 21:33:52 <Diablo-D3> gmaxwell: no!
388 2011-11-25 21:34:04 <Diablo-D3> he should have called it a security token!
389 2011-11-25 21:34:30 <Diablo-D3> gmaxwell: you know whats going to be depressing? when AMD goes bankrupt because no one buys 7xxx for mining
390 2011-11-25 21:35:00 <gmaxwell> Their GPU sales in 4Q 2010 were like 460m. Mining isn't relevant to that.
391 2011-11-25 21:35:17 <Diablo-D3> I dunno man, millions have quit nvidia for amd
392 2011-11-25 21:35:27 <denisx> sure, millions
393 2011-11-25 21:35:28 <Diablo-D3> they dont do full time mining, but thats a lot of lost nvdiai sales
394 2011-11-25 21:37:24 <gmaxwell> oh, you think that casual mining caused people to buy amd rather than nvidia? Thats.. an interesting thought.
395 2011-11-25 21:38:12 <graingert> I'm tempted for example
396 2011-11-25 21:38:19 <graingert> but for other reasons than mining alone
397 2011-11-25 21:38:28 <graingert> mining power is a minor motivator
398 2011-11-25 21:38:31 <graingert> (for me)
399 2011-11-25 21:43:52 <GMP> NVIDIA next high end chip delayed to the end of 2012, http://www.4gamer.net/games/120/G012093/20111124085/screenshot.html?num=005
400 2011-11-25 22:01:54 <coingenuity> rg you around?
401 2011-11-25 22:02:11 <coingenuity> or grubles, one of the two
402 2011-11-25 22:21:05 <batouzo> anyone 1 selling btc?
403 2011-11-25 22:39:28 <luke-jr> batouzo: for 25 USD
404 2011-11-25 22:46:28 <gmaxwell> batouzo: better buy fast bitcoin closes in about 6 days.
405 2011-11-25 22:47:06 <sipa> ?
406 2011-11-25 22:48:05 <gmaxwell> sipa: see the countdown on https://mtgox.com/
407 2011-11-25 22:49:59 <sipa> right... and then? a big secret announcement?
408 2011-11-25 22:53:25 <edcba> soon... december !!! :)
409 2011-11-25 22:54:42 <[Tycho]> Oh, so it's december !
410 2011-11-25 22:56:54 <tiz> hey guys, I'm developing a bitcoin signatures site, and i was wondering if someone would give me a hand?
411 2011-11-25 22:57:46 <gmaxwell> tiz: "bitcoin signatures site"?
412 2011-11-25 22:58:12 <tiz> yes, to display your mining hashrate from your pool via API
413 2011-11-25 22:58:21 <tiz> there was/is a site already, but they are having some problems
414 2011-11-25 22:59:07 <gmaxwell> ah, you mean those little graph images. okay. Makes sense.
415 2011-11-25 22:59:13 <tiz> exactly
416 2011-11-25 22:59:28 <gmaxwell> You can ask here but I don't know if anyone who knows anything about pool APIs is listening.
417 2011-11-25 22:59:44 <tiz> i'm mining in slush's pool atm, so i can test that API
418 2011-11-25 23:00:31 <tiz> i'm trying to do 2 things right now: 1. Get people to start using the site, hopefully once people see others signatures, the will get their own.
419 2011-11-25 23:00:42 <tiz> and 2: get more api addresses from other mining sites
420 2011-11-25 23:58:56 <graingert> tiz: link?
421 2011-11-25 23:59:09 <graingert> tiz: is it possible to link up blocks to polls using their getwork response
422 2011-11-25 23:59:13 <graingert> responce*