1 2014-10-06 00:01:55 <brisque> sipa: haven't managed yet. working out how I'm going to make a "bad" node to test these sorts of things more easily.
  2 2014-10-06 00:03:15 <brisque> currently it's just a passthrough sybil "node" that pretends to be a real bitcoind, but just proxies requests.
  3 2014-10-06 00:04:26 <sipa> brisque: hint: wait for a getheaders and never respond
  4 2014-10-06 00:04:29 <brisque> hoping to add tampering features like mutating transactions, making invalid blocks, droping portions of requests, anything else I can think of.
  5 2014-10-06 00:05:14 <brisque> sipa: I'm guessing that will get me dropped?
  6 2014-10-06 00:05:22 <sipa> brisque: unfortunately, no
  7 2014-10-06 00:05:28 <brisque> ah.
  8 2014-10-06 00:08:55 <brisque> should be fun though, might even be able to make a "full" node that only has incoming connections and no outgoing ones
  9 2014-10-06 00:12:04 <gmaxwell> Annoyingly this approach totally breaks one of my defense ideas against 'stupid nodes'
 10 2014-10-06 00:12:37 <gmaxwell> which was to just agressively profile behavior and consider nodes that don't get it right more suspect... but if you're passing through you can be indistinguishable except for whatever evil you do.
 11 2014-10-06 00:12:48 <gmaxwell> oh well, better to realize this before writing a bunch of behavior profiling code.
 12 2014-10-06 00:13:30 <gmaxwell> (note the idea there wasn't to really gain security against malicious behavior, but rather people trying to do something 'smart' and getting it wrong... but the fact that it would fail completely against a proxy makes it much less attractive)
 13 2014-10-06 00:17:27 <brisque> I had an idea of extending it to seeing who was lying on the network by feeding them random crap and seeing if they disconnect me properly.
 14 2014-10-06 00:18:41 <brisque> I'm not sure if connecting to other nodes and feeding them junk is really legal or not, so I thought better of it. seems to go past implied access.
 15 2014-10-06 00:18:47 <gmaxwell> yea, one test I'd considered was "is this node verifing?" that worked by sending an invalid signature and seeing if it got banned. :)
 16 2014-10-06 00:18:49 <xiando> gmaxwell: What is your opinion on blacklisted some outputs so people can't send to them?
 17 2014-10-06 00:19:23 <gmaxwell> xiando: that doesn't make a lot of sense, and probably has no business in this channel.
 18 2014-10-06 00:19:54 <xiando> gmaxwell: I see. If you "emerge bitcoind" to install it on Gentoo right now then you get a client which does that.
 19 2014-10-06 00:20:23 <xiando> I am apparently a troll for saying that I believe all outputs should be equal.
 20 2014-10-06 00:20:30 <gmaxwell> xiando: Ah. I thought you meant as a network rule. Nodes are free to run whatever policy they want.
 21 2014-10-06 00:21:02 <brisque> xiando: huh, are you saying gentoo is packaging a version with their own rules in it?
 22 2014-10-06 00:21:06 <gmaxwell> Probably not terribly useful, but it's also important that users of the network use it in a way which is unblockable; otherwise there is policy risk created for the whole system.
 23 2014-10-06 00:22:27 <sipa> it seems luke's patchset is enabled by default, which is probably not what people expect
 24 2014-10-06 00:22:35 <gmaxwell> looks like its a use flag at least... but you probably want to consider a different source for your bitcoind. Distro versions are almost universally not very good.
 25 2014-10-06 00:22:49 <brisque> sipa: hah, oh I'm not against that at all :)
 26 2014-10-06 00:23:18 <xiando> luke-jr is the gentoo package maintainer, thus his patches are enabled by default where as I think they should be a use-flag _disabled_ by default. His opinion is that I am trolling.
 27 2014-10-06 00:23:43 <sipa> i have no problem with people enabling such a patch, or making it available, but people shouldn't end up running with such behaviour without being aware of it
 28 2014-10-06 00:23:56 <xiando> seeing
 29 2014-10-06 00:23:57 <xiando> 2014-10-05 11:38:09 ERROR: AcceptToMemoryPool : ignoring transaction                289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice)
 30 2014-10-06 00:23:58 <Luke-Jr> gmaxwell: Gentoo is the exception there
 31 2014-10-06 00:24:01 <xiando> in the log is how I learned
 32 2014-10-06 00:24:17 <sipa> Luke-Jr: i think making it enabled by default is going too far
 33 2014-10-06 00:24:47 <gmaxwell> I've encouraged luke in the past for his own patches to instead optimize more neutrally, e.g. deprioritizing reuse... doing other than that seems unmaintainable generally.
 34 2014-10-06 00:24:48 <Luke-Jr> busy atm, can discuss later if needed (maybe without a troll present)
 35 2014-10-06 00:25:22 <brisque> my nodes are a hell of a lot more picky than Luke's, and I agree that people should at least know their client isn't vanilla even if it is default.
 36 2014-10-06 00:25:50 <xiando> Claiming everyone who disagrees with you is a troll is generally not helpfull, Luke-Jr. Try debating like an adult. It appers everyone else here is able to do that.
 37 2014-10-06 00:25:59 <gmaxwell> Luke-Jr: it's sort of surprising if there is complex default policy that people wouldn't expect.
 38 2014-10-06 00:28:49 <gmaxwell> Luke-Jr: So I'd perhaps cite that as an example of distros doing something bad. Even if all agreed that it was good policy (I don't, primarly because it's not matching the behavior), it's somewhat surprising.
 39 2014-10-06 00:29:16 <gmaxwell> But at the same time, no one has a monopoly on distributing a bitcoin implementation... and every implementation has different policy already.
 40 2014-10-06 00:36:32 <xiando> That is alright but multibit doesn't say it's bitcoin-qt and install when you ask to install that.
 41 2014-10-06 00:37:23 <xiando> Regardless, now I know how the rest of you feel about it. Thank you.
 42 2014-10-06 00:45:31 <Luke-Jr> xiando: you crossed the line into trolldom when you began spreading FUD ("breaks bitcoin") and making it into a political issue (bringing religion etc into it)
 43 2014-10-06 00:46:38 <Luke-Jr> gmaxwell: the latter (and code monoculture being a serious problem today for bitcoin) is similar to my thinking
 44 2014-10-06 00:46:48 <gmaxwell> (please don't continue that debate here)
 45 2014-10-06 00:47:07 <gmaxwell> Luke-Jr: I'd like us to get to the point where the policy is more pluggable... so that its runtime selectable.
 46 2014-10-06 00:47:25 <Luke-Jr> gmaxwell: most of the patchset is that way, in fact.
 47 2014-10-06 00:50:45 <Luke-Jr> it just doesn't make sense to have clearly inferior defaults
 48 2014-10-06 00:51:09 <Luke-Jr> even if the only present method of improvement is non-ideal
 49 2014-10-06 00:52:36 <phantomcircuit> gmaxwell, anybody who can install gentoo should know to look for USE flags
 50 2014-10-06 00:52:54 <gmaxwell> The defaults should be something that everyone could be comfortable using. Anything that singles out particular parties by definition fails that test.
 51 2014-10-06 00:53:05 <phantomcircuit> shrug
 52 2014-10-06 00:53:21 <phantomcircuit> call it payment to Luke-Jr for maintaining the ebuild file
 53 2014-10-06 00:54:08 <phantomcircuit> hmm
 54 2014-10-06 01:04:29 <jtimon> we should have a polymorhpic class CPolicy
 55 2014-10-06 01:05:04 <gmaxwell> jtimon: well my point was that it shouldn't be compiled in.
 56 2014-10-06 01:06:02 <gmaxwell> though gentoo users could handle recompiling to change policy, it doesn't work so well for anything else... and even there, ideally users shouldn't have to restart to change policy.
 57 2014-10-06 01:07:17 <kuzetsa> 
ACTION notices gentoo mention and perks slightly

 58 2014-10-06 01:10:36 <jtimon> users could write their own implementation of the class and run that instead without much maintainance overhead, and I think some policies (like replace-by-fees) should be compiled in the core as an alternative to the standard policy
 59 2014-10-06 01:11:57 <kuzetsa> wait, the default use flags on gentoo's bitcoind / bitcoin-qt has address reuse and other punishment patchsets in it and enabled by default?
 60 2014-10-06 01:12:10 <kuzetsa> xiando: what's going on here O_O
 61 2014-10-06 01:12:21 <kuzetsa> are you using the official gentoo build or luke's overlay?
 62 2014-10-06 01:12:39 <xiando> luke maintains the official gentoo ebuild so there is no difference. That is the issue at hand.
 63 2014-10-06 01:12:46 <kuzetsa> whoa
 64 2014-10-06 01:13:54 <gmaxwell> There has yet to be a single linux distribution which has distributed an unpatched bitcoind AFAIK, it's one of the reasons we discourage people from using distro versions. (in addition to them often being very slow/sloppy about updates)
 65 2014-10-06 01:14:47 <kuzetsa> gmaxwell: nod
 66 2014-10-06 01:15:14 <gmaxwell> At least policy changes won't result in consensus failures.
 67 2014-10-06 01:16:10 <jtimon> not even this? https://aur.archlinux.org/packages/bitcoin-git/
 68 2014-10-06 01:16:17 <Luke-Jr> gmaxwell: particular parties which are performing an active attack on the network, and only their active attack is being filtered by it
 69 2014-10-06 01:17:14 <kuzetsa> Luke-Jr: your opinion about so-and-so having a business model which you define as "an attack" is not one which is widely shared
 70 2014-10-06 01:17:15 <Luke-Jr> kuzetsa: address reuse deprioritisation is not implemented yet
 71 2014-10-06 01:17:17 <gmaxwell> IIRC arch was previously patching it, not sure if it is anymore.
 72 2014-10-06 01:18:04 <phantomcircuit> hmm actually that isn't half bad
 73 2014-10-06 01:18:09 <gmaxwell> kuzetsa: his definition isn't related to the business model.  I wouldn't use the attack characterization, but the same behavior actually does work as an attack when you think in terms of incentives.
 74 2014-10-06 01:18:09 <Luke-Jr> kuzetsa: the only part that is seriously questioned among experts AFAIK is whether the attack is intended as an attack or neglegence
 75 2014-10-06 01:18:40 <brisque> kuzetsa: do keep in mind that a very large portion of all transactions are made by Satoshi Dice.
 76 2014-10-06 01:18:57 <sipa> still?
 77 2014-10-06 01:19:00 <gmaxwell> kuzetsa: interesting argument: bitcoin is protected against flooding (and thus optimizes for effiient resource usage) by bidding on fees... with the belief that attackers are rational or at least funding bounded.
 78 2014-10-06 01:19:03 <sipa> i haven't heard from them in... years
 79 2014-10-06 01:19:26 <Luke-Jr> IMO, the intent is irrelevant when the objective fact of its behaviour is this clear; so I don't worry about trying to guess the intent of people besides myself whom I cannot know the intent of
 80 2014-10-06 01:19:29 <brisque> sipa: last I looked it was a few GB, which is still a large portion regardless of them continuing or not
 81 2014-10-06 01:20:00 <gmaxwell> kuzetsa: so you can do a cute attack where you take economically irrational participants who are willing to transact at a guarenteed expected loss, and ask them to flood the network, using the loss to pay for the flood... they'll out compete all rational participants.
 82 2014-10-06 01:20:06 <Luke-Jr> and people who disagree, can opt to not use my patchset - or use Gentoo's user patches feature to revert out that one part even
 83 2014-10-06 01:20:10 <kuzetsa> gmaxwell: "flooding" as defined here, is actually not well-defined (or any other kind of defined) -- please elaborate?
 84 2014-10-06 01:20:33 <gmaxwell> kuzetsa: the network has finite capacity. You use all of it and deny other users of the system access.
 85 2014-10-06 01:20:40 <brisque> sipa: last number I have is 4.1GB for July this year.
 86 2014-10-06 01:21:32 <kuzetsa> so then the definition is that a flood occurs whenever a usage model is a popular enough choice that bitcoin's capacity is pushed to the point of fees actually needing to be raised to compete?
 87 2014-10-06 01:21:40 <kuzetsa> gmaxwell: or am I misunderstanding
 88 2014-10-06 01:22:14 <gmaxwell> (or, under different constraints, we have some limited startup-up capitol in blocks being less than maximum size allowing for lower cost participation, which gets consumed)
 89 2014-10-06 01:22:23 <Luke-Jr> kuzetsa: you're ignoring the ratio factor
 90 2014-10-06 01:22:41 <Luke-Jr> kuzetsa: legitimately popular uses bring more resources to the network to compensate for the higher use
 91 2014-10-06 01:23:03 <sipa> Luke-Jr: i can't wrap my head around CreateNewBlock_validity, or why it can work
 92 2014-10-06 01:23:05 <Luke-Jr> "popular because the 'users' flood" does not
 93 2014-10-06 01:23:07 <gmaxwell> kuzetsa: well 'usage' is fuzzy. When irrational parties are funding your transactions the incentives are unhinged and its workable to use hundreds of transactions for each use and push everyone else out of the network.
 94 2014-10-06 01:23:12 <Luke-Jr> sipa: in what sense?
 95 2014-10-06 01:23:14 <kuzetsa> luke: same as above with the term "flooding", please define "legitimately popular"
 96 2014-10-06 01:23:33 <Luke-Jr> kuzetsa: actually having people who want to use it proportional to the load on the network
 97 2014-10-06 01:23:34 <sipa> Luke-Jr: it validatesblocks before setting the prev, so they're all genesii blocks before, but not anymore afterwards?
 98 2014-10-06 01:23:40 <kuzetsa> why is this popularity any less letitimate?
 99 2014-10-06 01:23:58 <sipa> Luke-Jr: anyway, i have a patch that breaks it, and i don't understand how it can have worked in the first place
100 2014-10-06 01:24:04 <sipa> so it's hard to fix :)
101 2014-10-06 01:24:12 <gmaxwell> kuzetsa: it's not a question of popularity. It uses hundreds of transactions where other competing services use one or two, because it does messaging via the blockchain.
102 2014-10-06 01:24:45 <Luke-Jr> sipa: it's setting the prev of the *next* block, to the current one
103 2014-10-06 01:24:50 <gmaxwell> e.g. system capacity usage 1000s of times larger than you'd expect given its actual userbase.
104 2014-10-06 01:25:10 <sipa> ah!
105 2014-10-06 01:25:46 <gmaxwell> kuzetsa: normally fees incentivize parties to not do that, but in that case it's unhinged.. which is interesting perhaps in terms of incentives.
106 2014-10-06 01:25:46 <kuzetsa> ooh, so this choice about defining the usage model as less legitimate is because it differs from other usage models which are lower load on the network?
107 2014-10-06 01:25:47 <Luke-Jr> kuzetsa: SatoshiDice could be implemented using 1000 times less resources; laziness isn't even an excuse because that implementation would be *easier*
108 2014-10-06 01:26:08 <sipa> i agree with all of this, but i don't think it matters
109 2014-10-06 01:26:12 <brisque> we have fools like blockchain.info to thank as well for enabling it.
110 2014-10-06 01:26:27 <gmaxwell> kuzetsa: it's not about legitimacy, rather we expect the system incentives to already naturally encourage efficient use. But they don't work when you're using economically irrational parties with lots of funds.
111 2014-10-06 01:26:38 <Luke-Jr> kuzetsa: in fact, I think there *are* actual gambling sites exactly like SD that don't flood the network
112 2014-10-06 01:26:38 <sipa> blocking the transactions will be controversial, and enabling by default in an unexpected way will make people feel fooled
113 2014-10-06 01:26:46 <gmaxwell> so it slightly breaks the natural fix the system already has.
114 2014-10-06 01:27:27 <gmaxwell> yea, I think this is orthorgonal with the gentoo version. I don't think it should have built in default policy different from the normal core releases unless its called something else.
115 2014-10-06 01:27:41 <kuzetsa> Luke-Jr: I thought SD's model was just 2-3 transactions per bet placed. is it actually worse than that? (1000 times worse?)
116 2014-10-06 01:27:49 <Luke-Jr> gmaxwell: the fact that we have a default policy at all is a bad thing.
117 2014-10-06 01:27:52 <brisque> kuzetsa: two.
118 2014-10-06 01:28:03 <Luke-Jr> kuzetsa: even 1 per bet placed is bad
119 2014-10-06 01:28:03 <sipa> kuzetsa: it shouldn't be one transaction per bet; it should be one transaction per credit/payout
120 2014-10-06 01:28:05 <kuzetsa> brisque: then waht's the problem? that sounds pretty legitimate
121 2014-10-06 01:28:10 <gmaxwell> kuzetsa: the bets are usually tiny with a high percentage of success. So a 'typical' user serssion may involve hundreds (or thousands) of bets.
122 2014-10-06 01:28:41 <Luke-Jr> indeed, if each SD user only did one bet, there would be nothing unreasonable about their load
123 2014-10-06 01:28:52 <brisque> kuzetsa: 4.1GB of bets. imagine there's 500,000 nodes. 2PB of bets stored.
124 2014-10-06 01:28:53 <sipa> the only way it works economically is because betters don't care about the irrationality of their action anyway
125 2014-10-06 01:29:55 <Luke-Jr> gmaxwell: I can agree the reference implementation shouldn't have ugly hacks, but in production, ugly hacks solving problems is better than no solution at all
126 2014-10-06 01:30:01 <gmaxwell> (further emphasized by the several other ways that its inefficient that have no business model impact, e.g. using uncompressed keys... I actually took the time to write a fast compressed pubkey vanity gen for them and they refused to use it.)
127 2014-10-06 01:30:22 <Luke-Jr> gmaxwell: speaking of vanitygen code… can you send some my way? :P
128 2014-10-06 01:30:23 <brisque> gmaxwell: why on earth
129 2014-10-06 01:30:34 <kuzetsa> brisque: yes, that's valid on a protocol level that all nodes will have the transactions (2PB, in your example)
130 2014-10-06 01:30:43 <gmaxwell> back when it mattered, there are fairly few transactions now that it's not publically traded anymore (haha)
131 2014-10-06 01:31:08 <gmaxwell> kuzetsa: well half the tx that they create are uneconomical to ever spend, so it's UTXO bloat too, even if you're not assuming nodes have history.
132 2014-10-06 01:31:17 <brisque> and this isn't blockchain.info's wallet anymore. https://i.imgur.com/8ib9H.png
133 2014-10-06 01:31:23 <kuzetsa> gmaxwell: yeah, so?
134 2014-10-06 01:32:08 <kuzetsa> if it's not economical, that will create a darwinism-style extinction of this business model if we just let it be a bad idea and fail naturally.
135 2014-10-06 01:32:40 <brisque> :C
136 2014-10-06 01:32:45 <gmaxwell> kuzetsa: so its huge amounts of state that is required to validate the network, which makes bitcoin either less decenteralized or more costly for it use as a currency. ... again, this is behavior which is already discouraged economically by the system, which is short circuited by the use of economically irrational participants.  In any case, I think of it mostly as a curiousity. It's no longer a huge harm now that the apparently ...
137 2014-10-06 01:32:51 <gmaxwell> ... fradulent traffic is gone.
138 2014-10-06 01:32:51 <Luke-Jr> kuzetsa: … did you read a thing anyone said in the last 15 mins?
139 2014-10-06 01:33:05 <gmaxwell> kuzetsa: it's not the _service_ that loses funds, its the users that do.
140 2014-10-06 01:33:42 <kuzetsa> [21:31:11] <gmaxwell> kuzetsa: well half the tx that they create are uneconomical to ever spend, so it's UTXO bloat too, even if you're not assuming nodes have history. <<<< I misunderstood what you meant by "uneconomical to ever spend", apparently?
141 2014-10-06 01:34:12 <Luke-Jr> kuzetsa: the users end up with the uneconomical outputs
142 2014-10-06 01:35:06 <kuzetsa> Luke-Jr: I feel completely amoral about who ends up with the "uneconomical to ever spend" UTXO set, as the end result will be darwinism-style extinction of this business model no matter which form of extinction occurs.
143 2014-10-06 01:35:12 <gmaxwell> kuzetsa: the minimum required to validate the blockchain is a database of potentially spendable coins. if someone creates zillions of 1e-8 outputs for non-payment reasons (messaging), they'll sit around forever increasing that cost... incentivizing dependance on centeralized resources like pools or hosted wallets.
144 2014-10-06 01:35:19 <Luke-Jr> kuzetsa: why would it?
145 2014-10-06 01:35:27 <gmaxwell> kuzetsa: its an externality.
146 2014-10-06 01:35:36 <Luke-Jr> kuzetsa: the only way this extincts the "business model" is by extincting Bitcoin
147 2014-10-06 01:36:01 <gmaxwell> normally the externality is guarded by fees. But you have 'suckers' that provide funds for free, defeating the defense.
148 2014-10-06 01:36:13 <jtimon> kuzetsa: to reiterate, the key is that messaging is a bad use for the chain
149 2014-10-06 01:36:46 <gmaxwell> perhaps eventually all the gamblers in the world will go bankrupt... human history suggests this is unlikely. :P
150 2014-10-06 01:39:30 <gmaxwell> this is all too not-production now for #bitcoin-dev. :P
151 2014-10-06 01:40:49 <Luke-Jr> gmaxwell: vanitygen code? pls? :p;
152 2014-10-06 01:41:53 <gmaxwell> Luke-Jr: for bfgminer, it needs a bunch of work before I can hand it to you. Lets talk elsewhere.
153 2014-10-06 01:42:16 <Luke-Jr> gmaxwell: I'm sure it does - were you planning on doing that? I assumed that'd be on me :p
154 2014-10-06 01:42:20 <Luke-Jr> #eligius maybe?
155 2014-10-06 02:09:03 <kuzetsa> xiando: your comment about the patch had me curious so I did an audit on gentoo's ebuild for bitcoind
156 2014-10-06 02:09:16 <kuzetsa> xiando: for bitcoind-0.9.2.1.ebuild at least, it has SRC_URI="https://github.com/${MyPN}/${MyPN}/archive/v${MyPV}.tar.gz -> ${MyPN}-v${PV}.tgz" and as such, bitcoin-v0.9.2.1.tgz gets pulled straight from the github repo with no evidence of patches being added (by luke or otherwise)
157 2014-10-06 02:09:51 <kuzetsa> also, I can't find any evidence that Luke-Jr is the package maintainer
158 2014-10-06 02:10:35 <kuzetsa> ^ from the "actually officially part of gentoo's repo and not an overlay" ebuild
159 2014-10-06 02:10:35 <kuzetsa> # $Header: /var/cvsroot/gentoo-x86/net-p2p/bitcoind/bitcoind-0.9.2.1.ebuild,v 1.4 2014/08/29 00:46:19 blueness Exp $
160 2014-10-06 02:11:05 <kuzetsa> or is gentoo's blueness actually Luke-Jr and I just never knew about that fact all these years?
161 2014-10-06 02:11:13 <kuzetsa> O_O
162 2014-10-06 02:12:38 <gmaxwell> man, it would suck if xiando was just trying to stir up drama
163 2014-10-06 02:12:55 <Luke-Jr> gmaxwell: that was obvious from the start IMO
164 2014-10-06 02:13:08 <gmaxwell> I missed the beginning of the conversation.
165 2014-10-06 02:13:10 <kuzetsa> yeaaaah, I think maybe xiando is using luke's personal overlay instead of just getting the package from gentoo
166 2014-10-06 02:14:08 <xiando> /usr/portage/net-p2p/bitcoind/bitcoind-0.9.3.ebuild IUSE="examples +ljr logrotate test upnp +wallet"  Try syncing if you are missing the latest ebuild
167 2014-10-06 02:14:18 <Luke-Jr> kuzetsa: I didn't backport my patchset until 0.9.3 - but this topic is getting old
168 2014-10-06 02:14:50 <Luke-Jr> (pre-0.9 did have some older patchsets)
169 2014-10-06 02:16:07 <kuzetsa> ah ok, I don't have any ebuild newer than 0.9.2.1.ebuild since I haven't done emerge --sync since the initial (major, remotely exploitable) shellshock vulnerabilities were being added to gentoo's portage tree
170 2014-10-06 02:16:18 <kuzetsa> *patches for [...]
171 2014-10-06 02:18:21 <kuzetsa> ah, sure enough, SRC_URI on the newer version includes http://luke.dashjr.org/programs/bitcoin/files/bitcoind/luke-jr/0.9.x/[...] <<< gross, no thanks on that being a default
172 2014-10-06 02:18:35 <kuzetsa> xiando: please file a bug with gentoo's bugzilla and I'll ack
173 2014-10-06 02:19:15 <Luke-Jr> kuzetsa: he already did; will probably close it INVALID or WORKSFORME
174 2014-10-06 02:19:27 <kuzetsa> oh ok, thanks
175 2014-10-06 02:19:37 <Luke-Jr> since there isn't an actual bug
176 2014-10-06 02:20:05 <Luke-Jr> (or if there is, xiando sure is trying hard not to say what it is)
177 2014-10-06 02:24:46 <tom99> wait so this whole time I could have reported all the bugs I've ever had on gentoo, debian, ubuntu, and fedora?
178 2014-10-06 02:27:30 <Luke-Jr> lol?
179 2014-10-06 02:27:54 <Luke-Jr> tom99: most have bug trackers, yes..
180 2014-10-06 02:27:59 <tom99> oh
181 2014-10-06 02:28:06 <tom99> sorry about that linux people!
182 2014-10-06 02:50:32 <kuzetsa> xiando: ack -- v
183 2014-10-06 02:50:34 <kuzetsa> oops
184 2014-10-06 02:50:44 <kuzetsa> xiando: my paste (ctrl + v) malfunctioned -- ack https://bugs.gentoo.org/show_bug.cgi?id=524512#c4
185 2014-10-06 11:28:46 <Anduck> would it be good if wallets stopped displaying like, less than 500 satoshi transactions? it could be modifiable limit
186 2014-10-06 11:29:03 <Anduck> then that 1-satoshi spam wouldnt reach the targets
187 2014-10-06 11:29:09 <Anduck> ( on default)
188 2014-10-06 11:29:26 <Anduck> also users wouldnt need to be annoyed by the dust they can't ever use
189 2014-10-06 11:32:16 <wumpus> at least bitcoin core already rejects transactions with outputs below the dust limit (5400 satoshis or so)
190 2014-10-06 11:33:42 <wumpus> no clue about other wallets, but sounds like something that would be trivial to implement
191 2014-10-06 17:28:03 <DanMAbraham> am i allowed to show you guys a drawing i did?
192 2014-10-06 17:28:15 <DanMAbraham> its my rendition of an elliptic curve
193 2014-10-06 18:07:17 <blueness> gribble, gwillen any other bitcoin devs.  I'm the gentoo maintainer for bitcoins.  we have controversy going on about https://bugs.gentoo.org/show_bug.cgi?id=524512
194 2014-10-06 18:07:58 <blueness> i have one and only one question, are sites like Sitoshi Dice a potential disruption to the bitcoin network?  I'm referring to Luke-Jr's patch which blacklists them.
195 2014-10-06 18:09:28 <gwillen> blueness: I'm not actually a bitcoin dev, just a moderator here; and gribble is a bot
196 2014-10-06 18:09:33 <gwillen> but you will definitely find bitcoin devs here. :-)
197 2014-10-06 18:12:09 <justanotheruser> blueness: I'm not a coredev, but I think they are because of the way they handle losses
198 2014-10-06 18:13:08 <justanotheruser> or at least the way they handled losses when I tried them like a year ago.
199 2014-10-06 18:13:50 <blueness> gwillen, are there any devs I should ask.  i need to get upstreams' opinion on this since 1) the contraversy is politically motivated and 2) i don't understand the bitcoin network/protocol well enough to make a judgment.  yet i want to make a judgment on technological grounds
200 2014-10-06 18:15:28 <justanotheruser> blueness: to tell someone they have lost they send them bitcoins that basically will never be redeemed which adds data to the UTXO forever, a database that every full node must have
201 2014-10-06 18:15:29 <earlz> So wait, for that patch it blacklists transactions for satoshidice?
202 2014-10-06 18:15:33 <justanotheruser> example 855d1acfbfce4cabd07ee6581b920460a04576e67260d4a2b22932d90a14fedf
203 2014-10-06 18:15:55 <sipa> blueness: i'm a core developer; i can't say i disagree with people choosing or encouraging others to run such a patch (i have done so myself at times), but i consider it dishonest to make it a default
204 2014-10-06 18:16:13 <blueness> justanotheruser, that information does help.
205 2014-10-06 18:16:30 <earlz> I don't see what this patch actually helps unless you're a mining pool using the wallet for mining..
206 2014-10-06 18:16:47 <blueness> sipa, i think i'm going to drop it as default and just put an informational blurb explaining what the patch does
207 2014-10-06 18:18:18 <earlz> How does this do anything to help the utxo bloat problem?
208 2014-10-06 18:18:37 <blueness> sipa, is there reason for concern about all excess data in the UTXO?
209 2014-10-06 18:19:24 <sipa> blueness: yes, creating transaction outputs that never get spent affects (fast) storage requirements for all future nodes
210 2014-10-06 18:20:01 <sipa> earlz: SD creates many outputs that are too small to be economical to spend
211 2014-10-06 18:20:02 <blueness> it makes sense to me.  this is probably why their practices are being labeled a "DDoS"
212 2014-10-06 18:20:52 <kjj> I'm reading the deluge about CHECKLOCKTIMEVERIFY, and I seem to be missing something.  Doesn't nlocktime already do exactly the same thing?
213 2014-10-06 18:30:23 <justanotheruser> blueness: they're not really denying service. Just making it more expensive
214 2014-10-06 18:34:28 <blueness> justanotheruser, okay a soft DoS.  I'm getting the impression though that htey are not doing this intentionally, that the extra expense a side effect of how they are using bitcoins
215 2014-10-06 18:35:18 <justanotheruser> blueness: them DoSing bitcoin is a side effect, right
216 2014-10-06 18:36:12 <gavinandresen_> kjj: nlocktime locks a transaction so it can’t get into the chain until later. CHECKLOCKTIMEVERIFY locks an output that is already in the chain, so it can’t be spent until later.
217 2014-10-06 18:36:52 <blueness> justanotheruser, that's why the question of their intention is secondary.  the more pressing issue is whether this extra impact is sufficiently high that it merits blacklisting them
218 2014-10-06 18:36:59 <blueness> that is not soemthing i can judge
219 2014-10-06 18:37:57 <earlz> sipa: if they're sending more coins than dust though, it's still spendable and a full node needs to respect that or risk a fork..
220 2014-10-06 18:37:57 <justanotheruser> blueness: the blacklist incentivizes them to not DoS bitcoin
221 2014-10-06 18:38:15 <kjj> I'm astonished how quickly state was accepted into the conditions
222 2014-10-06 18:38:42 <justanotheruser> earlz: there is no fork risk, it is changing whether a transaction is propogated, not whether it is valid
223 2014-10-06 18:47:44 <Luke-Jr> justanotheruser: to say the DoS is a side effect is based on intent, which we cannot know except from their actions; those actions do not suggest a benevolent intent (blueness☺
224 2014-10-06 18:48:44 <Luke-Jr> earlz: dust is not a concept at the Bitcoin protocol itself
225 2014-10-06 18:51:19 <DanMAbraham> Luke-Jr: A gift for you https://www.facebook.com/photo.php?fbid=774681792573075&set=a.199734086734518.44877.100000937842586&type=1 - ;)
226 2014-10-06 18:51:35 <DanMAbraham> EC Addition
227 2014-10-06 18:51:48 <DanMAbraham> point doubling rather
228 2014-10-06 18:51:49 <Luke-Jr> DanMAbraham: off-topic here, but thanks I guess
229 2014-10-06 18:52:04 <DanMAbraham> oh sorry
230 2014-10-06 18:52:18 <DanMAbraham> do you know if i drew it correctly?
231 2014-10-06 18:52:53 <justanotheruser> Luke-Jr: do you think that satoshidice is malicious, or just lazy?
232 2014-10-06 18:53:51 <Luke-Jr> justanotheruser: based on their actions (I cannot know their mind), I have to conclude it is malicious; laziness would result in an implementation that doesn't harm the network
233 2014-10-06 18:54:01 <Luke-Jr> (it's easier to implement correctly, than implement as a DoS)
234 2014-10-06 18:54:38 <justanotheruser> Luke-Jr: I mean too lazy to change their old code and too lazy to read up on what harm is caused by sending dust.
235 2014-10-06 18:56:08 <justanotheruser> it probabably takes very few programmer-minutes to send dust when losing, but many to determine that it is bad
236 2014-10-06 18:56:21 <sipa> i agree
237 2014-10-06 18:56:22 <Luke-Jr> justanotheruser: that's only one small part of their DoS
238 2014-10-06 18:56:28 <justanotheruser> oh?
239 2014-10-06 18:56:44 <Luke-Jr> justanotheruser: the main problem is abusing transactions as messaging
240 2014-10-06 18:57:09 <justanotheruser> how do they send messages other than sending "you lose" dust messages
241 2014-10-06 18:57:12 <Luke-Jr> justanotheruser: I suggest going over the log from last night
242 2014-10-06 18:57:18 <justanotheruser> ok
243 2014-10-06 18:57:28 <Luke-Jr> justanotheruser: they also send "I bet X on game X" and "you win" messages
244 2014-10-06 19:09:33 <earlz> So, I'll use the F word... but why not hard-fork to enforce dust prevention at the block level? That'd also make a lot of dust UTXOs provably unspendable and safe to trim away
245 2014-10-06 19:14:18 <justanotheruser> earlz: besides hardforking, the dust level is dynamic
246 2014-10-06 19:14:31 <justanotheruser> as more and more bitcoins are lost, there will be smaller and smaller tx
247 2014-10-06 19:14:39 <earlz> only in theory..
248 2014-10-06 19:14:50 <Luke-Jr> earlz: the dust level is dynamic in more than just theory
249 2014-10-06 19:14:52 <earlz> That's assuming more bitcoins are lost than minted
250 2014-10-06 19:15:08 <earlz> I didn't mean the dust level being dynamic.. I know that's just tx relay limits
251 2014-10-06 19:15:16 <justanotheruser> earlz: you realize bitcoins stop being minted eventually right?
252 2014-10-06 19:15:16 <Luke-Jr> earlz: also, it doesn't solve the problem.
253 2014-10-06 19:15:17 <gavinandresen_> earlz: how many dust transactions are we averaging per block right now?
254 2014-10-06 19:15:37 <earlz> I mean stuff like satoshidice.. isn't that dust?
255 2014-10-06 19:15:44 <Luke-Jr> earlz: only about 48% of it
256 2014-10-06 19:17:01 <earlz> Well, if it's dust, then why not prevent it from being put into a block
257 2014-10-06 19:17:16 <justanotheruser> earlz: it is prevented for the most part
258 2014-10-06 19:17:36 <earlz> How are the transactions getting put into blocks anyway, do they have a special mining pool?
259 2014-10-06 19:17:37 <justanotheruser> if you define dust as being outputs below the dust limit anyways
260 2014-10-06 19:17:38 <Luke-Jr> earlz: because dust is dynamic, we already said this…
261 2014-10-06 19:18:32 <earlz> I thought there was a hard limit
262 2014-10-06 19:18:36 <earlz> At least in bitcoin 0.9
263 2014-10-06 19:18:58 <justanotheruser> earlz: for propogation
264 2014-10-06 19:19:25 <earlz> yea.. but I mean what's the purpose of not enforcing that at the block level
265 2014-10-06 19:19:38 <Luke-Jr> earlz: it's still dynamic. users can change it, and ideally it would automatically adjust (I believe gavinandresen is working on this logic)
266 2014-10-06 19:20:02 <Luke-Jr> earlz: it's policy
267 2014-10-06 19:20:08 <Luke-Jr> it's supposed to change and vary by node
268 2014-10-06 19:20:22 <earlz> but that doesn't help the UTXO bloat problem, assuming SD has a pool or someone that accepts all their transactions
269 2014-10-06 19:20:47 <sipa> the only true solution to UTXO bloat is settig a UTXO limit
270 2014-10-06 19:20:59 <earlz> lol how would that even work
271 2014-10-06 19:21:04 <sipa> just like there is a byte limit and sigop limit to blocks
272 2014-10-06 19:21:16 <gavinandresen_> Reject any block that increases the UTXO set size “too much”
273 2014-10-06 19:21:32 <earlz> hmm.. that would be interesting
274 2014-10-06 19:21:32 <Luke-Jr> didn't we just get rid of that in 0.8.2? ;p
275 2014-10-06 19:21:35 <gavinandresen_> I think we should incentivize reducing the UTXO set size first, see if that works
276 2014-10-06 19:21:44 <gavinandresen_> (prefer blocks that reduce the UTXO set size in block races)
277 2014-10-06 19:22:08 <justanotheruser> ???
278 2014-10-06 19:22:09 <earlz> Only problem with that would be incentive for miners to mine empty blocks
279 2014-10-06 19:22:12 <justanotheruser> sounds dangerous
280 2014-10-06 19:22:14 <Luke-Jr> gavinandresen_: that could be dangerous (but I'm not saying to forget it)
281 2014-10-06 19:22:18 <gavinandresen_> empty blocks increase the UTXO set size.
282 2014-10-06 19:22:28 <earlz> Yes, but only by 1
283 2014-10-06 19:22:35 <sipa> nope
284 2014-10-06 19:22:36 <earlz> well..
285 2014-10-06 19:22:43 <sipa> the coinbase canhave hundrds of outputs
286 2014-10-06 19:22:50 <earlz> by only however many destinations the coinbase goes to... whatever
287 2014-10-06 19:22:51 <Luke-Jr> if it's a simple comparison, transactions that increase the UTXO set size might simply never get mined
288 2014-10-06 19:23:10 <gavinandresen_> Luke-Jr: mmm.  Might have to pay a higher fee for such a transaction.....
289 2014-10-06 19:23:14 <Luke-Jr> and you force people off pools with generational payouts to more centralised pools
290 2014-10-06 19:23:29 <Luke-Jr> gavinandresen_: a fee to cover the entire subsidy you stand to lose..
291 2014-10-06 19:23:31 <earlz> I mean an incentive for a miner to ignore all transactions.. there is already a tiny benefit to doing that anyway. The whole propogation bit
292 2014-10-06 19:23:54 <Luke-Jr> otherwise I send a 1 BTC fee that I never actually pay because I continually make smaller-UTXO blocks to reorg off the ones with my tx
293 2014-10-06 19:24:02 <justanotheruser> has anyone ever donated to reducing the utxo size?
294 2014-10-06 19:24:18 <earlz> donating would technically increase it ;)
295 2014-10-06 19:24:26 <sipa> before 0.8, the utxo setsize (ondisk) was several GB :)
296 2014-10-06 19:24:31 <Luke-Jr> actually, I could possibly even do that with a 25 BTC fee if I can eliminate any chance I lose it
297 2014-10-06 19:24:42 <justanotheruser> earlz: only if you do it wrong
298 2014-10-06 19:25:07 <gmaxwell_> Well people giving away their dust in dust-b-gone transactions are donation to reduce the utxo set size.
299 2014-10-06 19:25:19 <gavinandresen_> Luke-Jr: we want to incentivize several things: propagating blocks quickly (disincentivize selfish mining), including lots of transactions, decreasing (or at least not increasing too much) the UTXO set size.
300 2014-10-06 19:25:20 <earlz> ah
301 2014-10-06 19:25:40 <gavinandresen_> some function of all of those things to break block-races seems like the right way to go
302 2014-10-06 19:25:52 <earlz> There's also the matter of people encoding data in the blockchain wrongly
303 2014-10-06 19:25:57 <gavinandresen_> … or maybe several functions that people can choose between or tweak
304 2014-10-06 19:25:58 <Luke-Jr> "including lots of transactions" is not an obvious plus in itself - otherwise miners will just produce spam to inflate their blocks
305 2014-10-06 19:26:12 <earlz> making funds unspendable by sending them to a set of addresses corresponding with data
306 2014-10-06 19:26:15 <gavinandresen_> earlz: you’re coming across like a troll doing a gish gallop.
307 2014-10-06 19:26:31 <earlz> :/ I dont' mean to
308 2014-10-06 19:26:40 <Luke-Jr> gavinandresen_: the hard part IMO is doing it all in a way that can't be gamed
309 2014-10-06 19:27:18 <gavinandresen_> Luke-Jr: that’s why I kind of like having several choices and letting people set policy on their own. Hard to game systems if you don’t know what the rules actually are, because they’re ever-changing
310 2014-10-06 19:27:39 <Luke-Jr> fair enough
311 2014-10-06 19:27:41 <gavinandresen_> … and if you do manage to game the system to harm it, easier for people to react quickly to fix
312 2014-10-06 19:28:30 <gavinandresen_> Anybody measuring UTXO set size growth?  Is there a graph somewhere?
313 2014-10-06 19:29:16 <gmaxwell_> sipa has charted it in the past,  most recent graph I saw was from brisque I think.  (no news, ... dust limits appeared to work)
314 2014-10-06 19:30:05 <Luke-Jr> gmaxwell_: was that before dust-spammers started paying large fees?
315 2014-10-06 19:30:53 <earlz> why would people do that
316 2014-10-06 19:31:09 <Luke-Jr> actually, weren't the dust rules supposed to block regardless of fee? /me wonders how they're getting around that
317 2014-10-06 19:31:22 <Luke-Jr> earlz: blockchain.info lets you attach a message to the transaction; cheapish spam!
318 2014-10-06 19:31:57 <earlz> I thought those messages were just local to blockchain.info. ie, never went onto the network
319 2014-10-06 19:32:30 <Luke-Jr> earlz: they are
320 2014-10-06 19:32:36 <Luke-Jr> but apparently spammers like them
321 2014-10-06 19:32:41 <earlz> lol wtf
322 2014-10-06 19:43:39 <hearn> gavinandresen_: the flip side of that is if you don't know what the rules are, it's harder to write apps that work
323 2014-10-06 19:44:56 <gavinandresen_> hearn: hmm?  I’m talking about how to resolve block races, not whether or not your transaction will get accepted.....
324 2014-10-06 19:45:10 <hearn> oh sorry, i thought you were meaning dust limits
325 2014-10-06 19:45:13 <hearn> ignore me
326 2014-10-06 19:45:23 <hearn> this is what i get for reading irc backwards :)
327 2014-10-06 22:11:14 <lightlike> hey guys
328 2014-10-06 22:11:42 <lightlike> trying to get bitcore working with my local bitcoind, but I keep getting a "socket hang up" message -- has anyone had/solved this before?
329 2014-10-06 22:20:14 <BlueMatt> lightlike: this is not bitcore support, contact bitpay