1 2012-06-14 00:00:07 <gmaxwell> well, it would help if upgrades were reliably painless. :-/
  2 2012-06-14 00:00:08 <bayleef> hmmph. Just synched another machine, got it to latest block and synched my box only from it. That machine didn't have a problem with block 176948. My box instantly saw some invalid signature and won't accept it. wtf n stuff
  3 2012-06-14 00:00:13 <luke-jr> I was surprised to see that on Intel's website -.-
  4 2012-06-14 00:00:22 <luke-jr> "don't update your BIOS unless you have a problem"
  5 2012-06-14 00:00:36 <luke-jr> gmaxwell: hence the stable branches I maintain
  6 2012-06-14 00:01:06 <gavinandresen> I thought you said the stable branches got stuck on a block.....  (did you email about that?  I didn't get it if you did, I think)
  7 2012-06-14 00:01:21 <BlueMatt> bayleef: ok, thats really looking like a hardware problem...a. can you double-check that the bitcoin-qt.exe you are running has the same hash as the published ones? after that, try memtest86+
  8 2012-06-14 00:01:48 <BlueMatt> gmaxwell: yea...
  9 2012-06-14 00:02:19 <gmaxwell> luke-jr: for some of the issues people run into the stable branches don't help I think. E.g. they shutdown uncleanly then upgrade and bdb barfs because the bdb version isn't the same.
 10 2012-06-14 00:02:27 <bayleef> Would hashes still apply if I'm using custom-built binaries? Both me and portage
 11 2012-06-14 00:02:27 <luke-jr> gavinandresen: yes, they did. I haven't writ the email yet
 12 2012-06-14 00:02:41 <gmaxwell> portage?  ... gentoo user.
 13 2012-06-14 00:02:44 <BlueMatt> bayleef: mmm...probably not
 14 2012-06-14 00:02:54 <BlueMatt> try recompiling+reinstalling
 15 2012-06-14 00:02:56 <luke-jr> bayleef: huh?
 16 2012-06-14 00:02:59 <gmaxwell> Try -fdont-unroll-enough-to-break-everything?  :)
 17 2012-06-14 00:03:09 <luke-jr> what gmaxwell said too
 18 2012-06-14 00:03:56 <gmaxwell> bayleef: what crazy make options do you have? a miscompilation isn't out of the question.
 19 2012-06-14 00:06:49 <bayleef> nothing terribly interesting, -s -j2. Also when I compiled it, I set BDB_PATH=/usr/include/db4.8. CFLAGS is just the default stuff, -o2 -pipe -march=i686
 20 2012-06-14 00:07:20 <bayleef> I left any flags the way they were when I compiled myself
 21 2012-06-14 00:08:16 <luke-jr> bayleef: CXXFLAGS is what we want
 22 2012-06-14 00:08:32 <luke-jr> and I hope that's -O2
 23 2012-06-14 00:08:33 <luke-jr> not -o2
 24 2012-06-14 00:10:45 <gmaxwell> hah
 25 2012-06-14 00:10:52 <bayleef> and this is me, failing at quoting things properly
 26 2012-06-14 00:13:48 <bayleef> luke-jr: CXXFLAGS="${CFLAGS}"
 27 2012-06-14 00:14:08 <luke-jr> bayleef: failing hard drive?
 28 2012-06-14 00:14:38 <luke-jr> someone find a block plz
 29 2012-06-14 00:16:16 <bayleef> luke-jr: smartctl -a /dev/sda doesn't seem to think so. Any way to verify that?
 30 2012-06-14 00:17:26 <luke-jr> dunno
 31 2012-06-14 00:17:37 <luke-jr> bayleef: I suggest setting aside an IBM 5100 for the future.
 32 2012-06-14 00:29:00 <bayleef> luke-jr: So now I get to go run a memory test?
 33 2012-06-14 00:32:53 <luke-jr> bayleef: I'd run -checkblocks
 34 2012-06-14 00:36:32 <luke-jr> REORGANIZE: Connect 6811 blocks; 00000000000005353824..00000000000003c87423
 35 2012-06-14 00:37:14 <bayleef> luke-jr: I've tried that already, but that was another blockchain copy, verified that one at level 6 and it still couldn't verify the signature. Should I do that with this one too?
 36 2012-06-14 00:42:10 <gribble> New news from bitcoinrss: jgarzik opened pull request 1458 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1458> || joaocalistro opened issue 1457 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1457>
 37 2012-06-14 02:11:14 <luke-jr> REORGANIZE: Connect 6814 blocks; 00000000000005353824..00000000000000e44748
 38 2012-06-14 02:11:20 <luke-jr> going on an hour now&
 39 2012-06-14 02:13:08 <doublec> what's that from?
 40 2012-06-14 02:13:51 <luke-jr> doublec: 0.4.x with the P2SH bug fixed, trying to reorg up to the last block (an hour ago)
 41 2012-06-14 02:14:03 <luke-jr> in a single leap
 42 2012-06-14 02:14:58 <doublec> ah ok
 43 2012-06-14 02:44:50 <Nolybab> sure is quiet in here...is quiet in here...quiet in here...in here...here...*
 44 2012-06-14 04:07:05 <gribble> New news from bitcoinrss: laanwj opened pull request 1459 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1459>
 45 2012-06-14 05:08:15 <gribble> New news from bitcoinrss: xanatos opened issue 1460 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1460>
 46 2012-06-14 05:11:14 <BlueMattBot> Project Bitcoin-Test build #304: FAILURE in 33 min: http://jenkins.bluematt.me/job/Bitcoin-Test/304/
 47 2012-06-14 05:11:15 <BlueMattBot> * phil.kaufmann: merge toggleHidden() code into showNormalIfMinimized() to extend the functionality, but keep a simpler toggleHidden() for use in SLOT() macro
 48 2012-06-14 05:23:31 <yellowhat> can a transaction appear in more than one block?
 49 2012-06-14 06:56:16 <BlueMattBot> Yippie, build fixed!
 50 2012-06-14 06:56:17 <BlueMattBot> Project Bitcoin-Test build #305: FIXED in 30 min: http://jenkins.bluematt.me/job/Bitcoin-Test/305/
 51 2012-06-14 09:41:02 <jurov> hi all, i'm developing multiuser/multiwallet patch for bitcoind: https://bitcointalk.org/index.php?topic=71542.msg960484#msg960484
 52 2012-06-14 09:41:42 <jurov> and want to get in touch with devs whether it's potentially acceptable
 53 2012-06-14 09:44:09 <Joric> did you consider another wallet format? heard 0.7 moves towards that
 54 2012-06-14 09:44:45 <TD> hmm
 55 2012-06-14 09:44:52 <TD> how comes i am receiving so many orphan transactions
 56 2012-06-14 09:44:53 <jurov> I don't touch the disk at all, so far it was only sufficient to use multiple CWallet objects.
 57 2012-06-14 09:46:50 <TD> [Tycho]: satoshidice pays fees because bitcoinj doesn't currently contain a fee solver
 58 2012-06-14 09:46:57 <TD> so clients work around that by always attaching the minimum fee
 59 2012-06-14 09:48:02 <TD> once we fix that, if fireduck upgrades, i imagine SD will pay less in fees (only what is required)
 60 2012-06-14 09:48:13 <TD> for now it's "free money"
 61 2012-06-14 10:18:35 <sipa> jurov: moving to another wallet format can happen quite independently from multiwallet support
 62 2012-06-14 10:18:52 <sipa> the largest issue with it is that it is still tied to the (single) bdb environment for now
 63 2012-06-14 10:19:32 <wumpus> so you solve the 'multiwallet in rpc' problem by using multiple users... interesting
 64 2012-06-14 10:19:49 <sipa> so the plan was first moving to another wallet format that's self-contained in a single file, and then adding multiple wallets
 65 2012-06-14 10:19:56 <wumpus> it's less invasive than adding a wallet id to all the commands :-)
 66 2012-06-14 10:20:22 <sipa> but that's mostly from a UI perspective; for RPC, this is a nice solution that doesn't require such measures
 67 2012-06-14 10:20:38 <sipa> wumpus: indeed!
 68 2012-06-14 10:21:14 <sipa> or making it stateful and adding a "setwallet" command
 69 2012-06-14 10:22:07 <wumpus> I think it's a nice idea, as it also adds another layer of security that makes sense
 70 2012-06-14 10:22:24 <sipa> it makes the rpcuser useful :)
 71 2012-06-14 10:22:37 <wumpus> yep
 72 2012-06-14 10:23:05 <sipa> though you'll probably want to limit non-wallet commands to authorized users only
 73 2012-06-14 10:23:27 <sipa> or have some other administrative account which can set permissions/...
 74 2012-06-14 10:23:42 <wumpus> the only potential thorny issue I see is user administration
 75 2012-06-14 10:24:29 <wumpus> right
 76 2012-06-14 10:25:31 <wumpus> some things like removing users would be really dangerous
 77 2012-06-14 10:26:41 <wumpus> we should be careful not to drag an operating system into bitcoin :P
 78 2012-06-14 10:27:32 <jurov> heh... i actually had stray thoughts to add scripting support
 79 2012-06-14 10:27:51 <sipa> we already have a scripting language!
 80 2012-06-14 10:27:54 <wumpus> hah
 81 2012-06-14 10:28:21 <sipa> jurov: anyway, i haven't looked at the code, but i like the idea
 82 2012-06-14 10:30:41 <jurov> fine. now, has anyone experience with fundraising for such project?
 83 2012-06-14 10:31:46 <wumpus> nope, my work on this has been mostly unpaid
 84 2012-06-14 10:32:05 <sipa> etotheipi raised a few thousand for his work on armory
 85 2012-06-14 10:32:26 <sipa> but my work has been unpaid as well
 86 2012-06-14 10:32:57 <jurov> hm...i'm independent consultant and don't have anything atm
 87 2012-06-14 10:34:05 <jurov> and this solves real need of vps providers. so i'm looking into setting up some escrow for donations
 88 2012-06-14 11:19:33 <gribble> New news from bitcoinrss: laanwj opened pull request 1461 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1461>
 89 2012-06-14 11:51:33 <sipa> i wonder
 90 2012-06-14 11:51:49 <sipa> why do we need to keep txins of old transactions around?
 91 2012-06-14 11:52:12 <sipa> you need the txouts' amounts and scripts
 92 2012-06-14 11:52:23 <sipa> and the transaction hash
 93 2012-06-14 11:52:37 <tcatm> We need them to verify the chain. don't we?
 94 2012-06-14 11:52:46 <sipa> after verifying and storing them
 95 2012-06-14 11:52:58 <tcatm> But yes, they could be pruned just as Satoshi described it in his paper.
 96 2012-06-14 11:54:18 <sipa> right, it would mean being unable to serve the chain
 97 2012-06-14 11:59:58 <gribble> New news from bitcoinrss: xanatos opened issue 1462 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1462>
 98 2012-06-14 12:02:14 <luke-jr> sipa: I just got 0.4.x to reorganize 6814 blocks in a single bdb transaction
 99 2012-06-14 12:02:40 <BlueMatt> early blocks?
100 2012-06-14 12:02:42 <luke-jr> took 6 hours, but worked
101 2012-06-14 12:02:48 <luke-jr> BlueMatt: no, the most recent 6814
102 2012-06-14 12:02:52 <luke-jr> as of last night
103 2012-06-14 12:02:59 <BlueMatt> increased lock objects a ton?
104 2012-06-14 12:03:02 <luke-jr> yes
105 2012-06-14 12:03:05 <luke-jr> 100 fold
106 2012-06-14 12:03:10 <BlueMatt> peak memory usage?
107 2012-06-14 12:03:26 <luke-jr> about 768 MB
108 2012-06-14 12:04:15 <luke-jr> hmm
109 2012-06-14 12:04:17 <luke-jr> maybe higher
110 2012-06-14 12:04:28 <gmaxwell> Hm. 6 hours... not sure if thats fast enough to be considered 'worked'.
111 2012-06-14 12:04:40 <gmaxwell> I guess for an unattended server...
112 2012-06-14 12:05:17 <BlueMatt> gmaxwell: 6 hours in one tx vs 6.1 hours in 6814 txes...
113 2012-06-14 12:05:26 <BlueMatt> either way the gui/rpc interface will appear the same
114 2012-06-14 12:06:34 <luke-jr> the important thing is that it finished IMO
115 2012-06-14 12:06:50 <gmaxwell> BlueMatt: well the count won't update along the way, no?
116 2012-06-14 12:06:51 <sipa> gmaxwell: regarding the "merkle root of unspent outputs in coinbase"... i believe it could be calculated on the txids+txout data, so a light node would only need to keep those
117 2012-06-14 12:07:19 <BlueMatt> gmaxwell: currently the block count wont update, no...Im gonna fix that in cblockstore at some point though as it should be easy to do there...
118 2012-06-14 12:07:43 <gmaxwell> sipa: Hm. etothipi was arguing txout data... but I pointed out that it wasn't enough. txids+txout perhaps would be.
119 2012-06-14 12:07:48 <luke-jr> is there any harm in increasing locks 100fold?
120 2012-06-14 12:09:12 <luke-jr> instead, it has bursts of CPU use
121 2012-06-14 12:09:42 <sipa> i suppose bdb switching between updating to log file, and committing log
122 2012-06-14 12:09:53 <gmaxwell> jrmithdobbs: See that seccomp mode 2 made it into the linux kernel?  Would make for a much improved refresh of that capabilities patch.
123 2012-06-14 12:09:57 <BlueMatt> luke-jr: what was you database dir size max?
124 2012-06-14 12:10:17 <luke-jr> BlueMatt: I wasn't monitoring that.
125 2012-06-14 12:10:32 <luke-jr> sipa: I never saw hard drive activity solid
126 2012-06-14 12:10:34 <BlueMatt> if you never closed bitcoin after reorg it should still be at max
127 2012-06-14 12:11:13 <luke-jr> I did :/
128 2012-06-14 12:11:16 <sipa> gmaxwell: would result in a factor 2 less space, imho
129 2012-06-14 12:12:14 <sipa> and maybe it would even make sense to build a new such datastructure for every let's say 1000 blocks
130 2012-06-14 12:12:42 <sipa> as most likely the more recent ones will be accessed much more frequently
131 2012-06-14 12:12:55 <sipa> resulting in better cache usage
132 2012-06-14 12:13:46 <luke-jr> so& is there any harm in increasing locks 100fold?
133 2012-06-14 12:14:20 <sipa> luke-jr: what's the effect on base memory usage?
134 2012-06-14 12:14:35 <luke-jr> sipa: I presume none, it's a maximum
135 2012-06-14 12:14:41 <sipa> right
136 2012-06-14 12:17:28 <sipa> i think it'd make sense to separate the block-serving and tx-verifying systems entirely
137 2012-06-14 12:17:58 <luke-jr> memory peaked ~1280 MB right before it finished
138 2012-06-14 12:18:21 <sipa> you choose to either keep just block headers, or the full txout merkle tree
139 2012-06-14 12:18:47 <sipa> and independently choose whether (and which) blocks you keep in full to serve to other nodes
140 2012-06-14 12:21:12 <sipa> the txout merkle tree will presumably be more efficient for verification anyway
141 2012-06-14 12:33:58 <luke-jr> sipa: weird
142 2012-06-14 12:34:22 <luke-jr> as measured by top (RES), base memory use is 9 times greater (50 MB vs 442 MB)
143 2012-06-14 12:34:27 <luke-jr> as measured by ps (SIZE), it's the same
144 2012-06-14 12:34:54 <luke-jr> does that mean it's spare memory allocations or something? O.o
145 2012-06-14 12:35:41 <sipa> and what is the number reported by ps?
146 2012-06-14 12:36:32 <luke-jr> 103 MB
147 2012-06-14 12:37:10 <luke-jr> I usually prefer ps because it reports swap too
148 2012-06-14 12:37:57 <sipa> i'd expect resident set size to be less than allocated memory...
149 2012-06-14 12:41:04 <luke-jr> I don't know how to get allocated memory
150 2012-06-14 12:41:18 <luke-jr> SIZE is "how much disk space would be used if the entire process were in swap"
151 2012-06-14 12:41:41 <luke-jr> which I presume could exclude unused allocations
152 2012-06-14 12:46:36 <wumpus> there is no way to get allocated memory from the OS, as the OS is not concerned with that
153 2012-06-14 12:46:54 <wumpus> it just knows the amount and status of pages mapped to the process
154 2012-06-14 12:47:15 <gmaxwell> It does know if the pages are dirty or not.
155 2012-06-14 12:47:32 <wumpus> which only tells if it was recently used, not wether it was allocated
156 2012-06-14 12:47:46 <jgarzik> pages don't tend to stay dirty for long
157 2012-06-14 12:48:01 <jgarzik> one may make a guess by counting anonymously mapped pages
158 2012-06-14 12:48:04 <wumpus> or freed... some mallloc implementations never give back memory to the OS
159 2012-06-14 12:48:40 <jgarzik> today's glibc allocates via big anon blocks, which does permit some OS reclaim
160 2012-06-14 12:48:49 <jgarzik> sbrk has gone the way of the dodo
161 2012-06-14 12:49:04 <wumpus> yeah, on linux it's good
162 2012-06-14 12:50:01 <luke-jr> wumpus: how about pages mapped?
163 2012-06-14 12:50:40 <wumpus> how does that help? even with some reclaim, it will probably keep around freed memory for quite some time because it might be re-used just after
164 2012-06-14 12:53:32 <luke-jr> I'm checking use immediately after startup :p
165 2012-06-14 12:54:17 <wumpus> well in that case it's certainly more reliable than a long-running process
166 2012-06-14 13:24:15 <someone42> would it be correct to say that in order to securely generate a P2SH address, all signing devices must be able to independently generate it?
167 2012-06-14 13:24:29 <sipa> "it" being the address?
168 2012-06-14 13:24:35 <someone42> yeah
169 2012-06-14 13:24:51 <sipa> you just need to know the pubkeys involved of all signing devices
170 2012-06-14 13:25:27 <someone42> but how would you know the P2SH address generator isn't replacing pubkeys?
171 2012-06-14 13:26:05 <sipa> the generator can prove it, by revealing the full script
172 2012-06-14 13:27:51 <someone42> a compromised generator could reveal the correct, full script to the user, but then covertly replace pubkeys when actually generating addresses
173 2012-06-14 13:29:08 <sipa> all users involved tell eachother their pubkeys
174 2012-06-14 13:29:21 <sipa> all users involved generate the address from it
175 2012-06-14 13:29:39 <sipa> all users involved know the address and can see whether the others use it correctly
176 2012-06-14 13:29:48 <sipa> s/users/devices/ if you like
177 2012-06-14 13:30:52 <someone42> ok, so as i understand it, devices need to be able to independently swap pubkeys and generate addresses
178 2012-06-14 13:33:18 <sipa> well, public keys are not a secret
179 2012-06-14 13:33:41 <sipa> to verify that an untrusted address is correct, you do indeed need to know all public keys to verify it
180 2012-06-14 13:37:14 <sipa> ha!
181 2012-06-14 13:37:15 <sipa> $ git fetch -all
182 2012-06-14 13:42:58 <drizztbsd> git remote update
183 2012-06-14 13:44:06 <sipa> ha, useful!
184 2012-06-14 13:47:31 <sipa> ;;bc,blocks
185 2012-06-14 13:47:32 <gribble> 184511
186 2012-06-14 14:07:09 <epscy> using bitcoind, how many confirms does a received payment need before getinfo will show it as being a part of your balance?
187 2012-06-14 14:07:13 <epscy> i assumed it was one
188 2012-06-14 14:07:37 <sipa> 1
189 2012-06-14 14:07:44 <epscy> sipa: thanks
190 2012-06-14 14:07:56 <sipa> for payments-to-self and change, i believe 0
191 2012-06-14 14:09:14 <luke-jr> who's available to build 0.4.x and 0.5.x gitian binaries? should probably plan to get these up on SF&
192 2012-06-14 14:37:41 <gribble> New news from bitcoinrss: sipa opened pull request 1463 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1463>
193 2012-06-14 14:52:41 <luke-jr> BlueMatt: what exactly does this do? 4d00924 Fix DEBUG_LOCKCONTENTION
194 2012-06-14 14:57:43 <BlueMatt> luke-jr: fixes a compile error if compiled with DEBUG_LOCKCONTENTION
195 2012-06-14 14:58:27 <luke-jr> BlueMatt: I only see noop change
196 2012-06-14 14:58:31 <luke-jr> how does it fix it?
197 2012-06-14 15:05:01 <BlueMatt> how is that a noop?
198 2012-06-14 15:05:15 <BlueMatt> sync.h is included before util.h, so printf isnt defined
199 2012-06-14 15:05:47 <luke-jr> ah!
200 2012-06-14 15:06:07 <luke-jr> that's a sneaky hidden bug :/
201 2012-06-14 15:07:54 <wumpus> that's what you get for redefining printf
202 2012-06-14 15:08:07 <wumpus> it's a really evil thing to do
203 2012-06-14 15:08:10 <wumpus> :p
204 2012-06-14 15:08:13 <luke-jr> yeah, we should probably just rename every use to applog or something
205 2012-06-14 15:08:23 <luke-jr> maybe with loglevels too <.<
206 2012-06-14 15:09:26 <wumpus> I don't care about the levels, but renaming sounds good
207 2012-06-14 15:13:25 <BlueMatt> meh, its not worth chaning every call to printf and breaking a ton of pulls to do that
208 2012-06-14 15:13:35 <BlueMatt> that bug would still have existed
209 2012-06-14 15:13:41 <wumpus> it is worth it, eventually
210 2012-06-14 15:13:46 <BlueMatt> meh
211 2012-06-14 15:14:00 <BlueMatt> we've never had any problems as a result of redefining printf afaik
212 2012-06-14 15:14:09 <wumpus> it's not just about this bug but also future ones caused by this, and new developers getting confused by it
213 2012-06-14 15:14:20 <wumpus> it's simply something that should not be done
214 2012-06-14 15:14:34 <BlueMatt> redefinition of printf has nothing to do with this bug
215 2012-06-14 15:14:37 <wumpus> printf is a perfectly normal libc function, it has a well-defined meaning
216 2012-06-14 15:14:58 <wumpus> using a macro to redefine it is really ugly
217 2012-06-14 15:16:07 <BlueMatt> it is, but my point is its not worth changing now
218 2012-06-14 15:16:19 <wumpus> my point is that I disagree on that
219 2012-06-14 15:16:40 <BlueMatt> ok
220 2012-06-14 15:23:41 <gribble> New news from bitcoinrss: Diapolo opened pull request 1464 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1464>
221 2012-06-14 15:28:44 <gribble> New news from bitcoinrss: Diapolo opened pull request 1465 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1465>
222 2012-06-14 15:49:05 <gribble> New news from bitcoinrss: Diapolo opened issue 1466 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1466>
223 2012-06-14 15:49:44 <luke-jr> why do I get the feeling Diapolo broke test_bitcoin? <.<
224 2012-06-14 15:58:39 <luke-jr> ah, wumpus fixed it :D
225 2012-06-14 15:59:34 <BlueMatt> read scrollback, jenkins caught it hours ago ;)
226 2012-06-14 15:59:47 <luke-jr> heh
227 2012-06-14 16:03:36 <luke-jr> BlueMatt: will you be available to build 0.4.7 & 0.5.6?
228 2012-06-14 16:04:48 <BlueMatt> Ive gotta get gitian working, but Ill go do that...for when?
229 2012-06-14 16:05:13 <luke-jr> probably in an hour or so
230 2012-06-14 16:05:23 <BlueMatt> uhh...well Ill see
231 2012-06-14 16:05:25 <luke-jr> after I've confirmed they build myself
232 2012-06-14 16:25:30 <BlueMatt> [Tycho]: what is up with sendmulti? you said you were gonna implement it months ago and still havent?
233 2012-06-14 16:29:18 <BlueMatt> meh, he wont respond because for some bright reason the other person behind deepbit who doesnt do pr "doesnt like multisend"
234 2012-06-14 16:29:32 <copumpkin> sounds awfully convenient
235 2012-06-14 16:30:03 <copumpkin> in any negotiation, it's never you who doesn't want something. It's your partner/wife/husband/someone unseen
236 2012-06-14 16:30:08 <copumpkin> "if it were up to me I'd do it now"
237 2012-06-14 16:30:16 <copumpkin> "but you know, my wife doesn't want it"
238 2012-06-14 16:30:17 <BlueMatt> yep
239 2012-06-14 16:31:17 <copumpkin> lol
240 2012-06-14 16:31:31 <copumpkin> nothing fundamentally wrong with satoshidice
241 2012-06-14 16:31:40 <BlueMatt> uhh...the lack of sendmulti?
242 2012-06-14 16:31:59 <BlueMatt> if they just bunched up txes each minute, they would decrease their chain load by like 1/10th
243 2012-06-14 16:32:05 <copumpkin> fair enough
244 2012-06-14 16:32:15 <copumpkin> have you contacted the guys behind it?
245 2012-06-14 16:32:17 <BlueMatt> not chain size, mind you, but chain load in terms of txes
246 2012-06-14 16:32:19 <BlueMatt> yes
247 2012-06-14 16:32:41 <BlueMatt> see the rediculously long thread of people refusing to read anything but the first post and responding: https://bitcointalk.org/index.php?topic=87444.0
248 2012-06-14 16:33:37 <BlueMatt> and I pmd multiple people asking for comment, but...
249 2012-06-14 16:34:07 <copumpkin> BlueMatt: about the pruning question
250 2012-06-14 16:34:40 <copumpkin> it seems to me like there's no need to _store_ the entire blockchain history is there?
251 2012-06-14 16:34:46 <copumpkin> meaning when you first fire up your client, you "download" all of it
252 2012-06-14 16:35:00 <copumpkin> but discard it as you go along, just remembering the earlier hashes
253 2012-06-14 16:35:15 <Eliel> copumpkin: someone needs to keep it, otherwise there's no-one to download it from.
254 2012-06-14 16:35:26 <copumpkin> yeah, but it could be probabilistic
255 2012-06-14 16:35:37 <copumpkin> with 1/10 users keeping it or something :P
256 2012-06-14 16:35:42 <copumpkin> I guess that'd increase strain on them
257 2012-06-14 16:35:46 <copumpkin> or people could opt into being supernodes
258 2012-06-14 16:45:45 <lukys> ni'o Is there any way to connect to the network behind an http proxy?
259 2012-06-14 16:46:35 <BlueMatt> lukys: in bitcoin-qt? check the settings dialog, in bitcoind use -proxy
260 2012-06-14 16:46:52 <lukys> That's a socks proxy.
261 2012-06-14 16:47:04 <BlueMatt> I believe if you use socks4 it should be identical?
262 2012-06-14 16:47:12 <lukys> I'm behind an http proxy with authentication.
263 2012-06-14 16:48:22 <lukys> I have a username and password that I need to use to access the internet.
264 2012-06-14 16:49:55 <BlueMatt> oh, yea, we may not support proxy auth...
265 2012-06-14 16:50:17 <lukys> Is that a possibility for future releases?
266 2012-06-14 16:50:28 <BlueMatt> copumpkin: yes, pruning is an option, see the recent thread TD (tried) to start on the bitcoin-dev mailing list
267 2012-06-14 16:50:50 <BlueMatt> lukys: someone would have to implement it, and afaik no one is currently doing that so...patches welcome ;)
268 2012-06-14 16:51:22 <lukys> It's times like this I wish I could code...
269 2012-06-14 16:51:28 <lukys> I keep trying to learn but I'm useless
270 2012-06-14 16:54:27 <gmaxwell> lukys: Have patience and keep trying. If you keep at it you'll learn.
271 2012-06-14 16:55:02 <guruvan> after like 20yrs of hacking at linux, I'm starting to learn to write a little code :D
272 2012-06-14 16:55:19 <BlueMatt> lukys: people here will gladly help you if you have questions
273 2012-06-14 16:55:57 <lukys> I've recently started delving into the figurative intestines of Linux. I'm doing LFS at the moment :)
274 2012-06-14 16:56:09 <lukys> That's a nice offer, thank you.
275 2012-06-14 16:56:16 <lukys> It's C++, isn't it?
276 2012-06-14 16:57:21 <gmaxwell> lukys: Learning Linux in detail is actually a great thing to do to learn programming... simply because a lot of the C culture is well embodied in Unix and there is an assumption that programmers are all unix power users and know all this stuff.
277 2012-06-14 16:58:13 <guruvan> ^^ this - this is how I know anything about code - building gentoo & LFS systems is awesome for this
278 2012-06-14 16:59:02 <gmaxwell> Its also a lot easier to get started and more rewarding for beginners to make small changes to the programs you use than it is to write whole big programs.  Plus the way you become _good_ at programming once you know how to do it is reading a LOT of code.
279 2012-06-14 17:01:02 <lukys> I just do tutorials and stuff, then try reading things that other people have written and I'm just like "wahh?"
280 2012-06-14 17:01:26 <lukys> I think I need to go on an actual course with a real teacher
281 2012-06-14 17:01:36 <gmaxwell> When I started using Linux back in the SLS and early slackware days all linux was a lot more like gentoo than modern distros are. On my own systems I eventually walked them through the transistions from a.out binaries to elf and libc to glibc, both of which required recompiling everything.
282 2012-06-14 17:03:04 <gmaxwell> I've been recently recommending this to people: http://c.learncodethehardway.org/book/  though it presumes some preexisting programming expirence, it uses a very direct get down to business approach that I think is good.
283 2012-06-14 17:03:34 <Diablo-D3> c the hard way?
284 2012-06-14 17:03:42 <Diablo-D3> isnt it already hard enough?
285 2012-06-14 17:04:28 <gmaxwell> (In some ways C is a good beginning language though it's ruthless and hard the language itself is very small, so once you know the basics you won't find things which are completely foreign to you. C is hard because its very low level and you have to actually think clearly about what you want the machine to do)
286 2012-06-14 17:05:50 <BlueMatt> except then you have to go back and learn oop separately, but, I agree for the most part
287 2012-06-14 17:06:06 <Diablo-D3> C is a good language to think in, imo
288 2012-06-14 17:06:14 <Diablo-D3> its so brutal that it MAKES a programmer out of you
289 2012-06-14 17:06:22 <Diablo-D3> complete with disney musical scene.
290 2012-06-14 17:06:56 <Diablo-D3> I dont know why people hate C so much
291 2012-06-14 17:07:00 <Diablo-D3> its a wonderful language to code in
292 2012-06-14 17:07:04 <BlueMatt> agreed
293 2012-06-14 17:07:13 <luke-jr> yay C
294 2012-06-14 17:07:40 <Diablo-D3> it makes you think about every last line of code
295 2012-06-14 17:07:49 <Diablo-D3> so you're forced to write the best code possibly
296 2012-06-14 17:07:57 <Diablo-D3> none of this lazy shit java fucks you in the ass with
297 2012-06-14 17:10:06 <lukys> I have given C a go.
298 2012-06-14 17:10:19 <lukys> It seems great, I'm just bad at it.
299 2012-06-14 17:10:41 <Diablo-D3> like I said, it makes a programmer out of you
300 2012-06-14 17:10:52 <gmaxwell> Meh. The only way to be bad at it forever is to believe you're good at it.
301 2012-06-14 17:10:53 <lukys> I made a little number guessing game, which worked, but I couldn't figure out how to catch non-integers.
302 2012-06-14 17:10:55 <sneak> hi
303 2012-06-14 17:11:17 <lukys> So it broke if you typed in a letter or something.
304 2012-06-14 17:11:28 <gmaxwell> lukys: use strtol instead of atoi. :)
305 2012-06-14 17:11:28 <sneak> i think i am going to become a cpp hacker
306 2012-06-14 17:12:05 <gmaxwell> lukys: or be crazy and write your own code to iterate over the input and check for characters.
307 2012-06-14 17:12:22 <lukys> I tried that.
308 2012-06-14 17:12:29 <lukys> The latter, that is.
309 2012-06-14 17:12:33 <sneak> i like the idea of a reusable set of good code that isn't cocoa
310 2012-06-14 17:12:47 <sneak> and it seems like cpp (via boost and such) has that
311 2012-06-14 17:12:54 <sneak> i mean, i don't think it's an accident that bitcoin uses boost so much
312 2012-06-14 17:13:05 <gmaxwell> sneak: boost makes bitcoin a lot smaller than it would be other wise.
313 2012-06-14 17:13:20 <gmaxwell> Boost also introduces mysterious bugs from time to time. Mixed blessing.
314 2012-06-14 17:13:20 <sneak> i think that cpp+good libs is probably on par these days with, ex, interpereted languages
315 2012-06-14 17:13:26 <sneak> without being written in an interpreted language :)
316 2012-06-14 17:14:08 <BlueMatt> sneak: uhh...should be the other way around there
317 2012-06-14 17:14:18 <BlueMatt> interpreted languages are starting to catch up to cpp
318 2012-06-14 17:14:31 <sneak> i mean, in ease of development
319 2012-06-14 17:14:34 <sneak> rapid prototyping
320 2012-06-14 17:14:39 <sneak> not final output quality, obv compiled wins there
321 2012-06-14 17:15:42 <gmaxwell> maybe, debugability kinda sucks. C++ still admits low level failures like memory corruption, but unlike in C there are a zillion layers of indirection between the crash and your code.
322 2012-06-14 17:15:48 <BlueMatt> I find cpp much easier to develop in, you get errors at compile time...
323 2012-06-14 17:15:53 <BlueMatt> well, sanity errors
324 2012-06-14 17:16:03 <gmaxwell> BlueMatt: you do in java too.
325 2012-06-14 17:16:10 <BlueMatt> gmaxwell: thats half because of boost
326 2012-06-14 17:16:21 <BlueMatt> gmaxwell: and I find java easier to dev in than cpp
327 2012-06-14 17:16:23 <gmaxwell> The python sanity errors at runtime are just absolutely nuts.
328 2012-06-14 17:16:26 <BlueMatt> not that the result is any good...
329 2012-06-14 17:18:05 <gmaxwell> I went through a phase where I said "my time is more valuable than the CPUs' I'll use python for 100% of my single use programs"  only to have computations take 10 hours and then die when they were to print the solution because of a typo that the C compiler would have caught.. and meanwhile the same task in C completed in under a half hour.
330 2012-06-14 17:19:09 <BlueMatt> gmaxwell: yep, I never hit that phrase after being forced to use java for class and then writing c for single-use stuff and realizing its a billion and a half times faster...
331 2012-06-14 17:20:48 <gmaxwell> Java generally makes you write a lot of boilerplate, making it less good for rapid prototyping. Also, the fact that python integers are infinite range makes a lot of code simpler (well, at least for me).
332 2012-06-14 17:20:51 <BlueMatt> (yea, yea java is theoretically quick thanks to its good jit and whatnot, but...)
333 2012-06-14 17:21:02 <Diablo-D3> java boilertype fucking pisses me off
334 2012-06-14 17:21:06 <Diablo-D3> its one of the reasons I quit java
335 2012-06-14 17:21:22 <Diablo-D3> if Im going to write boilerplate, Im going to have fucking cpp do it for me
336 2012-06-14 17:21:25 <BlueMatt> gmaxwell: true, but use any ide and thats all done for you...
337 2012-06-14 17:22:03 <gmaxwell> I saw this the other day: http://blog.sanctum.geek.nz/series/unix-as-ide/
338 2012-06-14 17:22:26 <Diablo-D3> bluematt: thats the fucking problem
339 2012-06-14 17:22:28 <Diablo-D3> ides ruin code
340 2012-06-14 17:22:47 <Diablo-D3> vim, a few xterms with bash or man in them, one to run make in, bam
341 2012-06-14 17:22:49 <Diablo-D3> entire ide
342 2012-06-14 17:23:05 <BlueMatt> Diablo-D3: yep, thats my ide for cpp/c
343 2012-06-14 17:23:30 <lukys> xterminate!
344 2012-06-14 17:23:37 <lukys> >.>
345 2012-06-14 17:24:10 <Diablo-D3> <_<
346 2012-06-14 17:24:20 <jurov> i envy people that remember enough to code in just vim.... i tend to google almost every fking for cycle
347 2012-06-14 17:24:35 <sneak> i can't use gui editors now
348 2012-06-14 17:24:38 <sneak> after spending so much time in vim
349 2012-06-14 17:24:41 <gmaxwell> I spent 15 hours a day last week in a room with a couple of other coders getting a start on a new video codec, mostly prototyping and mathematics work. One of us is a Java+IDE user and he was a lot faster at working on certian tasks. So there are things that kind of enviroment does better.
350 2012-06-14 17:24:43 <sneak> even for personal todo lists
351 2012-06-14 17:25:46 <BlueMatt> gmaxwell: agreed, but it also removes some effort in trying to deal with the ide itself...
352 2012-06-14 17:25:50 <gmaxwell> jurov: the Learn C the hardway book rags on IDEs for causing that kind of short attention span and poor memory.  I never use google while programming, I do use man and grep a lot.
353 2012-06-14 17:26:17 <jurov> gmaxwell, i'd love to... but had to switch language evey year or so
354 2012-06-14 17:26:24 <BlueMatt> gmaxwell: s/man/cplusplus.com/ when working on cpp
355 2012-06-14 17:29:28 <jurov> anyone knows http://drakon-editor.sourceforge.net/ ? it's rather alien concept but i'm slowly but surely falling in love
356 2012-06-14 17:30:17 <jurov> but it can't import code and generated code can be unmaintainable :(
357 2012-06-14 17:32:33 <sneak> that's cool as hell
358 2012-06-14 17:32:39 <gmaxwell> jurov: There have been lots of visual programming languages made... they're interesting, but other than for dataflow problems (e.g. see Max/MSP, PD, and GNURadio) I've not seen them get wide adoption. Part of the challenge is that text is just a very efficient way to communicate.
359 2012-06-14 17:33:45 <sneak> i am thinking of writing a javascript-to-python transpiler
360 2012-06-14 17:33:58 <sneak> seeing as there's now an llvm-bytecode-to-javascript tool for compiling c to js
361 2012-06-14 17:34:04 <BlueMatt> sneak: Im 99% sure such a thing already exists
362 2012-06-14 17:34:27 <jurov> i agree but walls of text intimidate me.. and drakon scheme actually requires comparable screen estate to equivalent code
363 2012-06-14 17:34:29 <sneak> there's one for the other direction, pyjs
364 2012-06-14 17:35:00 <jurov> sneak, what would you use it for?
365 2012-06-14 17:35:01 <Diablo-D3> [03:24:41] <gmaxwell> I spent 15 hours a day last week in a room with a couple of other coders getting a start on a new video codec, mostly prototyping and mathematics work. One of us is a Java+IDE user and he was a lot faster at working on certian tasks. So there are things that kind of enviroment does better.
366 2012-06-14 17:35:03 <Diablo-D3> thats the problem
367 2012-06-14 17:35:05 <sneak> uglifyjs already spits out a nice AST from javascript
368 2012-06-14 17:35:06 <Diablo-D3> fast != good
369 2012-06-14 17:35:17 <sneak> jurov: well, if it can deal with the output of the c-to-javascript llvm thing
370 2012-06-14 17:35:23 <sneak> then i could make pure python versions of c libs
371 2012-06-14 17:35:36 <gmaxwell> Diablo-D3: it is for single use problem solving.. code that will be run once to a few times and then thrown out.
372 2012-06-14 17:35:51 <sneak> i'm trying to achieve the cross-platform holy grail for some apps i'm writing, and python seems like the path of least resistance in a lot of cases
373 2012-06-14 17:36:06 <sneak> python using only python stdlib is exceptionally portable, and easy to write
374 2012-06-14 17:36:13 <gmaxwell> haha
375 2012-06-14 17:36:14 <gmaxwell> sorry.
376 2012-06-14 17:36:22 <gmaxwell> You have a very narrow definition of portable. :)
377 2012-06-14 17:36:30 <sneak> unix, windows, osx
378 2012-06-14 17:37:04 <gmaxwell> Microcontrollers and other embedded devices? Lots of pretty powerful computers don't have enough memory to run a python interperter. :)
379 2012-06-14 17:37:14 <sneak> you'd be surprised these days
380 2012-06-14 17:37:41 <sneak> i'm in the process of building a home automation product built aroudn the beaglebone... $35 chip that has 256mb ram and full stack
381 2012-06-14 17:38:08 <sneak> it sounds insane but in the next few years "embedded" is going to mean "<=1gb ram"
382 2012-06-14 17:38:14 <gmaxwell> Yes, and the tasks you're asking it to do could be done just as well with a $5 microcontroller that uses 1/20th of the power. ::shrugs::
383 2012-06-14 17:38:21 <sneak> yes but time to market
384 2012-06-14 17:38:36 <BlueMatt> is similar
385 2012-06-14 17:38:42 <sneak> if there were 3 of me, i wouldn't care
386 2012-06-14 17:38:43 <gmaxwell> ::shrugs:: it's not particlarly hard to code for such things. E.g. if you write actually portable C.
387 2012-06-14 17:38:44 <sneak> but there's only one of me
388 2012-06-14 17:39:22 <sneak> i think it's easier to write python and stick to the stdlib and pure python extensions than to write "actually portable C"
389 2012-06-14 17:39:36 <sneak> certainly faster
390 2012-06-14 17:40:07 <sneak> i agree with your thing up above about the human time/cpu time tradeoff, and how dynamic languages can bite you in the ass
391 2012-06-14 17:40:08 <gmaxwell> Certantly easier to start. Once you consider debugging everything perhaps not, especially if you do run into any performance issues.
392 2012-06-14 17:40:10 <sneak> it's happened to me plenty
393 2012-06-14 17:40:51 <gmaxwell> If I didn't already know python fairly well I think I would learn LUA instead, as it appears to strike a better balance in that space.
394 2012-06-14 17:41:11 <gmaxwell> (I mean in the space of things where python is a reasonable consideration)
395 2012-06-14 17:41:20 <sneak> yeah
396 2012-06-14 17:41:26 <sneak> same, i think... but i already know python.
397 2012-06-14 17:41:40 <sneak> i like that python is also easily embeddable on osx for building native cocoa apps
398 2012-06-14 17:41:55 <sneak> do a python core, with native cocoa ui that talks to it via rpc
399 2012-06-14 17:42:07 <sneak> that's how i'm building the p2p app i'm working on now
400 2012-06-14 17:42:33 <sneak> in-process rpc using shared memory via zeromq
401 2012-06-14 17:42:38 <sturles> Or Forth.  Even the simplest 8 bit AVR can run a Forth intepreter.
402 2012-06-14 17:43:19 <gmaxwell> I have a big "meh" feeling about very high level languages for network apps. It's very easy to leak language implementation details into the effective protocol specification making it very hard to write interoperable alternatives in other languages without dealing with a bunch of implicit corner cases.
403 2012-06-14 17:43:33 <gmaxwell> Bitcoin suffers this problem and it's merely written in C++.
404 2012-06-14 17:43:50 <luke-jr> well, that's because Satoshi sucks sometimes
405 2012-06-14 17:43:52 <luke-jr> -.-
406 2012-06-14 17:44:01 <gmaxwell> But e.g. details about how openssl and bdb work manage to leak out into the protocol behavior.
407 2012-06-14 17:44:05 <sneak> gmaxwell: agreed but protobuf helps.
408 2012-06-14 17:44:06 <luke-jr> srsly, you're not supposed to ever access raw memory data like that
409 2012-06-14 17:44:27 <sneak> how does bdb leak out?
410 2012-06-14 17:45:05 <sneak> the on-disk stuff is the part of the bitcoin code i've looked at least
411 2012-06-14 17:45:34 <gmaxwell> sneak: for example, the issues we've had with reorgs turn BDB gotchas into effective protocol rules.
412 2012-06-14 17:46:07 <gmaxwell> e.g. an alternative implementation which didn't fail to perform reorgs with 'too many transactions' would be at risk of getting nocked onto different forks from the reference bitcoin nodes.
413 2012-06-14 17:46:07 <luke-jr> gmaxwell: ?
414 2012-06-14 17:46:16 <sneak> ahh
415 2012-06-14 17:46:34 <luke-jr> gmaxwell: I don't see that as a protocol rule, but a bitcoind bug.
416 2012-06-14 17:46:43 <sneak> yeah, i tend to think going to a higher level language would _prevent_ stuff lik that personally
417 2012-06-14 17:47:02 <sneak> luke-jr: well it's a "bitcoin network" bug, because the bitcoin network runs bitcoind mostly
418 2012-06-14 17:47:10 <sneak> he's got a great point though
419 2012-06-14 17:47:11 <luke-jr> sneak: it was fixed in master
420 2012-06-14 17:47:22 <luke-jr> though I think that fix introduces new similar bugs
421 2012-06-14 17:47:27 <sneak> heh
422 2012-06-14 17:47:46 <sneak> are there public stats on client version breakdowns in the wild?
423 2012-06-14 17:48:10 <luke-jr> sneak: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
424 2012-06-14 17:49:14 <gmaxwell> luke-jr: right, I agree, but my point was that basically the use of all these complicated high level tools in the normative part of the implementation basically turns their subtle and sometimes undocumented behavior into effective rules. You can call them bugs if they're rules we didn't intend, but the program acts the same no matter what you call them.
425 2012-06-14 17:49:43 <ThomasV> question: if I restart bitcoind, my memorypool will accept only newly forwarded transactions. Will it reject all the transactions that depend on currently unconfirmed inputs? (I guess ConnectInputs should fail because the previous input is not in my mempool)
426 2012-06-14 17:49:45 <sneak> i'm really glad there are people thinking this way in the decentralized software world
427 2012-06-14 17:50:06 <sneak> these sorts of "entire network as the program state" things are really cool
428 2012-06-14 17:50:18 <sneak> i've been building distributed systems for the last few years and it's a fun challenge
429 2012-06-14 17:59:12 <jgarzik> ThomasV: it will consider the latter orphan transactions, and store those in a special, separate pool
430 2012-06-14 17:59:41 <jgarzik> ThomasV: TX must validate in all ways except actually being connect-able
431 2012-06-14 18:00:10 <ThomasV> jgarzik: I see. I was not sure how a newly started bitcoind could catch up with satoshidice :)
432 2012-06-14 18:07:21 <jgarzik> ThomasV: a newly started bitcoind only catches up to the latest block, not unconfirmed transactions
433 2012-06-14 18:07:52 <jgarzik> ThomasV: unconfirmed transactions are considered volatile, and must be retransmitted until they make it into a block
434 2012-06-14 18:07:52 <ThomasV> huh?
435 2012-06-14 18:08:02 <ThomasV> yes I got that
436 2012-06-14 18:09:15 <jgarzik> ThomasV: a newly started bitcoin does not -request- unconfirmed transactions from remote nodes.  it starts receiving TX solicitations immediately, but never requests the TX queue of any remote node.
437 2012-06-14 18:10:02 <ThomasV> jgarzik: yes, I know. that's why I was wondering why a freshly started bitcoind accepts satoshidice txes at all
438 2012-06-14 18:10:09 <Joric> is anyone good at licenses? for now i guess MIT prohibits using author's name in ads, BSD endorses it? sounds right..ish?
439 2012-06-14 18:10:39 <jgarzik> ThomasV: it accepts them as orphan tx's if they cannot be connected.  it accepts them as normal tx's if they can be connected.
440 2012-06-14 18:11:04 <ThomasV> yes.I wasnt aware of that separate pool
441 2012-06-14 18:13:37 <jgarzik> with all the satoshidice TX's, we have been seeing half-full blocks frequently
442 2012-06-14 18:14:01 <jgarzik> one wonders how quickly we'll approach 1MB
443 2012-06-14 18:14:32 <wizkid057> at this rate it probably wont be long
444 2012-06-14 18:19:11 <gmaxwell> Hm? it'll be infinite.
445 2012-06-14 18:19:19 <gmaxwell> by default nodes soft limit to half.
446 2012-06-14 18:19:29 <gmaxwell> And I don't see any miners lifting the soft limit for _this_.
447 2012-06-14 18:20:44 <gmaxwell> (if they want to go modify the code, better to modify it to just strongly deprioritize or drop the dice txn) and leave the softcap alone.
448 2012-06-14 18:24:10 <BlueMatt> or is it (finally) time to limit relaying of addresses that have very high volume?
449 2012-06-14 18:24:35 <gmaxwell> I liked the idea you had about checking the memory pool.
450 2012-06-14 18:25:15 <gmaxwell> Essentially creating a per address rate limit. Would address these specific trouble areas while encouraging generally good behavior.
451 2012-06-14 18:25:33 <BlueMatt> been discussing it pretty much all day on bitcointalk: https://bitcointalk.org/index.php?topic=87444.0;all
452 2012-06-14 18:25:40 <gavinandresen> meh. So they'll create 1,000 1dice addresses and rotate them....
453 2012-06-14 18:25:54 <gavinandresen> transaction fees are the answer
454 2012-06-14 18:26:10 <BlueMatt> gavinandresen: yea, but that means they have to put in more effort, and if you're gonna do that, might as well just do multisend
455 2012-06-14 18:26:15 <gmaxwell> gavinandresen: The argument for not having accounts to combine transactions is that using the addresses is easier.
456 2012-06-14 18:26:18 <BlueMatt> fixes the underlying issue and gets around the limit
457 2012-06-14 18:26:34 <jgarzik> BlueMatt: have you directly contacted satoshidice people and asked them to use multisend?
458 2012-06-14 18:26:37 <gmaxwell> If there are addresses you have to rotate between you might as well not be using 1txn per gamble.
459 2012-06-14 18:26:38 <Eliel> gavinandresen: if they have to create more addresses, that would curtail the problem because it'll reduce the userfriendlyness.
460 2012-06-14 18:26:42 <BlueMatt> jgarzik: they commented in that thread
461 2012-06-14 18:26:49 <luke-jr> jgarzik: not sure multisend helps here <.<
462 2012-06-14 18:26:51 <BlueMatt> also: discourages green addresses, which also generate too many txes
463 2012-06-14 18:27:04 <BlueMatt> luke-jr: ofc it does, less txindex.dat volume, which is the biggest issue
464 2012-06-14 18:27:11 <luke-jr> hmm
465 2012-06-14 18:27:53 <BlueMatt> (or: allows green addresses to accept a longer confirmation time, which is acceptable for green addresses)
466 2012-06-14 18:28:07 <gmaxwell> Basically there are a swath of behaviors which are both high in chain bloat and bad for user privacy which involve constantly reusing the same addresses. These activities themselves also don't tend to need fast confirmations, so depriortizing them makes sense.
467 2012-06-14 18:28:13 <BlueMatt> also: encourages people to use rotating addresses, which is good for user privacy
468 2012-06-14 18:28:36 <luke-jr> one time someone asked me to use green addresses so they could accept Eligius payouts at 0 confirmations&
469 2012-06-14 18:28:47 <gmaxwell> 0_o
470 2012-06-14 18:29:08 <gavinandresen> I say let users pick their priority via transaction fees.  Fix the client so it looks at blocks to figure what a 'reasonable' fee/kb is, and fix the block creation code so it sorts by fee/kb
471 2012-06-14 18:29:14 <luke-jr> yeah& I was like "you don't *really* want to do that&"
472 2012-06-14 18:29:45 <luke-jr> gavinandresen: I have a pullreq for that, a few weeks old now..
473 2012-06-14 18:29:46 <gmaxwell> gavinandresen: but what happens when you want less than the zero fee priority?
474 2012-06-14 18:29:52 <BlueMatt> jgarzik: they already are
475 2012-06-14 18:30:19 <BlueMatt> gavinandresen: sadly, the impacts of satoshidice are largely on end-users not miners nor satoshidice, as miners get paid anywa
476 2012-06-14 18:30:19 <gavinandresen> luke-jr: which pullreq?  You wrote code for the client that looks at previous blocks and figures out a reasonable fee/kb ?
477 2012-06-14 18:30:28 <luke-jr> gavinandresen: oh, that side, no
478 2012-06-14 18:30:33 <BlueMatt> the idea is to give end-users a tiny bit of impact on the txes that get confirmed
479 2012-06-14 18:30:36 <luke-jr> gavinandresen: mine just pays attention to fees when prioritizing
480 2012-06-14 18:30:39 <gavinandresen> luke-jr: we need both sides of the equation
481 2012-06-14 18:30:41 <gmaxwell> gavinandresen: because e.g. you're a spamming gambling site that bloats the chain like crazy just so you can use unconfirmed txns... since you don't need confirmations at all you really want less than zero-fee priority (to make up for your bloat)
482 2012-06-14 18:31:03 <gmaxwell> jgarzik: it _does_ crowd them out currently.
483 2012-06-14 18:31:04 <luke-jr> gavinandresen: you can't guess appropriate fees by looking at blocks, though
484 2012-06-14 18:31:35 <gavinandresen> luke-jr: yeah, yeah, special arrangements with miners will throw things off....
485 2012-06-14 18:31:38 <luke-jr> https://github.com/bitcoin/bitcoin/pull/1240 is the miner side
486 2012-06-14 18:31:45 <gmaxwell> people are already all twichy about fees because they feel they can't predict them. Making them depend on blocks will make that worse.
487 2012-06-14 18:31:59 <gavinandresen> ... but it'd still be better than the fixed, dumb fee rules we have now.
488 2012-06-14 18:32:26 <luke-jr> gavinandresen: seems like a LOT of coding, for something that needs to be fixed still
489 2012-06-14 18:32:33 <BlueMatt> gavinandresen: yep, but thats a separate discussion from green-address-relay-discouraging
490 2012-06-14 18:32:34 <gmaxwell> one reason that people don't set non-zero default fees is because they're per-KB.. so setting 0.01 means you'll pay anywhere from 0.01 to 1 BTC in fees depending on the inputs selected.
491 2012-06-14 18:32:46 <gavinandresen> We've got a limited resource (space in blocks), the only rational way to allocate it is to create a market.
492 2012-06-14 18:34:06 <gmaxwell> gavinandresen: I'm fine with the create a market. But I think that the market should be setup so that the basline behavior allows service worse than zero fee.
493 2012-06-14 18:34:08 <BlueMatt> gavinandresen: creating a market and letting sites like satoshidice pay their way into every block crowds out a /ton/ of current users
494 2012-06-14 18:34:18 <BlueMatt> gavinandresen: whereas satoshidice doesnt care if its txes get confirmed fast or not
495 2012-06-14 18:35:01 <gavinandresen> BlueMatt: if satoshidice doesn't care how fast they get confirmed then they'll set low fees.  The default behavior of the client should be to attache a fee high enough to crowd them out.
496 2012-06-14 18:35:47 <BlueMatt> then you crowd out a ton of existing users who use bitcoin because it is 0 fee and they still get their txes confirmed in some amount of time
497 2012-06-14 18:36:04 <gmaxwell> well, then we need to do something about the per KB-ness.. because having a 100x dynamic range on the fees you pay isn't acceptable if the minimum amount is non-trivial.
498 2012-06-14 18:36:11 <BlueMatt> whereas as satoshidice, or really most green address users, will accept a few extra blocks confirmation time
499 2012-06-14 18:36:20 <BlueMatt> gmaxwell: yes
500 2012-06-14 18:36:57 <gavinandresen> Why do we need to so something about the per-KB-ness?  Getting tiny payouts from a mining pool is bad for the network and should be discouraged....
501 2012-06-14 18:37:00 <BlueMatt> but as a customer paying for my lunch, I dont wanna have to wait a week to confirm
502 2012-06-14 18:37:15 <gmaxwell> Right. We have users who we could expect to voluntarily identify as wanting lower priority to leave room for lower fees for normal users. Why ignore that information?
503 2012-06-14 18:37:26 <gavinandresen> Paying for lunch is a totally separate problem/issue.
504 2012-06-14 18:37:54 <BlueMatt> gavinandresen: but its exactly the type of transaction that will be crowded out if we start making everyone pay big fees
505 2012-06-14 18:38:12 <gmaxwell> gavinandresen: Because people are disinterested in setting 0.01/KB due to anxiety about potentially paying a $6 txn fee for a few dollar value transaction.
506 2012-06-14 18:39:11 <gavinandresen> I'm NOT suggesting that people set the fee, I'm suggesting the client should be smart and suggest "if you want this to confirm quickly, X."  "If you don't care, Y" ... for fees
507 2012-06-14 18:39:55 <luke-jr> gmaxwell: I have a pullreq that sets an upper limit on txn fees attached
508 2012-06-14 18:40:06 <gmaxwell> Yea, great. So they're going to send 0.5 BTC and get told 'If you want this to confirm quickly pay .8 BTC in fees', and then they say no and get a two week confirmation.
509 2012-06-14 18:40:19 <gavinandresen> Looking at the fees paid by transactions in the last 50 blocks should get a pretty good idea of what X and Y should be.
510 2012-06-14 18:40:55 <Diapolo> Are you discussing a QoS-style thing here?
511 2012-06-14 18:41:04 <gavinandresen> gmaxwell: and the alternative is.....
512 2012-06-14 18:41:22 <luke-jr> (did anyone lart Diapolo for earlier yet?)
513 2012-06-14 18:41:23 <ciscoftw> reminds me of this; http://research.microsoft.com/pubs/156072/bitcoin.pdf
514 2012-06-14 18:41:35 <gmaxwell> gavinandresen: fix the base behavior so that X  is more like 0.01 BTC instead of 1 BTC.
515 2012-06-14 18:41:43 <BlueMatt> ciscoftw: btw, that paper is wrong
516 2012-06-14 18:41:44 <gavinandresen> back in a few minutes...
517 2012-06-14 18:41:56 <gmaxwell> ciscoftw: that is so entirely unrelated I have no clue why you're linking to it.
518 2012-06-14 18:42:00 <Diapolo> luke-jr: What is lart?
519 2012-06-14 18:42:25 <ciscoftw> regarding fee's
520 2012-06-14 18:42:40 <luke-jr> Diapolo: Luser Attitude Readjustment Tool :p
521 2012-06-14 18:42:48 <luke-jr> Diapolo: you broke test_bitcoin ;)
522 2012-06-14 18:43:11 <BlueMatt> gavinandresen: I think that is absolutely the way fees are gonna end up going, so I have no problem with doing that kind of thing now...but, as gmaxwell puts it, "We have users who we could expect to voluntarily identify as wanting lower priority to leave room for lower fees for normal users. Why ignore that information?"
523 2012-06-14 18:43:49 <Diapolo> luke-jr: Because no one tried out the pull with Gitian I guess ;)?
524 2012-06-14 18:43:52 <luke-jr> BlueMatt: why would miners act on it, if it means they lose out on more fees?
525 2012-06-14 18:44:02 <luke-jr> Diapolo: gitian has nothing to do with it
526 2012-06-14 18:44:10 <BlueMatt> luke-jr: they wont, thats why end-users and relayers have to act on it
527 2012-06-14 18:44:11 <gmaxwell> We even have a good metric that they're sending already already: address reuse.
528 2012-06-14 18:44:24 <luke-jr> BlueMatt: then the original user can simply not broadcast it immediatley
529 2012-06-14 18:44:36 <Diapolo> luke-jr: Whatever, on my setup that test is not compiled so I couldn't see that error.
530 2012-06-14 18:44:38 <BlueMatt> luke-jr: ok, and that will get the same result...
531 2012-06-14 18:44:43 <gmaxwell> luke-jr: do you really care about losing out on a few bitcents? if it means making bitcoin more usable for regular txn?
532 2012-06-14 18:45:25 <luke-jr> gmaxwell: I don't think the answer is delaying the fee-payers, but encouraging the cheapskates to include fees
533 2012-06-14 18:45:51 <gmaxwell> luke-jr: 0.0005 BTC is hardly a fee.
534 2012-06-14 18:46:05 <Diapolo> I somehow dislike the idea of pay more to get a faster TX ... reminds me of a net neutrality debate somehow.
535 2012-06-14 18:46:05 <luke-jr> gmaxwell: then other people should have no problem paying 0.001 BTC
536 2012-06-14 18:46:16 <gmaxwell> Diapolo: it's pretty fundimental to the system.
537 2012-06-14 18:46:26 <jgarzik> BlueMatt has a fair point, IMO.  It is analagous to voluntarily-provided IP ToS/DSCP hints
538 2012-06-14 18:47:14 <luke-jr> IMO, the transaction fee is the analogy to IP ToS/DSCP hints
539 2012-06-14 18:47:34 <BlueMatt> oh, this discussion sparked another good pruning thing we could do to txindex -> dont write txes that are being fully spent later in the same block to txinex
540 2012-06-14 18:47:50 <luke-jr> BlueMatt: that would probably help
541 2012-06-14 18:47:51 <gmaxwell> The neat thing is that the things which don't need confirmations are also the things creating a lot of excessive txn (because the security processes they use create more txn), and they're also easily identifyable by their address reuse.
542 2012-06-14 18:48:28 <Diapolo> To get a clue, what is the current goal in terms of the fees?
543 2012-06-14 18:48:39 <Diapolo> or let's say long term goal
544 2012-06-14 18:48:43 <luke-jr> Diapolo: the purpose of fees in Bitcoin, is to subsidize the miners' costs
545 2012-06-14 18:49:08 <ciscoftw> bitminter
546 2012-06-14 18:49:32 <luke-jr> as things stand right now, I expect a lot of GPU miners are going to disappear in the fall
547 2012-06-14 18:50:08 <Nolybab> hello...been lurking for a while, just returned to my keyboard
548 2012-06-14 18:50:19 <Diapolo> Yes, but what is that how much thing going on with the fees? Is there a fear the network will suffer when we reach 25BTC per block?
549 2012-06-14 18:50:33 <wizkid057> luke-jr: if this happened pretty quickly, wouldnt that cause some issues as far as greatly delaying blocks for a while?
550 2012-06-14 18:50:35 <luke-jr> Diapolo: that's one side of the equation
551 2012-06-14 18:50:47 <luke-jr> wizkid057: yes
552 2012-06-14 18:50:55 <luke-jr> until the difficulty catches up
553 2012-06-14 18:51:21 <wizkid057> perhaps a solution to this should be something along the lines of the difficulty adjusting more quickly for the first month after a block reward change
554 2012-06-14 18:51:41 <luke-jr> wizkid057: that'd make hardforks
555 2012-06-14 18:51:45 <Diapolo> btw. are there any testnet3 nodes up, it takes ages for testnet blocks to mature for me ...
556 2012-06-14 18:51:54 <gmaxwell> wizkid057: I don't really think there is an issue there.
557 2012-06-14 18:52:00 <wizkid057> luke-jr: people have like, 5 months to upgrade....
558 2012-06-14 18:52:07 <Diapolo> currently I even don't get a connection to a node
559 2012-06-14 18:52:12 <luke-jr> wizkid057: and there's still people using 0.3
560 2012-06-14 18:52:17 <Nolybab> is the link ciscoftw posted familiar to everyone (newbie here, obviously)
561 2012-06-14 18:52:27 <gmaxwell> Diapolo: sure, but not much mining. I only mine after 20 minutes have passed.
562 2012-06-14 18:53:04 <luke-jr> wizkid057: and we have much more important reasons to hardfork, but opted not to thus far
563 2012-06-14 18:53:23 <gmaxwell> wizkid057: you're presuming irrational behavior in any case. There is no reason to expect a pointwise discontinuity in hashrate.
564 2012-06-14 18:53:41 <wizkid057> there's pleanty of reason...
565 2012-06-14 18:53:51 <gmaxwell> wizkid057: if mining becomes unprofitable for you you should be getting rid of your gear _before_ the change to get ahead of the flooded market.
566 2012-06-14 18:54:16 <wizkid057> mining is always profitable for me, but, thats not the norm
567 2012-06-14 18:54:37 <gmaxwell> I didn't mean you you, I meant the platonic you.
568 2012-06-14 18:55:04 <wizkid057> you also assume that most miners even realize that this date is approaching
569 2012-06-14 18:55:06 <luke-jr> gmaxwell: only if you expect to profit from resale
570 2012-06-14 18:55:46 <jgarzik> luke-jr: transaction fee is different.  consider real-world shipping: rates and classes of service are separate, though clearly related.  you might pay same rate, but select a different class of freight service (slower, yet more reliable).
571 2012-06-14 18:56:12 <luke-jr> jgarzik: I don't think Bitcoin has "slower, yet more reliable" service :P
572 2012-06-14 18:56:18 <gmaxwell> It could.
573 2012-06-14 18:56:20 <luke-jr> speed and reliability are the same thing
574 2012-06-14 18:56:24 <luke-jr> gmaxwell: how?
575 2012-06-14 18:56:28 <jgarzik> irrelevant to overall analogy
576 2012-06-14 18:56:44 <gmaxwell> For example, one reason to have low priority txn would be to keep them around for replacement in order to save fees.
577 2012-06-14 18:57:03 <luke-jr> &
578 2012-06-14 18:57:22 <gmaxwell> e.g. I send you 1 BTC low priority, but before its mined, I find I need to send you more.. so I replace it with a 2 BTC payment and make just one txn instead of two.
579 2012-06-14 18:57:25 <luke-jr> why would a miner hold off mining a transaction just so you could remove the fee?
580 2012-06-14 18:57:37 <gmaxwell> and since you trusted my unconfirmed txns this didn't delay anything.
581 2012-06-14 18:57:56 <luke-jr> hmm
582 2012-06-14 18:58:03 <gmaxwell> not remove the fee, but use less blockspace kilobytes.
583 2012-06-14 18:58:09 <luke-jr> I suppose
584 2012-06-14 18:58:30 <gmaxwell> gavinandresen: also wrt tiny inputs, since we're getting closer to pruning we ought to have a priority fee metric that rewards people for reducing the number of open txn in the blockchain.
585 2012-06-14 19:00:26 <gmaxwell> e.g. using the net change in pruned blockchain size plus some constant as the fee metric instead of the size of the transaction.
586 2012-06-14 19:02:06 <wizkid057> can we prune satoshidice from existance?
587 2012-06-14 19:02:15 <BlueMatt> has anyone spent more time acking https://github.com/bitcoin/bitcoin/pull/1405 ?
588 2012-06-14 19:02:34 <gmaxwell> wizkid057: I already suggested the tool for that.
589 2012-06-14 19:02:54 <wizkid057> gmaxwell: did i miss it?
590 2012-06-14 19:03:11 <gmaxwell> wizkid057: No, you didn't. I suggested using a prediction market.
591 2012-06-14 19:03:21 <wizkid057> oh, lol
592 2012-06-14 19:06:28 <[Tycho]> Can anyone tell me if deprioritizing 1dice is good or bad ?
593 2012-06-14 19:06:49 <BlueMatt> [Tycho]: thats what we're discussing
594 2012-06-14 19:07:00 <BlueMatt> actually, more broadly, deprioritizing high-use addresses
595 2012-06-14 19:07:04 <BlueMatt> including deepbit
596 2012-06-14 19:07:22 <BlueMatt> [Tycho]: I think the consensus is generally good
597 2012-06-14 19:07:42 <gmaxwell> I don't know that anyone thinks depriortizing it is _bad_... maybe just pointless.
598 2012-06-14 19:08:10 <BlueMatt> as long as they're using 1dice its not ;)
599 2012-06-14 19:09:00 <gmaxwell> well maybe.. I mean, the volume of txn still exists and will need to go in sometime.
600 2012-06-14 19:09:01 <luke-jr> [Tycho]: the rationale seems to be that using the same address means green addresses means you can wait longer for confirmations because they're accepted at 0conf anyway
601 2012-06-14 19:09:30 <luke-jr> I think more important is getting the people complaining to pay fees ;)
602 2012-06-14 19:09:34 <BlueMatt> gmaxwell: well it could still encourage multisend
603 2012-06-14 19:09:38 <jgarzik> [Tycho]: IMO it is mainly a question of whether or not satoshidice are harming "regular users"
604 2012-06-14 19:09:49 <jgarzik> [Tycho]: is satoshidice increasing confirmation times for everyone else?
605 2012-06-14 19:09:51 <jgarzik> if so...
606 2012-06-14 19:10:06 <BlueMatt> yes
607 2012-06-14 19:10:10 <BlueMatt> they are
608 2012-06-14 19:10:15 <gmaxwell> I don't think the existance of harm is in question, only the magnitude. People are showing up confused and angry about long confirmation times. But perhaps it's only a few people.
609 2012-06-14 19:10:54 <luke-jr> gmaxwell: so those people should be told to pay 0.001 BTC fees
610 2012-06-14 19:11:02 <luke-jr> and do what we can to make it easier
611 2012-06-14 19:11:06 <Diapolo> So to nail it down is to decrease priority for things that could be considered background-noise in the network :D.
612 2012-06-14 19:11:11 <luke-jr> so, allowing adding fees after the fact, for example
613 2012-06-14 19:11:47 <luke-jr> oh, there's another idea&
614 2012-06-14 19:11:53 <luke-jr> instead of trying to guess fees up front
615 2012-06-14 19:12:00 <gmaxwell> luke-jr: people spaz out and get angry about 0.0005 up front.
616 2012-06-14 19:12:04 <[Tycho]> Yes, they are.
617 2012-06-14 19:12:05 <luke-jr> just track priorities in the client
618 2012-06-14 19:12:10 <luke-jr> and add fees as blocks ignore your txn
619 2012-06-14 19:12:15 <gmaxwell> luke-jr: auto fee bidding would be a big incentive to intentionally delay txn in order to cause them to bid up.
620 2012-06-14 19:12:21 <[Tycho]> That's why I'm now messing with priority things.
621 2012-06-14 19:12:48 <BlueMatt> [Tycho]: while you're at it, multisend would be nice ;)
622 2012-06-14 19:13:02 <luke-jr> gmaxwell: is that a problem?
623 2012-06-14 19:13:06 <luke-jr> gmaxwell: people would still be setting maximum bids
624 2012-06-14 19:13:14 <[Tycho]> No, that's completely different part.
625 2012-06-14 19:13:17 <luke-jr> and they can't delay them *forever*
626 2012-06-14 19:13:26 <BlueMatt> yes they can
627 2012-06-14 19:13:35 <luke-jr> BlueMatt: not if they ever want a fee
628 2012-06-14 19:13:52 <luke-jr> every block MinerA delays accepting TxnA, is a block MinerB might take it
629 2012-06-14 19:14:04 <luke-jr> so as long as we have a competitive mining market&
630 2012-06-14 19:14:14 <BlueMatt> oh, you are saying >0 fees
631 2012-06-14 19:14:14 <luke-jr> it's either "take it or leave it" pretty much
632 2012-06-14 19:14:35 <gmaxwell> luke-jr: Perhaps.
633 2012-06-14 19:15:05 <luke-jr> BlueMatt: yeah, 0 fee txns might get left waiting always
634 2012-06-14 19:15:09 <luke-jr> but IMO that's ok
635 2012-06-14 19:15:16 <luke-jr> charity cases can wait :P
636 2012-06-14 19:15:19 <BlueMatt> luke-jr: its not imo
637 2012-06-14 19:15:40 <luke-jr> I don't mean they wait forever
638 2012-06-14 19:15:44 <BlueMatt> we shouldnt design a system that results in encouraging 0-fee txes never being acepted
639 2012-06-14 19:15:48 <luke-jr> but at some point, it will be obvious they're not being bid up
640 2012-06-14 19:15:52 <BlueMatt> but they likely will
641 2012-06-14 19:15:53 <luke-jr> and some nice miner will confirm them
642 2012-06-14 19:16:09 <luke-jr> BlueMatt: likely they will be accepted *eventually*
643 2012-06-14 19:16:16 <BlueMatt> ok, but the incentives are that they wont
644 2012-06-14 19:16:33 <luke-jr> only in the same sense that they are now
645 2012-06-14 19:16:39 <luke-jr> there is no reason for miners to accept them now either
646 2012-06-14 19:16:53 <BlueMatt> ok, but it increases incentives in your system
647 2012-06-14 19:16:57 <luke-jr> no
648 2012-06-14 19:17:02 <gmaxwell> It does, but meh.
649 2012-06-14 19:17:14 <luke-jr> gmaxwell: it increases the incentive to *never* confirm 0fees?
650 2012-06-14 19:17:20 <BlueMatt> yes, because its possible that you will eventually get a fee
651 2012-06-14 19:17:24 <gmaxwell> Why accept it? it may be more later... and if someone else accepts it.. so what?
652 2012-06-14 19:17:31 <luke-jr> BlueMatt: that's an unavoidable reality.
653 2012-06-14 19:17:40 <luke-jr> gmaxwell: OK, so why accept it now?
654 2012-06-14 19:17:45 <gmaxwell> it makes it more likely. Though I dunno if I care.
655 2012-06-14 19:18:10 <gmaxwell> luke-jr: because it likely won't ever be increased now, so not accepting just makes bitcoin suck. (unless it's a DOS attack, in which case.. great!)
656 2012-06-14 19:18:15 <BlueMatt> luke-jr: shifting the option to add fees to tx receiver I like
657 2012-06-14 19:18:29 <BlueMatt> letting the user add more later I dont
658 2012-06-14 19:18:44 <gmaxwell> I think like all complicated issues the solution to this is "all of the above"
659 2012-06-14 19:18:56 <luke-jr> gmaxwell: but we *need* the ability to increase fees IMO
660 2012-06-14 19:19:06 <luke-jr> gmaxwell: at the very least, it's far more important than leeches who don't pay them
661 2012-06-14 19:19:09 <gmaxwell> Yes, there should be fee replacements, yes there should be fee recommendations, yes there should be deprioritization of obvious low prio transactions.
662 2012-06-14 19:19:26 <BlueMatt> luke-jr: Im sorry you are a miner and consider 0fee txes leeches, I consider them important bitcoin sers
663 2012-06-14 19:19:29 <BlueMatt> users
664 2012-06-14 19:19:52 <jgarzik> 0-fee users are very important to bitcoin's adoption right now
665 2012-06-14 19:20:21 <gmaxwell> meh, everyone is a leech now. The way I look at it future bitcoin users are subsidizing our chain bloat in order to foster the adoption of bitcoin which will allow them to exist in the future. But I'm weird.
666 2012-06-14 19:20:23 <BlueMatt> and I think they will continue to be as long as bitcoin is growing
667 2012-06-14 19:20:33 <luke-jr> they're important, but not so important that they can't wait
668 2012-06-14 19:20:43 <BlueMatt> disagree entirely
669 2012-06-14 19:20:55 <gmaxwell> (I say everyone is a leech because a 0.0005 btc fee is nothing currently.. its a fraction of a cent.. you lose more to rounding up on taxes in typical transactions with cash)
670 2012-06-14 19:21:24 <luke-jr> gmaxwell: sure, to an extent, everyone is leeching off the subsidy right now
671 2012-06-14 19:21:38 <gmaxwell> luke-jr: people have weird mental interactions with fees. If you only have a few btc then a 0.0005 btc fee a fraction of a cent for some reason makes a lot of people obsess and become unhappy.
672 2012-06-14 19:22:04 <gmaxwell> bitcoin has to be more attractive as a system for people to get over that, but nothing will create that attraction except time and adoption.
673 2012-06-14 19:22:06 <ThomasV> gmaxwell: it's because there is the mental overhead of having to think about it
674 2012-06-14 19:22:08 <luke-jr> gmaxwell: I think part of that is they don't have the  choice to wait
675 2012-06-14 19:22:10 <BlueMatt> and as long as we are as small as we are, thats an important problem imho
676 2012-06-14 19:22:43 <BlueMatt> 0fee txes should be useable for as long as we can make them
677 2012-06-14 19:22:51 <gmaxwell> ThomasV: I've found that pointing out to people that the default mandatory fees can never go over 0.05 BTC with the current software really helps some people relax, which supports that theory.
678 2012-06-14 19:23:12 <luke-jr> BlueMatt: txn_prio allows 0fee txes to be mined when the recipient adds a fee ;)
679 2012-06-14 19:23:17 <someone42> what about allocating a fixed portion (eg. 10%) of maximum block size for 0 fee tx?
680 2012-06-14 19:23:39 <jgarzik> there is already a free tx area, of a sort
681 2012-06-14 19:23:41 <BlueMatt> luke-jr: which is a good feature for the future, but isnt related to my statement
682 2012-06-14 19:23:55 <BlueMatt> someone42: only way to do that, really, is a hardfork
683 2012-06-14 19:23:59 <gmaxwell> BlueMatt: I agree, but at the same time we must not compromise what makes the system valuable. E.g. a conspiracy of miners to totally block 1dice txn would enable zero fees but would call the value of bitcoin itself into question.
684 2012-06-14 19:24:11 <Nolybab> bingo gmaxwell
685 2012-06-14 19:24:19 <BlueMatt> gmaxwell: agreed
686 2012-06-14 19:24:19 <someone42> jgarzik: oh, cool
687 2012-06-14 19:24:33 <BlueMatt> gmaxwell: but deprioritizing 1dice so that we can have 0fee txes work doesnt
688 2012-06-14 19:24:36 <ThomasV> 1dice increased miners revenue
689 2012-06-14 19:24:49 <gmaxwell> someone42: so if I'm a miner that doesn't want zero fee txn in my blocks I'll just fill that 10% with txn to myself.
690 2012-06-14 19:24:53 <gmaxwell> ThomasV: only very slightly.
691 2012-06-14 19:25:29 <luke-jr> gmaxwell: I think his point wasn't to require that 10%, but only let you use free txns to fill the block to max
692 2012-06-14 19:25:31 <gmaxwell> ThomasV: not even enough to pay for the disk space the chain growth takes up.
693 2012-06-14 19:25:46 <luke-jr> gmaxwell: so you can only get to 90% capacity with fees
694 2012-06-14 19:25:51 <jgarzik> if we could get it down to just a few bytes, encoding fee policy metadata in coinbase would be interesting
695 2012-06-14 19:25:51 <ThomasV> gmaxwell: only because of the block reward.
696 2012-06-14 19:26:08 <jgarzik> (not a new idea, I grant)
697 2012-06-14 19:26:09 <luke-jr> someone42: also note that in the future, we don't need/want to appease 0fee txns at all ;)
698 2012-06-14 19:26:32 <luke-jr> jgarzik: the latest idea for that is an alert-like broadcast system, so they can be updated
699 2012-06-14 19:26:35 <gmaxwell> jgarzik: no need to do that.. Just use the coinbases public key to signmessage fee statements... then nodes don't have to carry that data around 1000 years from now. :)
700 2012-06-14 19:26:40 <luke-jr> jgarzik: so we include a pubkey hash in the coinbase
701 2012-06-14 19:26:40 <ThomasV> when we drop to 25btc/block, todays fees will represent 1% of their revenue
702 2012-06-14 19:27:19 <ThomasV> 1dice is a great thing IMO
703 2012-06-14 19:27:28 <ThomasV> it's a stress test for btc
704 2012-06-14 19:27:45 <jgarzik> I don't think there needs to be an alert-like system.  We can calculate by looking at last N blocks, plus some OOB metadata
705 2012-06-14 19:28:05 <jgarzik> calculate sufficient to make good recommendations about fees
706 2012-06-14 19:28:48 <gmaxwell> ThomasV: er. it could just as easily be done on testnet or a closed system. We're not actually learning anything from it.
707 2012-06-14 19:29:05 <BlueMatt> ThomasV: I think you're falling into the logical fallacy gmaxwell pointed out is rampant when criticizing wikipedia: because you see a mistake and correct it, you cant complain that wikipedia is broken: you are part of the system
708 2012-06-14 19:29:19 <luke-jr> jgarzik: no, you can't, because past fees don't tell you anything about what fees *you* need to pay
709 2012-06-14 19:29:38 <gmaxwell> the _only_ thing about that site is the number of complete idiots who are using bots to play it at high speed. Automating a net negative expectancy game is something I never expected!
710 2012-06-14 19:29:39 <BlueMatt> part of the system isnt to accept problems that are caused by 1dice, its to fix them
711 2012-06-14 19:29:45 <jgarzik> luke-jr: sure they do, especially combined with metadata from various sites
712 2012-06-14 19:30:30 <luke-jr> jgarzik: so when 75% of transactions have bulk fees prepaid privately, and the other 25% start getting stuck because they don't pay a fee?
713 2012-06-14 19:30:50 <ThomasV> gmaxwell: they have fun from it. that's why negative expectancy games exist
714 2012-06-14 19:31:02 <gmaxwell> ThomasV: but !! automated!
715 2012-06-14 19:31:23 <jgarzik> gmaxwell: hehe
716 2012-06-14 19:31:44 <ThomasV> yeah. I think that we will have to live in a world where the block limit  is reached, and transaction compete through fees
717 2012-06-14 19:31:49 <gmaxwell> I thought I understood slot machines with the lever pulling and the blinking lights...  Oh well.
718 2012-06-14 19:31:57 <jgarzik> luke-jr: you want informed self-tuning system.  history and OOB metadata both play a role, but are not the complete picture individually.
719 2012-06-14 19:32:26 <jgarzik> gmaxwell: it's perfect for Americans... literally instant gratification
720 2012-06-14 19:32:39 <gmaxwell> ThomasV: So here is the point I've made about this before:  That world is viable when it's also a world where bitcoin is firmly established and widely used. The economic utility of widely used bitcoin will justify dealing with the fees.
721 2012-06-14 19:33:01 <gmaxwell> ThomasV: If we reach that state _before_ the value of bitcoin is well established, then it will discourage people from adopting it.
722 2012-06-14 19:33:25 <gmaxwell> ThomasV: so we should do what we can as a community to forstall that point in time in order to increase the system's chances of success.
723 2012-06-14 19:34:03 <ThomasV> gmaxwell: the negaative expectancy of 1dice is just another fee in the game. ant that fee does not discourage people from playing. so I don't see why the miner fee would discourage more rational players
724 2012-06-14 19:34:24 <luke-jr> looks like I can release bitcoind 0.5.6 for OSX
725 2012-06-14 19:34:28 <gmaxwell> ThomasV: Prior to dice I wasn't so worried about reaching this situation too early because there was some proportionality... more txns meant more users meant more value in the system.
726 2012-06-14 19:34:32 <luke-jr> gmaxwell: did you ever get gitian working?
727 2012-06-14 19:34:47 <gmaxwell> ThomasV: because that traffic makes bitcoin suck for users who don't want to gamble too.
728 2012-06-14 19:35:08 <gmaxwell> ThomasV: it makes it take longer to install a full node and it makes transactions confirm slowly for everyone.
729 2012-06-14 19:35:41 <gmaxwell> And the dice users don't even care much about the slow confirmations since their system works with zero confirms (made possible only due to the bloaty behavior)
730 2012-06-14 19:35:54 <gmaxwell> luke-jr: no. :( though I didn't make a third pass at it yet.
731 2012-06-14 19:36:11 <gmaxwell> (third pass = installing newer ubuntu on the host vm)
732 2012-06-14 19:36:11 <ThomasV> gmaxwell: why don't you stop worrying and learn to love the Dice!
733 2012-06-14 19:36:26 <gmaxwell> ThomasV: because I'd like bitcoin to survive.
734 2012-06-14 19:36:26 <luke-jr> gmaxwell: what if we tell Dice they have two choices 1) we throw together some hacks to deprioritize and/or filter their stuff; or 2) they pay a developer to implement more Dice-friendly ways of scaling with their load
735 2012-06-14 19:36:36 <ThomasV> it will :)
736 2012-06-14 19:36:46 <gmaxwell> ThomasV: only because people will worry.
737 2012-06-14 19:36:51 <gmaxwell> And I'm part of that system.
738 2012-06-14 19:37:22 <BlueMatt> ThomasV: same logical fallacy
739 2012-06-14 19:37:49 <gmaxwell> luke-jr: I do not like that.
740 2012-06-14 19:38:28 <gmaxwell> It goes back to what I said before about not compromising the things that make bitcoin valuable. Giving users, even abusive ones, ultimatums is good fud material.
741 2012-06-14 19:38:52 <gmaxwell> About the only thing I think would justify that is an overpowering ASIC attacker.
742 2012-06-14 19:40:59 <Diablo-D3> DMC DMC DMC DMC
743 2012-06-14 19:41:08 <BlueMatt> /kick Diablo-D3
744 2012-06-14 19:41:22 <Diablo-D3> :<
745 2012-06-14 19:41:28 <BlueMatt> how's that going, btw?
746 2012-06-14 19:41:32 <Diablo-D3> very well
747 2012-06-14 19:43:45 <BlueMatt> TD: we've been discussing future fee structures, if you're interested
748 2012-06-14 19:44:27 <TD> ok
749 2012-06-14 19:44:36 <TD> i'm heading to bed soon
750 2012-06-14 19:45:12 <luke-jr> gmaxwell: well, depends how it's worded
751 2012-06-14 19:47:13 <BlueMatt> luke-jr: see the thread: https://bitcointalk.org/index.php?topic=87444.0
752 2012-06-14 19:47:36 <BlueMatt> its a similar concept
753 2012-06-14 19:49:01 <luke-jr> SgtSpike = Dice?
754 2012-06-14 19:49:56 <BlueMatt> no, fireduck
755 2012-06-14 19:51:03 <Nolybab> yeah, then just wait till someone puts dice in facebook, linking wallets to facebook accounts then dice goes viral...maybe just in time for the fall halving.
756 2012-06-14 19:51:25 <ThomasV> lol
757 2012-06-14 19:51:43 <ThomasV> but that would go against fb's tos
758 2012-06-14 19:51:50 <Nolybab> not necessarily
759 2012-06-14 19:51:57 <BlueMatt> hence why we look at rate-limiting forwarding txes from/to the same address now
760 2012-06-14 19:52:08 <Nolybab> technically, even by law, bitcoin is not a 'currency', at lest it's still being debated
761 2012-06-14 19:52:15 <Nolybab> it's like the zynga relationship with facebook
762 2012-06-14 19:52:19 <Nolybab> or paypal with ebay
763 2012-06-14 19:52:28 <Nolybab> looks parasitic, but really symbiotic
764 2012-06-14 19:52:37 <Nolybab> the key is to understand the symbiosis
765 2012-06-14 19:52:44 <Nolybab> cause-->effect
766 2012-06-14 19:54:35 <ThomasV> 1dice transactions are not spam. they are paying fees.
767 2012-06-14 19:54:48 <BlueMatt> yes. they. are.
768 2012-06-14 19:55:08 <BlueMatt> they pay fees to miners, but they are spam to everyone
769 2012-06-14 19:55:20 <ThomasV> to everyone?
770 2012-06-14 19:55:31 <BlueMatt> everyone who runs a client that stores the chain
771 2012-06-14 19:55:54 <luke-jr> BlueMatt: alternate solution to subsidy crash?
772 2012-06-14 19:56:00 <ThomasV> oh but you don't need to store the chain to play dice :)
773 2012-06-14 19:56:15 <BlueMatt> ThomasV: I dont care about dice users
774 2012-06-14 19:56:29 <luke-jr> ThomasV: you mean to be a victim of dice
775 2012-06-14 19:56:54 <Nolybab> not spam...noise...because they also increase the computation requirements to statistically analyze the network, especially when you introduce many, many 'quasi-centralized' server-side hubs that transmit into the network...maybe dice actually does a 'service' to the network from that perspective
776 2012-06-14 19:57:54 <BlueMatt> luke-jr: the dice fees wont help anyone when the subsidy decreases.  And I never said we shouldnt have transactions which pay fees, but we should do that in a way that is a result of real growth in bitcoin, not the result of one site
777 2012-06-14 19:58:01 <ThomasV> if you create a currency system with almost free transactions, noise has to be expected
778 2012-06-14 19:58:02 <Nolybab> actually scratch that part bout the centralization...can just filter that out
779 2012-06-14 19:58:09 <BlueMatt> because one site doesnt help anyone and just makes people who want to pay 0fee mad
780 2012-06-14 19:58:09 <Nolybab> well, we want noise
781 2012-06-14 19:58:22 <BlueMatt> Nolybab: I call that spam
782 2012-06-14 19:58:32 <Nolybab> who am i to say 'we'...just a newbie here
783 2012-06-14 19:59:08 <Nolybab> here's a question
784 2012-06-14 19:59:19 <luke-jr> BlueMatt: would Amazon.com not be real growth?
785 2012-06-14 19:59:40 <Nolybab> nvm
786 2012-06-14 19:59:44 <Nolybab> i'll save it...more research
787 2012-06-14 19:59:47 <ThomasV> BlueMatt: you call it spam. fine. that's your point of view. now bitcoin is an open system, it does not belong to you. other people do not call it spam.
788 2012-06-14 19:59:52 <BlueMatt> luke-jr: amazon would encourage people to pay one tx/order, not one tx per item
789 2012-06-14 20:00:05 <BlueMatt> ThomasV: I never said it was spam
790 2012-06-14 20:00:08 <BlueMatt> I said I call that spam
791 2012-06-14 20:00:20 <ThomasV> <BlueMatt> yes. they. are.
792 2012-06-14 20:00:55 <BlueMatt> that was in response to you claiming they arent spam /because/ thy pay fees
793 2012-06-14 20:00:55 <weex> satoshidice isn't going away. i think this is the test and imagine satoshi at 100x this tx rate
794 2012-06-14 20:01:00 <BlueMatt> which is unrelated to the issue at hand
795 2012-06-14 20:01:17 <BlueMatt> weex: no one wants them to go away
796 2012-06-14 20:01:20 <ThomasV> what is the issue at hand?
797 2012-06-14 20:01:38 <BlueMatt> weex: this is atest, and we are failing, so we should change incentive structures so that this kind of failure isnt possible in the future
798 2012-06-14 20:01:58 <BlueMatt> ThomasV: the drastic increase in load on full nodes for no reason
799 2012-06-14 20:02:07 <BlueMatt> s/no reason/no reason other than the laziness of individuals/
800 2012-06-14 20:02:35 <weex> as a user, i might want to be warned that if i pay less than x it might delay my transaction being confirmed... is how to do that the issue at hand?
801 2012-06-14 20:03:17 <BlueMatt> weex: that is one thing that I think eveeryone agrees should be done