1 2013-07-17 00:00:00 <PRab> E.G. Eve owes Alice 1BTC, but sends it as 1000 outputs of .001BTC. Then when Alice wants to spend the money a big fee is required.
2 2013-07-17 00:00:23 <PRab> I know Eve would have to add a large fee, but this doesn't help Alice at all.
3 2013-07-17 00:03:53 <Luke-Jr> PRab: if I were the merchant, I would refuse to acknowledge it as payment
4 2013-07-17 00:04:24 <PRab> Luke-Jr: Sounds like a lawsuit waiting to happen.
5 2013-07-17 00:04:31 <gmaxwell> PRab: yes/no. Yes someone can send you a lot of dust that costs more for you to redeem, but with the newer anti-dust rules its hard for them to send more to redeem than its worth.
6 2013-07-17 00:04:50 <gmaxwell> PRab: not at all??? but it's a good reason to simply state up front something about that case.
7 2013-07-17 00:05:13 <Luke-Jr> PRab: I would be glad to be an expert witness to testify that Bitcoin addresses are intended to be single-use, and that multiple sends to them should not be something someone should expect to be honoured
8 2013-07-17 00:05:25 <PRab> To me its the equivalent to somebody paying a large bill in all pennies.
9 2013-07-17 00:05:35 <gmaxwell> PRab: which is frequently rejected.
10 2013-07-17 00:06:41 <PRab> gmaxwell: True.
11 2013-07-17 00:07:07 <PRab> But, you didn't really reject it.
12 2013-07-17 00:07:17 <PRab> There is no way to return the money without paying the fee.
13 2013-07-17 00:08:04 <gmaxwell> You didn't accept it either. You can't just lob a sack of pennies over my counter and then insist that you paid me.
14 2013-07-17 00:08:21 <gmaxwell> (in fact, I'm pretty sure people have been convicted of vandalism for doing exactly that in the US)
15 2013-07-17 00:08:44 <PRab> I guess you could return it by giving them the private key to that address.
16 2013-07-17 00:08:58 <gmaxwell> Good point too!.
17 2013-07-17 00:09:10 <gmaxwell> Besides, de minimis non curat lex; especially if you're being an obvious jerk.
18 2013-07-17 00:10:42 <gmaxwell> returning the private keys is a cute solution though. But I do think it would be good to have a up front policy too. I know that some wallet services in the past have ignored tiny inputs, but I'm not sure if any documented it in their published policies.
19 2013-07-17 00:11:04 <PRab> I just thought about it because I was looking at the rulebook for my old fraternity and we had an explicit "no pennies" rule and wondered how that translates to bitcoin.
20 2013-07-17 00:11:07 <gmaxwell> pratically everything using ltc does because the reference litecoin software ignores tiny inputs by default.
21 2013-07-17 00:11:44 <PRab> My initial reaction was to adjust the transaction fee rules to weigh outputs significantly more than inputs.
22 2013-07-17 00:11:57 <gmaxwell> PRab: from time to time it's actually been a problem for some parties, not even due to an attacker, but due to dull users and clickfraud faucets that pay really tiny amounts.
23 2013-07-17 00:12:44 <PRab> E.G. It cost 10X more to include a byte of output than a byte of input. (Signatures might be 3X)
24 2013-07-17 00:13:21 <gmaxwell> PRab: any transaction with an output under 0.01 BTC in value must be a non-free transaction to begin with. Once a transaction is non-free I don't know how much sense it makes having a rule that miners would be _irrational_ (as in, not profit maximizing) to follow.
25 2013-07-17 00:13:44 <PRab> I've seen people complaining on the forum that its hard to spend the bitcoin after playing satoshi dice.
26 2013-07-17 00:14:30 <gmaxwell> The badness of this has been limited by the minimum output size relay rules, since that make people produce outputs that should still yield more btc value than they cost in fees.
27 2013-07-17 00:14:54 <gmaxwell> But thats a recent change.
28 2013-07-17 00:15:04 <PRab> gmaxwell: 8.2, right?
29 2013-07-17 00:15:17 <gmaxwell> 0.8.2, yes.
30 2013-07-17 00:15:24 <PRab> oops,
31 2013-07-17 00:16:28 <gmaxwell> For free txn it would indeed make sense to have the priority calculation favor transactions that have less outputs absolutely and also ones that have more inputs relative to outputs. But it's not clear how much longer free txn will be very relevant.
32 2013-07-17 00:16:33 <PRab> I would love it if there was a miner rational, UTXO shrinking rule fee rule.
33 2013-07-17 00:17:39 <gmaxwell> PRab: That would require a new block validity rule, e.g. setting a maximum UTXO size increase per block.
34 2013-07-17 00:18:13 <gmaxwell> once that existed it would be rational for miners to favor txn that had a lower (or negative) utxo impact.
35 2013-07-17 00:18:45 <PRab> gmaxwell: Yes, but I'm guessing that would require at least a soft fork.
36 2013-07-17 00:18:49 <gmaxwell> such a rule could be a soft forking one. But it might be politically complicated to deploy.
37 2013-07-17 00:18:55 <gmaxwell> PRab: Yup.
38 2013-07-17 00:19:33 <PRab> I would vote/mine for it, but I only have one GPU at my disposal
39 2013-07-17 00:19:59 <gmaxwell> The space of all such rules isn't very unique either, so even if people agree in general its easy to disagree about the details.
40 2013-07-17 00:20:14 <petertodd> gmaxwell: jdillon's voting proposal...
41 2013-07-17 00:21:01 <PRab> gmaxwell: Yeah, I have seen a lot of bikeshedding
42 2013-07-17 00:22:54 <gmaxwell> And not just empty bikeshedding. E.g. Say you think at change of +500k should be the maximum. OKAY. But if you just sum the changes and agree with the maximum you can get some perverse motivations.
43 2013-07-17 00:23:10 <petertodd> PRab: this is worse because it's about what Bitcoin can be to different people
44 2013-07-17 00:23:28 <gmaxwell> For example: say there are a lot of negative utxo change transactions. So many, in fact, that if you included all of them your UTXO change would be negative overall.
45 2013-07-17 00:24:28 <gmaxwell> You would then find it in your interest to add your own junk outputs.. just to create UTXO bloat and get the change up to the 500k limit.
46 2013-07-17 00:24:53 <gmaxwell> Then on the next block you try to mine, you would (without announcing them) pad up the space with transactions cleaning it back up again.
47 2013-07-17 00:25:18 <PRab> Grumble... I see your point.
48 2013-07-17 00:25:24 <PRab> Why can't anything be easy.
49 2013-07-17 00:26:01 <gmaxwell> hah. Well, I can answer that one, just don't allow them to be negative. That risk only exists when things can cancel.
50 2013-07-17 00:27:09 <gmaxwell> But, you wouldn't want to treat a -1000 utxo and a 0 change utxo the same. So really it should be utxo_delta = max(0,UTXO_delta + offset) .. and now we get to debate the offset.
51 2013-07-17 00:28:23 <PRab> That looks just like a different way of represent my TxIn vs TxOut multiplier.
52 2013-07-17 00:28:48 <PRab> Leads to the same question (whats the multiplier vs whats the offset)
53 2013-07-17 00:28:51 <petertodd> PRab: no, it's a way of making your multiplier happen
54 2013-07-17 00:29:18 <gmaxwell> PRab: right, you could also do this with weighing when calculating the 'size' though thats a hardforking change. The delta with limit could be a soft forking change but would be analogous to your multiplier.
55 2013-07-17 00:29:52 <gmaxwell> PRab: you might also like my transaction cost prepayment idea
56 2013-07-17 00:30:07 <gmaxwell> PRab: search for 'prepayment' https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
57 2013-07-17 00:30:10 <Luke-Jr> ACTION finally gets around to fixing bitcoind's GBT longpolling pullreq
58 2013-07-17 00:30:11 <PRab> gmaxwell: Where/what was that?
59 2013-07-17 00:30:34 <PRab> gmaxwell: ah, your too quick.
60 2013-07-17 00:32:42 <gmaxwell> PRab: the idea is that the 'size' of a transaction for the purpose of imposing the block limit is increased by the amount that its outputs will take to redeem. And when the outputs are redeemed, the size is decreased by the 'prepaid' amount.
61 2013-07-17 00:33:53 <gmaxwell> You can look at it like every output must reserve space in the chain to make room for their consumer, and their consumer uses the reserved space. Though it's tricky to avoid the weird incentives, and I am not confident that I really did so there.
62 2013-07-17 00:34:38 <PRab> I don't quite follow the prepayment proposal (details, I get the concept), but it would probably make some more sense if I spent some time in the code.
63 2013-07-17 00:35:52 <PRab> Oh well, thanks for taking the time to answer my "what ifs".
64 2013-07-17 00:36:27 <PRab> I'm hoping to dive into the code at some point, but who knows when that will be.
65 2013-07-17 02:22:37 <Luke-Jr> sipa: is there an update for your hal branch somewhere?
66 2013-07-17 02:32:01 <gmaxwell> Luke-Jr: why would you want that?
67 2013-07-17 02:32:13 <gmaxwell> the sipa-ecc code is tons faster.
68 2013-07-17 02:32:22 <Luke-Jr> gmaxwell: that's what I mean by update ;)
69 2013-07-17 02:32:32 <Luke-Jr> gmaxwell: is it his secp256k1 branch? does it work reasonably?
70 2013-07-17 02:33:19 <warren> Luke-Jr: I've been using it in production for weeks
71 2013-07-17 03:08:34 <Krellan> makefile.unix question: where's the best place to put -fPIC in there? Getting compilation errors without it.
72 2013-07-17 03:11:45 <jedunnigan> ;;last
73 2013-07-17 03:11:46 <gribble> [01:04:06] <Krellan> makefile.unix question: where's the best place to put -fPIC in there? Getting compilation errors without it.
74 2013-07-17 03:13:33 <Luke-Jr> Krellan: nowhere. you should not be building bitcoind with -fPIC
75 2013-07-17 03:13:58 <Luke-Jr> if you're getting compilation errors, it's related to something else
76 2013-07-17 03:16:10 <Krellan> ah OK thanks - is it bad to do that?
77 2013-07-17 03:16:21 <Krellan> I tried to enable PIE=1
78 2013-07-17 03:18:01 <Krellan> It successfully built with -fPIC, and it didn't build without it.
79 2013-07-17 03:18:14 <Luke-Jr> Krellan: only libraries should use -fPIC
80 2013-07-17 03:18:22 <Krellan> The error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: obj/alert.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
81 2013-07-17 03:18:39 <Luke-Jr> Krellan: ok, so why does ld think you're trying to make a shared object?
82 2013-07-17 03:19:59 <Krellan> Not sure about that. It only did it when trying to do the final bitcoind link.
83 2013-07-17 03:20:47 <gmaxwell> Luke-Jr: hum, we're not compiling bitcoin with -fPIC ?!
84 2013-07-17 03:20:57 <gmaxwell> relro doesn't work without it.
85 2013-07-17 03:21:33 <Luke-Jr> it doesn't? last I checked, only libraries were supposed to be -fPIC
86 2013-07-17 03:22:52 <Krellan> as a general rule of thumb I have *always* used -fPIC when doing anything with libraries on x86_64
87 2013-07-17 03:23:03 <Luke-Jr> Krellan: but bitcoind is not a library!
88 2013-07-17 03:23:31 <Krellan> True. I wonder if it could also be caused by a library that it's trying to pull in during compilation, though. http://www.gentoo.org/proj/en/base/amd64/howtos/?part=1&chap=3
89 2013-07-17 03:24:05 <Luke-Jr> Krellan: can you pastebin the full build log?
90 2013-07-17 03:24:59 <Krellan> OK will do
91 2013-07-17 03:25:24 <gmaxwell> Luke-Jr: derp mode here, -PIE accomplishes on executibles what -fPIC does on DSOs.
92 2013-07-17 03:26:31 <Krellan> I also had to modify the makefile.unix slightly, to add directory: -I/usr/include/db4.8
93 2013-07-17 03:26:35 <gmaxwell> oh, hm. it doesn't.
94 2013-07-17 03:26:47 <gmaxwell> Krellan: you don't have to modify the makefile for that, it takes that as an argument.
95 2013-07-17 03:26:53 <Luke-Jr> Krellan: you're supposed to pass BDB_INCLUDE_PATH=/usr/include/db4.8 to make for that
96 2013-07-17 03:27:07 <Luke-Jr> Krellan: you might look at the ebuild..
97 2013-07-17 03:27:22 <gmaxwell> e.g. I compile Bitcoin as DB_LIB_PATH='/usr/lib64/libdb4/' BDB_INCLUDE_PATH='/usr/include/libdb4' BOOST_LIB_SUFFIX='-mt' make -j4 -f makefile.unix bitcoind USE_UPNP=
98 2013-07-17 03:28:51 <Luke-Jr> ACTION puts all the params after 'make' so he can find it in history easier <.<
99 2013-07-17 03:28:52 <Krellan> OK http://pastebin.com/9JLcWBzH
100 2013-07-17 03:29:03 <Luke-Jr> actually, I just threw them all in a GNUmakefile XD
101 2013-07-17 03:29:27 <Luke-Jr> Krellan: that's missing the end
102 2013-07-17 03:29:53 <Krellan> sigh, stupid terminal limits the maximum length of a cut
103 2013-07-17 03:31:08 <gmaxwell> Luke-Jr: ugh. So PIE=1 is broken, and we're not PIE by default but we should be.
104 2013-07-17 03:31:28 <Krellan> actually that's all of it. Line 109 is the final command that links, and outputs bitcoind.
105 2013-07-17 03:32:35 <Luke-Jr> Krellan: I don't see any errors then
106 2013-07-17 03:33:18 <Krellan> That's just it: adding -fPIC made it compile without errors. It shouldn't have been necessary to add, though, and it's bad form to use it with executables (should only be shared libraries, as you said).
107 2013-07-17 03:33:44 <Krellan> scanelf indicates TYPE ET_DYN and STK/REL/PTL RW- R-- RW- so that passes sanity check
108 2013-07-17 03:34:11 <gmaxwell> Krellan: where did you have to add it? I just successfully did a git build without adding anything
109 2013-07-17 03:34:22 <gmaxwell> $ ./checksec.sh --file ./bitcoind
110 2013-07-17 03:34:23 <gmaxwell> RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
111 2013-07-17 03:34:25 <gmaxwell> Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH ./bitcoind
112 2013-07-17 03:34:41 <gmaxwell> BDB_LIB_PATH='/usr/lib64/libdb4/' BDB_INCLUDE_PATH='/usr/include/libdb4' BOOST_LIB_SUFFIX='-mt' make -j4 -f makefile.unix bitcoind USE_UPNP= PIE=1
113 2013-07-17 03:35:15 <Krellan> Nice
114 2013-07-17 03:35:54 <gmaxwell> will be nice when gitian is gcc 4.8 and can use -fstack-protector-strong
115 2013-07-17 03:36:44 <gmaxwell> (strong is basically all of the protection of all, but basically the same performance as fstack-protector)
116 2013-07-17 03:38:07 <Krellan> I didn't know about checksec.sh script - nice
117 2013-07-17 03:39:14 <Krellan> I cheesily added -fPIC to DEBUGFLAGS because that gets pasted everywhere already, like CFLAGS would be
118 2013-07-17 03:40:11 <gmaxwell> Krellan: RTFM. :P
119 2013-07-17 03:40:58 <gmaxwell> Krellan: ../doc/build-unix.md see the bottom.
120 2013-07-17 03:42:34 <Krellan> will do, guess I missed that part
121 2013-07-17 03:42:42 <Krellan> the built bitcoind is up and running
122 2013-07-17 03:48:00 <Krellan> ah, the Gentoo sample is in the middle, missed that part about BDB_INCLUDE_PATH
123 2013-07-17 03:51:54 <Krellan> thanks for your advice
124 2013-07-17 03:52:23 <Krellan> is it possible to run bitcoin-qt as merely a thin user interface, that would point at another bitcoind running elsewhere?
125 2013-07-17 03:52:40 <gjs278> Krellan use the ebuild
126 2013-07-17 04:03:32 <Luke-Jr> [05:47:55] <Krellan> is it possible to run bitcoin-qt as merely a thin user interface, that would point at another bitcoind running elsewhere? <-- no