1 2013-05-06 00:03:14 <IanCormac> Can someone explain what we hope to accomplish with the new minimum output value limit?
 2 2013-05-06 00:04:56 <IanCormac> I don't understand why this would prevent people who are doing 1 satoshi transactions from just doing 5430 satoshi transactions instead. However, I can see a lot of problems it would cause
 3 2013-05-06 00:06:06 <Belxjander> IanCormac: well it also comes up as an anti-blockchain-spam rule as a side-effect... doesn't stop it... but does raise the price :)
 4 2013-05-06 00:06:30 <IanCormac> Yeah, by an incredibly small margin. We already have transaction fees to prevent blockchain spam
 5 2013-05-06 00:06:41 <IanCormac> and besides, why should the client enforce anti-spam measures?
 6 2013-05-06 00:07:44 <Belxjander> IanCormac: it shouldn't...
 7 2013-05-06 00:07:58 <IanCormac> Right, but that's what this patch does, right?
 8 2013-05-06 00:08:17 <Belxjander> IanCormac: it is just an alternate use of the minimum transfer rule just upping the price of the spam :)
 9 2013-05-06 00:08:18 <IanCormac> the client no longer relays transactions that meet this much broader "dust" classification
10 2013-05-06 00:08:27 <Belxjander> seems to be the only real way to make it happen properly
11 2013-05-06 00:08:31 <IanCormac> The price of spam used to be 0 satoshis
12 2013-05-06 00:08:37 <IanCormac> Make what happen properly?
13 2013-05-06 00:08:42 <IanCormac> This won't change anything for spammers
14 2013-05-06 00:08:49 <IanCormac> they already had to pay a ~5 cent transaction fee
15 2013-05-06 00:08:51 <IanCormac> or larger
16 2013-05-06 00:08:57 <Belxjander> well... it is the only real way to combat "spam".... make the spammer pay for each message
17 2013-05-06 00:09:15 <IanCormac> Don't they do that already with transaction fees?
18 2013-05-06 00:14:04 <IanCormac> Anyone? Is there any reasoning behind the new minimum output value limit besides forcing spammers to pay marginally more significant amounts per spam transaction?
19 2013-05-06 00:15:30 <vrs> IanCormac: block chain size
20 2013-05-06 00:15:58 <owowo> IanCormac:  I would guess the blockchain got really dusty.. like my miner ;o)
21 2013-05-06 00:16:01 <IanCormac> How will this actually decrease blockchain size by any significant amount?
22 2013-05-06 00:16:16 <cjd> IanCormac: tx fees are ignored for very old coins so I could send an enormous shitstorm of tiny payments to you and it would cost you more to spend them than it does to leave them in the chain
23 2013-05-06 00:17:05 <IanCormac> So the solution, then, is to change the algorithms the miners are using, NOT to censor otherwise valid transactions by refusing to relay them
24 2013-05-06 00:17:20 <IanCormac> They are lots of valid reasons to have valueless transactions
25 2013-05-06 00:17:25 <IanCormac> or near-valueless
26 2013-05-06 00:17:31 <cjd> ahh relay wat ahh want
27 2013-05-06 00:18:37 <cjd> yeah, the code will make miners not mine them either
28 2013-05-06 00:18:49 <cjd> unless they are willing to mine non-standard transactions
29 2013-05-06 00:18:50 <IanCormac> Right, so let's just do that
30 2013-05-06 00:19:05 <IanCormac> no reason to make everyone else block the transactions too
31 2013-05-06 00:19:37 <cjd> well.. you can also flood the p2p net with crap transactions as well
32 2013-05-06 00:19:38 <IanCormac> And miners are more equipped to make decisions about what they think should be included than average joe with his bitcoin-qt is
33 2013-05-06 00:20:14 <jgarzik> IanCormac: if normal clients don't block transactions, then you relay 99% spam
34 2013-05-06 00:20:21 <jgarzik> IanCormac: the network is trivially flooded
35 2013-05-06 00:21:15 <IanCormac> Here's a solution that makes a lot more sense regarding tokens, smart property, etc: factor in number of outputs in fee evaluation, if we don't do that already
36 2013-05-06 00:21:25 <IanCormac> No reason to block the transactions outright
37 2013-05-06 00:21:57 <cjd> IanCormac: smart property and colored coin transactions are trivially implemented with transactions which otherwise look perfectly normal
38 2013-05-06 00:22:09 <cjd> there's no reason why you have to make them look like dust spam
39 2013-05-06 00:22:26 <IanCormac> And for what reason should a transaction be forced to look "normal"?
40 2013-05-06 00:22:45 <IanCormac> What about 2-output, 1-satoshi transactions?
41 2013-05-06 00:22:52 <IanCormac> Those have a lot of perfectly valid uses
42 2013-05-06 00:23:05 <cjd> which can be implemented other ways
43 2013-05-06 00:23:12 <IanCormac> But which shouldn't have to be
44 2013-05-06 00:23:15 <gmaxwell> IanCormac: that doesn't actually solve anything. Say your smart property becomes worthless.. Now there is a technically viable txout in the txout set which the nextwork is forced to carry _forever_ but which is worthless so only a griefer would spend it.
45 2013-05-06 00:23:33 <cjd> this is like saying "in order to send my perfectly valid email, I *have* to make it look just like viagra spam" I don't buy it.
46 2013-05-06 00:23:34 <jgarzik> IanCormac: Those transactions may also be trivially used to store data that we must carry for eternity
47 2013-05-06 00:24:12 <luna> if this is another mention of cp
48 2013-05-06 00:24:18 <luna> gonna go crazy
49 2013-05-06 00:24:25 <gmaxwell> IanCormac: Bitcoin is a currency, it's is not a messaging network or a data storage service or whatever else. To the extent that some non-currency users can work along side it without adding additional costs thats fine, but you don't get to bloat the unprunable utxo set.
50 2013-05-06 00:26:10 <IanCormac> gmaxwell: So how is this a preferable option to charging people based on the number of outputs? And quite frankly, I don't think it's up to you to decide whether or not Bitcoin is a data storage service or not
51 2013-05-06 00:26:19 <IanCormac> Didn't the very first block have a message in it?
52 2013-05-06 00:26:20 <cjd> jgarzik: Suppose I wanted to make some huge changes to libccoin by making every function require a memory allocator (a struct with a malloc function) would you be totally against this?
53 2013-05-06 00:26:44 <gmaxwell> IanCormac: Then people can choose to not use my software.  It's also not up to _you_ to decide that you can force third party people to store data for you without a fight.
54 2013-05-06 00:27:39 <jgarzik> cjd: That would be an odd way to implement a common pattern.
55 2013-05-06 00:27:48 <gmaxwell> IanCormac: because adding up insane tx fees doesn't help because it doesn't address the underlying issue of the perpetually stored txouts being uneconomical to redeem, instead increasing fees screws over regular currency users doing regular currency things.
56 2013-05-06 00:27:55 <jgarzik> cjd: Usually you have a library-wide memory allocator setting.  Set that once at lib init time.
57 2013-05-06 00:28:10 <jgarzik> cjd: Few programs need more than one allocator at a time.
58 2013-05-06 00:28:25 <IanCormac> gmaxwell: What the hell kind of regular user has a 1000-output transaction?
59 2013-05-06 00:28:35 <gmaxwell> Or if you're in an enviroment where allocator behavior matters you make the program constant memory (other than stack) and allocate it up front.
60 2013-05-06 00:28:35 <IanCormac> the vast majority of transactions are 2-output, are they not?
61 2013-05-06 00:28:58 <IanCormac> That seems to be a much better indicator of spam than transaction value
62 2013-05-06 00:29:33 <gmaxwell> IanCormac: 1000? perhaps not??? but more than two? sure. people use send many all the time.  The low value txouts are _fundimental_ to the data storage transactions, because they directly add to the cost of the storage because they can never be redeemed.
63 2013-05-06 00:29:42 <cjd> jgarzik: All of my code uses allocators so that I can group things together by the lifetime of the memory, so for example when I send a ping message, I fork an allocator and use it to store all various state associated with the ping, when it returns or times out, I call allocator->free(allocator) and all of that state is cleaned up.
64 2013-05-06 00:30:17 <gmaxwell> They are anti-fundimental to actual currency usage, since sending someone an amount thats worth less than it costs to send is not actually a payment.
65 2013-05-06 00:30:20 <cjd> In cjdns there is are no "destructors" or unregister type functions because I hook the allocator->free() function.
66 2013-05-06 00:31:14 <gmaxwell> IanCormac: that makes a very clear seperation between abusive and non-abusive usage which you can't get by hitting every user with an additional fee per txout. If you do that, the abusive use would just use two txouts per transaction.
67 2013-05-06 00:31:56 <IanCormac> If abusive use could only make two txouts per transaction, would they not start paying a lot more in fees to get the same abusive txout volume?
68 2013-05-06 00:33:05 <cjd> https://github.com/cjdelisle/cjdns/blob/master/memory/Allocator.h <-- this is basically the single element responsable for cjdns not becoming a ball of mud
69 2013-05-06 00:35:17 <cjd> my toy bitcoin parser: 210943 blocks in 1 minute 36 seconds.
70 2013-05-06 00:35:25 <cjd> because my harddrive is crap
71 2013-05-06 00:36:31 <cjd> I'm using an allocator which allocates data for the block structure out of an 8MB buffer and resets the pointer after parsing each block
72 2013-05-06 00:36:57 <IanCormac> ?? Isn't it true that doing txout-based fees would actually charge based on space used *after* the transaction has been sent, punishing spammers but not punishing people doing generic small transactions?
73 2013-05-06 00:37:06 <gmaxwell> IanCormac: only a third more or so, as you don't save /that/ much from the common parts??? and again you'd then be discouraging sendmany which is widely used by regular users, supported in all (?) clients, and is the _preferable_ way for someone to do multiple payments at once.
74 2013-05-06 00:37:50 <gmaxwell> IanCormac: Isn't it true that you're a member of the communist party??
75 2013-05-06 00:37:56 <IanCormac> And why should sendmany not get charged proportionately more than a send to a single user?
76 2013-05-06 00:38:06 <IanCormac> And that is not true, not sure how that's relevant
77 2013-05-06 00:38:24 <gmaxwell> IanCormac: because they're already charged proportional to their _size_ any other basis for charging is not economically rational for miners.
78 2013-05-06 00:39:18 <gmaxwell> IanCormac: I'm interested in knowing what usage you're concerned with this harming.
79 2013-05-06 00:39:43 <IanCormac> I'm concerned with crippling Bitcoin's capability to support transactions of extremely small denominations
80 2013-05-06 00:39:55 <gmaxwell> So far, no one has suggested one on the pull accept the colored coins one??? which I think was answered to people's satisfaction. (That it just means you need to make the color coins large enough to pay for cleaning themselves up)
81 2013-05-06 00:40:34 <gmaxwell> IanCormac: What capability? You already are forced to include a fee of 50,000x larger when paying a "payment" of 1e-8 and then that "payment" costs more to redeem than it yields in Bitcoin value.
82 2013-05-06 00:40:48 <IanCormac> And you keep talking about cleaning themselves up; it's not like it's suddenly impossible to send to an unknown private key
83 2013-05-06 00:41:01 <IanCormac> gmaxwell: And? Just because *you* don't want to use that capability doesn't mean others don't
84 2013-05-06 00:41:22 <gmaxwell> IanCormac: Bitcoin is a currency, if you want to abuse it for non-currency usages then I invite you to go get your own software.
85 2013-05-06 00:41:43 <IanCormac> Didn't satoshi himself use it for a non-currency usage in the very first block?
86 2013-05-06 00:41:59 <IanCormac> Surely you don't disagree with his ideas for what Bitcoin should be able to do