1 2014-11-01 01:20:40 <kamora> Hi. When is the next hard fork?
 2 2014-11-01 01:21:12 <phantomcircuit> kamora, the next scheduled hard fork is when the timestamp field overflows
 3 2014-11-01 01:21:42 <phantomcircuit> which is decades away
 4 2014-11-01 01:22:05 <kamora> Will it be adding anon?
 5 2014-11-01 01:22:37 <justanotheruser> phantomcircuit: I don't think a hardfork is necessary to fix that
 6 2014-11-01 01:23:01 <phantomcircuit> justanotheruser, i dont see how
 7 2014-11-01 01:23:28 <justanotheruser> phantomcircuit: what is the consequence?
 8 2014-11-01 01:23:40 <justanotheruser> they both should overflow in the same way
 9 2014-11-01 01:24:03 <justanotheruser> both being my actual timestamp and a blocks timestamp
10 2014-11-01 01:24:24 <justanotheruser> it would be a bit shaky during the first two hours of the overflow maybe
11 2014-11-01 01:25:21 <phantomcircuit> justanotheruser, difficulty calculation breaks unless the field is either extended or values less the the current minimum value are reinterpreted as being value + current minimum value
12 2014-11-01 01:32:38 <justanotheruser> phantomcircuit:  if (nActualTimespan < Params().TargetTimespan()/4)
13 2014-11-01 01:32:39 <justanotheruser>         nActualTimespan = Params().TargetTimespan()/4;
14 2014-11-01 01:35:43 <justanotheruser> If block 2016002016 is 4294967000 and the next block is 100000 (obviously these number are for the concept) then the difference would not only be less than the actual timespan, it would be a negative number. Miners should be excited for those 3.5 days in 2038
15 2014-11-01 01:36:18 <justanotheruser> s/less than the actual/four times less than the actual/
16 2014-11-01 01:39:10 <justanotheruser> Actually I'm wrong in that it wouldn't be 4 times easier, it would be four times harder and would be a burden on miners for 2 months.
17 2014-11-01 13:12:42 <earlz> does the RPC interface support sending to a public key address that is not hashed?  (ie, starts with 04)
18 2014-11-01 13:12:57 <earlz> well, just a public key. not an address
19 2014-11-01 13:13:29 <sipa> using createrawtransaction, yes
20 2014-11-01 13:13:41 <sipa> but that also means doing your own coin selection
21 2014-11-01 13:13:54 <sipa> earlz: compressed public keys start with 02 or 03, btw
22 2014-11-01 13:14:06 <earlz> uncompressed is 04 though, right?
23 2014-11-01 13:14:29 <earlz> and yea, you can send to anything using createrawtransaction heh.
24 2014-11-01 13:14:53 <sipa> uncompressed is 04 yes, but those are discouraged
25 2014-11-01 13:15:12 <sipa> (as in, really no reason to use them, unless of course the key already exists)
26 2014-11-01 16:43:57 <teward> is it still possible to solo CPU/GPU mine testnet, if I want to test a mining software on a specific hardware deployment?
27 2014-11-01 16:44:18 <teward> oopsies, misposted, wrong channel
28 2014-11-01 17:09:28 <Eliel> I was wondering... Currently most bitcoin wallets require 1 confirmation before they allow sending the coins onward. This prevents huge chains of coins that won't confirm. However, wouldn't it be enough to only prevent sending if there's more than 1 or 2 uncofirmed txouts in the chain?
29 2014-11-01 17:11:56 <Eliel> a case in point, there's a veggie burger place in Finland with a bitcoin ATM in it. People go there, buy coins from the ATM and then try paying for a burger with bitcoin. The first experience of bitcoin for many people is thus that they need to wait a a long time before they can pay.
30 2014-11-01 17:32:01 <jgarzik> Eliel, questions like that just lead to "what is your risk tolerance?" responses :)
31 2014-11-01 17:32:46 <jgarzik> anything is possible... most times things go smoothly with friendly actors.  is it secure against determined attacker?  how much are attackers willing to spend, and what will they gain if successful?
32 2014-11-01 17:36:36 <Eliel> In this case it's probably worth also discussing whose risk tolerance we're speaking of. Is it the user of the wallet who pays or the person who receives the coins as payment or perhaps someone else altogether?
33 2014-11-01 17:37:02 <Eliel> personally, I'd much prefer my wallet acted the way I just described.