1 2012-08-15 00:37:26 <theymos> Is this possible? http://bitcoin.stackexchange.com/questions/4436 The first transaction isn't eligible for free tx status and the min fee was decided based on tx size. The second transaction must have fewer inputs, so how can the fee be higher?
  2 2012-08-15 01:54:51 <luke-jr> theymos: the inputs are newer
  3 2012-08-15 02:57:36 <jgarzik> thread title: "Bitcoin client upload saturating my DSL connection. (No bandwidth throttling ?)"
  4 2012-08-15 03:04:59 <luke-jr> jgarzik: I think there's a bug on that topic too
  5 2012-08-15 03:05:24 <jgarzik> The poster is correct that bitcoin client can and will max out your upstream
  6 2012-08-15 03:06:51 <luke-jr> that applies to most programs that upload afaik
  7 2012-08-15 03:09:10 <jgarzik> most programs that are peer-to-peer, online 24/7, and upload have bandwidth controls
  8 2012-08-15 04:23:20 <midnightmagic> if I had a shorter chain but which represented more actual work, but still had the checkpoints as a base, would it cause a reorg to my shorter chain?
  9 2012-08-15 04:23:50 <luke-jr> yes
 10 2012-08-15 04:24:06 <phantomcircuit> midnightmagic, that's actually not possible
 11 2012-08-15 04:24:13 <phantomcircuit> wait
 12 2012-08-15 04:24:15 <phantomcircuit> maybe it is
 13 2012-08-15 04:24:17 <midnightmagic> thanks. i knew it didn't go the other way (less work, longer chain)
 14 2012-08-15 04:24:18 <phantomcircuit> yes it is
 15 2012-08-15 04:24:46 <luke-jr> hmm
 16 2012-08-15 04:24:50 <luke-jr> I wonder if that's exploitablre
 17 2012-08-15 04:24:57 <midnightmagic> i'd just have to magically mine at a much higher difficulty for a while in secret.
 18 2012-08-15 04:24:57 <phantomcircuit> of course it would require a 50% attack
 19 2012-08-15 04:25:02 <jgarzik> midnightmagic: yes, it will reorg to a shorter chain, if the shorter chain's total work is > the longer chain
 20 2012-08-15 04:25:03 <luke-jr> phantomcircuit: no?
 21 2012-08-15 04:25:13 <phantomcircuit> luke-jr, im not sure
 22 2012-08-15 04:25:18 <midnightmagic> jgarzik: thanks, i like triangulation
 23 2012-08-15 04:25:27 <luke-jr> get the difficulty on your chain high enough to counter the current chain with 1 block
 24 2012-08-15 04:25:30 <luke-jr> then hope you get lucky
 25 2012-08-15 04:25:45 <luke-jr> 64% chance you'll find it with the same work as the main chain would take to get there&
 26 2012-08-15 04:25:56 <midnightmagic> it would be similarly as likely as just mining a longer chain normally wouldn't it?
 27 2012-08-15 04:26:07 <phantomcircuit> actually
 28 2012-08-15 04:26:08 <luke-jr> midnightmagic: no, it would just be amazingly lucky
 29 2012-08-15 04:26:12 <midnightmagic> (presuming identical work)
 30 2012-08-15 04:26:13 <phantomcircuit> i guess you could do it
 31 2012-08-15 04:26:21 <phantomcircuit> by screwing with the timestamps in your chain
 32 2012-08-15 04:26:38 <luke-jr> midnightmagic: 64% chance you could get away with less actual work
 33 2012-08-15 04:26:43 <phantomcircuit> but you would need to either be ridiculously lucky or have WAY more processing power than the main network
 34 2012-08-15 04:27:04 <luke-jr> phantomcircuit: but you'd only need to be lucky ONCE
 35 2012-08-15 04:27:13 <midnightmagic> luke-jr: .. I have go explain in brush strokes bitcoin to someone, i'll be back later. I'd really like to know how you arrived at the 64% figure.
 36 2012-08-15 04:27:30 <luke-jr> midnightmagic: 64% of blocks are found with less than average shares
 37 2012-08-15 04:27:31 <phantomcircuit> luke-jr, well you'd probably need to be lucky for 2016 blocks
 38 2012-08-15 04:27:58 <phantomcircuit> since the target recalculation only happens on the boundary and blocks with the wrong target are rejected
 39 2012-08-15 04:28:02 <luke-jr> phantomcircuit: maybe.
 40 2012-08-15 04:28:09 <midnightmagic> or you just wait for teh 2016th
 41 2012-08-15 04:28:12 <phantomcircuit> (work is calculated from the target not the actual hash)
 42 2012-08-15 04:28:25 <luke-jr> midnightmagic: then you're limited to how much you can change it
 43 2012-08-15 04:28:33 <phantomcircuit> midnightmagic, the recalculation takes into account all the blocks in the last group
 44 2012-08-15 04:28:41 <luke-jr> phantomcircuit: no, it doesn't
 45 2012-08-15 04:28:45 <luke-jr> phantomcircuit: it's last - first
 46 2012-08-15 04:28:45 <phantomcircuit> it doesn't?
 47 2012-08-15 04:28:49 <phantomcircuit> oh
 48 2012-08-15 04:28:59 <luke-jr> but you can't set your block's timestamp more than the median of the last N blocks
 49 2012-08-15 04:29:02 <midnightmagic> except.. hrm. 2016th timestamp is ignored in retarget
 50 2012-08-15 04:29:04 <luke-jr> s/more/before
 51 2012-08-15 04:29:25 <midnightmagic> anyway doesn't matter. bbl
 52 2012-08-15 04:29:57 <phantomcircuit> midnightmagic, basically you'd be trying to skyrocket the target by screwing with block timestamps and then getting lucky with a single ridiculously low target block
 53 2012-08-15 04:30:14 <phantomcircuit> i suspect if you worked out the numbers you'd find a 51% attack to be easier
 54 2012-08-15 05:58:26 <denisx> rpc calls to bitcoind (like getinfo or getwork) from 127.0.0.1 don't require authentication, right?
 55 2012-08-15 06:07:52 <weex> they require that an rpcuser and rpcpassword be set in bitcoin.conf
 56 2012-08-15 06:08:10 <weex> if you're using bitcoind to to do the calling
 57 2012-08-15 06:08:20 <weex> from php does require those credentials denisx
 58 2012-08-15 06:08:35 <denisx> ok
 59 2012-08-15 08:07:41 <zveda> hi
 60 2012-08-15 08:08:09 <zveda> is there a discussion somewhere of the timeline for the upcoming hard fork ?
 61 2012-08-15 08:16:44 <sipa> zveda: there is no hard fork planned
 62 2012-08-15 08:17:11 <zveda> sipa, but I read in the 'scaling bitcoin' discussions
 63 2012-08-15 08:17:15 <epscy> sipa: is there a plan to increase the block size so the chain can handle more transactions?
 64 2012-08-15 08:17:23 <zveda> yes the block size
 65 2012-08-15 08:17:47 <zveda> https://en.bitcoin.it/wiki/Scalability#Current_bottlenecks
 66 2012-08-15 08:18:03 <zveda> "Once those limits are lifted, the maximum transaction rate will go up significantly. "
 67 2012-08-15 08:18:10 <zveda> Seems to imply that the fork is imminent .. ?
 68 2012-08-15 08:18:44 <epscy> zveda: i don't think the wiki is neccessarily up to date
 69 2012-08-15 08:18:57 <epscy> someone may have wrote that a couple of years ago
 70 2012-08-15 08:19:12 <zveda> hm I see
 71 2012-08-15 08:19:14 <zveda> so what's the plan now
 72 2012-08-15 08:19:21 <zveda> to deal with the block size?
 73 2012-08-15 08:19:27 <zveda> or just leave things be ?
 74 2012-08-15 08:19:38 <epscy> i think it is to leave things be
 75 2012-08-15 08:19:42 <epscy> for the time being
 76 2012-08-15 08:19:42 <justmoon> I think for now most people are focusing on improving scalability and performance
 77 2012-08-15 08:19:50 <justmoon> we need to be ready to deal with larger blocks before we allow them
 78 2012-08-15 08:20:05 <sipa> in case the transaction rate goes up even more, space in blocks will become more expensive
 79 2012-08-15 08:20:21 <sipa> so at that point, tx fees may become more relevant
 80 2012-08-15 08:20:22 <epscy> gmaxwell has written about how bitcoin doesn't need to scale to visa levels of transactions, it can be used as a clearing house
 81 2012-08-15 08:20:38 <sipa> yes, bitcoin is a currency, not a payment processor
 82 2012-08-15 08:21:09 <justmoon> sipa: I disagree with gmaxwell (and many others) on that
 83 2012-08-15 08:21:13 <sipa> it can be used as a simple payment processor directly, but it is slow and hard to use as one
 84 2012-08-15 08:21:18 <sipa> justmoon: i know
 85 2012-08-15 08:21:22 <justmoon> by the same token you could make a micropayment network and use paypal as a "clearing house"
 86 2012-08-15 08:21:43 <justmoon> the benefit comes from having a common standard for transaction directly
 87 2012-08-15 08:22:03 <epscy> zveda: https://en.bitcoin.it/wiki/Talk:Scalability#Response_from_Gregory_Maxwell
 88 2012-08-15 08:22:25 <sipa> sure, i think bitcoin has many advantages over other currencies, when you want to build an electronic payment processor on top of it
 89 2012-08-15 08:23:25 <zveda> I see thx
 90 2012-08-15 08:25:39 <justmoon> sipa: the price of payment processors doesn't come from their clearing costs, but from their market position. if bitcoin is used merely in the background, then the payment processors with the best adoption will still be able to charge high premiums
 91 2012-08-15 08:26:25 <epscy> justmoon: i think the difference is that getting set up with a visa merchant account can be a costly and time consuming process
 92 2012-08-15 08:26:33 <epscy> this is not true of bitcoin
 93 2012-08-15 08:27:05 <epscy> so if any payment processor acts too "evil" the barrier to entry for a competitor is very low
 94 2012-08-15 08:28:07 <grondilu> I run "bitoind help" and I get a "error:  couldn't connect to server".  ??
 95 2012-08-15 08:28:13 <justmoon> epscy: I'm not arguing that bitcoin wouldn't still be an improvement over the status quo - it just wouldn't as big of one
 96 2012-08-15 08:28:35 <epscy> and it would be difficult for one bitcoin payment processor to prevent users from moving to another
 97 2012-08-15 08:29:07 <justmoon> epscy: not necessarily, since payments from processor to processor would be more expensive then internal payments
 98 2012-08-15 08:29:11 <epscy> justmoon: the problems you identify aren't technical, they are economic and social
 99 2012-08-15 08:29:38 <justmoon> epscy: yes, I think there is no technical reason to limit the scale of bitcoin only economic and social ones
100 2012-08-15 08:29:40 <epscy> justmoon: if the user can withdraw btc then i don't see the problem
101 2012-08-15 08:30:23 <justmoon> epscy: if you switch payment processors you can still transact with the people using that payment processor, it'll just cost more
102 2012-08-15 08:30:40 <justmoon> it'll be more like the banking system we have now, or like the mobile phone market
103 2012-08-15 08:31:06 <epscy> justmoon: i think there are technical limits to bitcoins ability to scale
104 2012-08-15 08:31:19 <epscy> look at the problems we have with the size of the blockchain already
105 2012-08-15 08:31:48 <justmoon> that's because currently there is no way to distribute verification work across multiple nodes that don't trust one another
106 2012-08-15 08:31:55 <epscy> justmoon: also it would be different from the current system, in that you can send btc directly to people
107 2012-08-15 08:32:05 <epscy> in theory that should keep the PP honest
108 2012-08-15 08:33:05 <justmoon> you can also send money using other methods to people today, that only keeps western union "honest" to the extent that this other method is competitive price-wise
109 2012-08-15 08:33:18 <justmoon> remember our premise is that bitcoin transactions get relatively expensive
110 2012-08-15 08:34:42 <epscy> yeah
111 2012-08-15 08:34:50 <justmoon> epscy: all I'm asking is that we assume that the existing tasks a bitcoin node performs can be decentralized and that if we introduce new features that are mandatory for mining nodes that these features fulfill the same criterion
112 2012-08-15 08:34:55 <epscy> i don't believe bitcoin will ever be the only currency used