--- Log opened Wed Oct 16 00:00:13 2013
04:42 < warren> http://mastercoin-explorer.com/  <--- Mastercoin actually exists?
04:42  * warren hasn't been paying attention
04:44 < warren> huh.  this thing is just another litecoin-0.6.3 clone
04:48 < warren> oh wait, there's actually two coins called mastercoin
04:51 < gmaxwell> lol
04:59 < sipa> are there any english dictionary words $W for which {$W}coin doesn't exist?
05:33 < wumpus> lol
05:33 < wumpus> starting to doubt it
05:33 < wumpus> almost looks like someone implemented my random altcoin generator idea
05:34 < warren> Does it get listing on an exchange on the first day, upload to github, post to bitcointalk, etc?
05:34 < warren> =)
05:36 < wumpus> it doesn't get listing on an exchange (that'd need help from one of the exchanges), but generating a name, generating a ruleset, uploading to github, posting to bitcointalk, sure :-)
05:36 < warren> steal a random picture from google images for the logo
05:37 < warren> automate more steps and more people will do it!
05:37 < wumpus> yeah or just generate a random color for the bitcoin logo and put a different letter in it
05:37 < warren> hah
05:41 < sipa> you should make it a game
05:41 < sipa> you can tweak only N parameters
05:41 < sipa> but if your altcoin takes off, you level up
05:41 < sipa> and you get to change more things in your next coin
05:42 < warren> sipa: game administrator might have to be centralized ...
05:42 < sipa> is that a problem?
05:42 < sipa> checkpoint broadcasts are ok as well, no?
05:43 < warren> seems anything is OK there.
05:51 < wumpus> good idea, 'coin tycoon'
05:52 < sipa> tycoin!
05:52 < wumpus> :D
05:52 < gmaxwell> thaicoin?
05:53 < gmaxwell> what currency symbol could it use?
05:53 < gmaxwell> I know, the Thai baht symbol!
05:53 < gmaxwell> (if its not already taken)
06:08 < gmaxwell> sipa:  http://bitcoin.sipa.be/speed-lin-2k.png you're off the scale again
06:08 < warren> Bitcoin is THAT awesome.  Off the scale.
06:14 < gmaxwell> warren: you ever offload that bfl you bought onto someone else? :P
06:14 < sipa> gmaxwell: my bitcoind is down it seems :(
06:14 < warren> gmaxwell: yeah, and I feel guilty about it now.
06:15 < warren> gmaxwell: I'm considering just giving his money back and eating the loss even though contractually I don't need to.
06:17 < warren> gmaxwell: I
06:17 < warren> I'm hearing nothing about deliveries now, and people who ordered months before me are reporting no deliveries, so the guy who bought mine is screwed.
06:17 < gmaxwell> hm. Did they suddenly go quiet?
06:18 < gmaxwell> I know people who had SC order recenly (couple weeks ago) got their piles of singles alternative.
06:18 < warren> recently?!
06:18 < warren> huh
06:18 < warren> gmaxwell: my April 2013 order didn't ship yet
06:19 < gmaxwell> no no I mean they recently recieved stuff, not recently ordered.
06:19 < gmaxwell> Ordering back in 2012.
06:19 < warren> gmaxwell: among other problems, they went quiet around August, and a few weeks ago people figured out that BFL was violating paypal's TOS, so paypal began seizing funds from them.  whoever figured it out first and used the secret escalation procedure got refunds until the seized funds ran out.
06:21 < gmaxwell> yea, I know. They were litterally calling some guy inside paypal who was hand processing it.
06:21 < gmaxwell> I deleted that guys phone number and name from the forum a bunch of time so people wouldn't mob him.
06:22 < warren> I sold only the 30GH unit that I got with the 6 months no interest paypal loan
06:22 < warren> I tried to get paypal to seize that but I learned about the escalation procedure too late.
06:23 < warren> BFL apparently began generating fake tracking numbers to stop paypal from giving refunds.  real shady.
06:24 < gmaxwell> wow, I'd missed that. Interesting. I saw some people getting tracking numbers when they canceled.
06:24 < gmaxwell> But I assumed that was someone lying to try to cause a run on cancelations.
06:24 < gmaxwell> warren: sorry, If I'd realized you were in a position where you might want to refund I would have prodded you personally.
06:26 < warren> I feel bad about the pre-order buyer so might just give him his money back.
06:26 < warren> dunno
06:38 < gmaxwell> warren: http://www.reddit.com/r/Bitcoin/comments/1o2zo0/just_got_email_confirmation_from_bfl_that_my/
06:41 < warren> gmaxwell: I managed to cancel all of my other orders before they stopped giving refunds ... so it's just one 30GH miner remaining from early April 2013
07:26 < gmaxwell> oh got.
07:27 < gmaxwell> that quantum wingnut guy apparently spoke at the Amsterdam bitcoin conf?
07:27 < sipa> what's a wingnut?
07:27 < gmaxwell> american term for crazy or weird.
07:28 < gmaxwell> I have an "investor" person emailing me asking for advice because he wants to invest in this guys super plan for BQP in polytime on clasical computers for mining.
07:28 < sipa> lol
07:28 < sipa> say you want 10%
07:29 < gmaxwell> hah
07:29 < gmaxwell> awful.
07:31 < wumpus> lol
07:36 < warren> "american term for crazy or weird." it's all relative in bitcoinland.
07:55 < warren> are we still switching to testnet4 for 0.9?
07:56 < sipa> what is testnet4?
07:56 < sipa> i don't object to resetting testnet, but i haven't heard about any specific plans or rule changes
07:57 < warren> oh, there was previous discussion about resetting it to discourage storing stuff there
10:01 < jgarzik> sipa, I had suggested resetting it proactively on IRC.  gmaxwell seemed to agree, but I don't think it was ever more concrete than that.
10:02 < jgarzik> testnet IMO should not be a permanent side channel database
13:52 < gmaxwell> jgarzik: I agree, but before we do that, we really ought to go figure out where the distributed tests are.... several useful tests were added to that chain later on (including ones that forked bitcoin 0.8-prerelease, bitcoin ruby, electrum, and btcgo) so we can make sure to add them to the front in the replacement.
14:17 < maaku> gmaxwell: if anyone does that, it'd be *really nice* to package that up into a bunch of transaction-generating scripts
14:18 < sipa> how about running pulltester on testnet? :p
14:18 < gmaxwell> sipa: pulltester tests reorgs.
14:18 < sipa> ok ok
14:18 < gmaxwell> maaku: Well the first 500 block of testnet are full of test cases.
14:19 < sipa> i mean, taking the transactions in pulltester, and puttiing them in the chain
14:19 < sipa> though i suppose there aren't that many
14:20 < gmaxwell> yea, reasonable way to go about it.
14:36 < BlueMatt> petertodd: no, if you are an spv node you shall not relay data you cannot fully verify
14:36 < BlueMatt> petertodd: this has been an unspoken network rule for a long time
14:37 < gmaxwell> BlueMatt: oh hai.
14:37 < BlueMatt> hi
14:37 < gmaxwell> BlueMatt: we probably should have CVEed the debian contrib init script stuff that set an rpc password. :(
14:37 < BlueMatt> petertodd: spv nodes shall only relay transactions they created
14:38 < BlueMatt> gmaxwell: probably, but debian should have done that themselves, really
14:38 < gmaxwell> BlueMatt: some guy with a fedora rpm was shipping it. I'd missed it when it was removed, but I caught it when auditing his package.
14:38 < BlueMatt> hmm
14:40 < BlueMatt> (I didnt publicize the removal of it because I wasnt sure when debian was gonna/did ship the fix)
14:42 < gmaxwell> well I've made it public (half on accident because I thought I was in /query with warren and not #bitcoin-dev ... :( though its not the end of the world I don't think that _that_ many were using that fedora package)
14:42 < BlueMatt> and hopefully people have been paying attention to the long-standing recommendation that rpc interface not be public, even if password protected...
14:42 < BlueMatt> but I suppose we can never depend on that :(
14:44 < warren> why do we allow one distro's packaging stuff into upstream at all?
14:48 < maaku> holy cow, there's a C++ REPL? http://root.cern.ch/drupal/content/about
14:50 < maaku> warren: there are many debian/ubuntu based distributions. it makes sense to put that stuff in contrib
14:51 < gmaxwell> warren: projects also do that as a way of having some amount of control/influence/visibility into how they are being packaged. ... though it doesn't stop distributions from ignoring it and patching the crap out of their software...
16:49 < amiller> ugh i'm really bothered by a couple more things now
16:49 < amiller> 1) i've been starting to think about how BTC (the currency) can be thought of as 'legal tender' within Bitcoin (the system) because of how it can be used for tx fees
16:50 < amiller> i'm trying to understand the implications of overlay currencies like in freimarkets and colored coins
16:50 < amiller> but actually since there are no mandatory fees
16:50 < amiller> it *doesn't* even enjoy any privileged status in that regard
16:50 < amiller> you could probably pay miners in colored coins, if the 'color kernel' supported that
16:51 < amiller> it's really entirely up to the miners what motivates them to include your tx
16:52 < amiller> i don't nkow of any colorcions that do that, but in freimarkets you can explicitly pay miners with portions of the self issued currencies
16:52 < amiller> an individual miner may or may not value these of course
16:52 < amiller> but for the sake of hard fork rules it doesn't matter
16:52 < amiller> 2) so this brings me to the second thing that's bugging me today
16:54 < gmaxwell> amiller: well, so long as the coloring rule inherits across fees.
16:54 < gmaxwell> oh you said that.
16:54 < gmaxwell> and yea, people have previously noticed that you can pay miners in other ways.. and in fact there is a history of that already.
16:55 < amiller> what kind of history?
16:55 < amiller> side deal or just with the tx broadcast?
16:55 < gmaxwell> (E.g. eligius providing free priority processing for mtgox as part of their hosting arrangement)
16:56 < gmaxwell> It's one of the reasons that "figure out what fees you should pay from recent blocks" is somewhat iffy.
16:56 < amiller> the second thing is that even if miners can't easily vote to change rules (because of some kind of constitutional interweaving somehow),
16:56 < amiller> i can't figure out what rationale prevents a couple mining pools from "discouraging" a particular transaction, perhaps temporarily
16:57 < sipa> they can perfectly vote to softfork
16:57 < sipa> censorship is only a softfork
16:57 < gmaxwell> (eligius also lets you pay fees by including outputs to the pools' donations addresses)
16:57 < amiller> i'm thinking of something in between a softfork and a hardfork
16:57 < gmaxwell> amiller: mining pools already discourage paritcular transactions.
16:57 < amiller> a hardfork is when you absolutely will not mine a block that has predicate x
16:57 < sipa> no
16:57 < amiller> a softfork is when you do not include in your block, transaction with predicate x
16:57 < gmaxwell> For example, many block correct horse stapler battery.
16:58 < amiller> mine on top of*
16:58 < sipa> amiller:
16:58 < sipa> no
16:58 < gmaxwell> amiller: no thats not the common convention.
16:58 < sipa> a hardfork is allowing something that used be illegal
16:58 < sipa> a softfork is disallowing something that was legal
16:58 < sipa> the rest is just policy
16:58 < amiller> oh.
16:59 < sipa> a softfork requires 51% from miners
16:59 < gmaxwell> What you're describing as a hardfork is a softfork. What you're calling a softfork is just policy.
16:59 < sipa> a hardfork requires 100% from everyone
16:59 < gmaxwell> Everyone that remains at least! :P
17:00 < amiller> i see.
17:00 < amiller> hmmmm
17:00 < sipa> there has exact
17:00 < sipa> ly one hardfork that i know of
17:01 < gmaxwell> and even that one is a little debatable! there are still old nodes running and current!
17:01 < warren> how?
17:01 < gmaxwell> because the bdb large block failure is non-determinstic.
17:03 < amiller> that makes a lot of sense, i don't know how i haven't understood this before, thanks.
17:04 < sipa> a hard fork is called that way because it inevitably forks off old clients
17:04 < amiller> actually i'm not sure where anyone would go to read that description clearly, i can't find it on the wiki
17:04 < sipa> a soft fork only causes an actual fork in case a majority of hash power is on the old code
17:05 < sipa> better explanations on the wiki would be great
17:05 < sipa> many things are just outdated or missing
17:06 < amiller> okay so then what i'm talking about is a softer-fork
17:06 < amiller> i can make my own predicate, or even just a temporary special case, and threaten to try hard to prevent it
17:07 < amiller> it's potentially costly for me in wasted-work if i ignore a block that has a transaction i don't like
17:07 < sipa> you're only threatening yourself
17:07 < sipa> unless you find a 51% hashpower to go along with you
17:07 < amiller> on the other hand, i have a chance at succeeding, and it may discourage other miners from including that transaction because i can harm them too
17:08 < sipa> how so?
17:08 < sipa> they don't care about seeing a competitor-mimer fork off
17:08 < amiller> suppose i have 20% or so hashpower
17:09 < amiller> i have maybe a 1 in 25 chance of succeeding in undermining a block that i don't like
17:09 < amiller> if i commit to doing that anyway, despite the cost to me
17:09 < sipa> they would care if network nodes would start enforcing your rule
17:09 < amiller> then other miners may not want to include transactions that will make me fight them
17:10 < sipa> well if they suspect that you (and those thinking the same way) have more than 50% together, yes :)
17:10 < amiller> no it doesn't need to be anywhere near 50%  is what i'm arguing
17:11 < sipa> not sure how
17:11 < amiller> suppose i have 20% of the hashpower
17:11 < amiller> how often is it that i find two consecutive blocks?
17:11 < sipa> once every 25 blocks, i guess
17:11 < amiller> 1/25?
17:11 < amiller> okay
17:12 < amiller> so if i commit to making a one-block attempt to undermine anything with transaction x in it
17:12 < amiller> then you are losing 4% of your effective hashpower if you mine a block with transaction x in it
17:13 < amiller> regardless of what anyone else does
17:13 < sipa> unless they actively discourage a block that does not have x in it
17:13 < amiller> hm, well yeah
17:13 < sipa> in which case the majority sode will always wim
17:13 < sipa> side, win
17:14 < amiller> s/regardless of what anyone else does/assuming everyone else runs like normal
17:14 < sipa> colluding against a <50% party is easy, if you have >50%
17:15 < sipa> in case there are different colluding parties
17:15 < sipa> you only need more than the largest other + non-colluding ones
17:15 < amiller> so perhaps miners will check their work at "doeseligiushatemyblock.com" to make sure they aren't triggering any retaliation
17:16 < sipa> i hope such things won't be necessary :)
17:16 < sipa> but maybe it's inevitablre
17:17 < gmaxwell> hard to say, miners mostly take stock software these days. (eligius being the largest major exception afaik)
17:21 < amiller> i wonder if it would even be meaningful to define a completely zero knowledge consensus protoco.
17:22 < amiller> i guess that's a little bit like the stuff adam3us is trying to think of
17:23 < amiller> the only defense i can think of this is to obscure as much information about the block as possible so that an influencer like that wouldn't easily be able to pick a predicate and enforce it
17:23 < amiller> you'd even want it to be deniable so that it couldn't just hate on everything that doesn't whitelist with it firs
17:25 < gmaxwell> amiller: it's called a timestamper? :P
17:25 < amiller> well no i mean
17:26 < amiller> zero knowledge except for that all applicable validation rules have been followed :o
17:30 < gmaxwell> amiller: part of the challenge there is that when the state is incremental, you actually have to know the state for form another one.
17:31 < amiller> maybe. sort of like what we were just talking about with utxo proofs,
17:31 < gmaxwell> so you can prove to me in zero knoweldge that you have a valid block xxxyyy  ... but that isn't enough for me to be able to build a successor blockl
17:31 < amiller> potentially you only need to know about the portion of the state that changes
17:31 < amiller> each transaction output is basically it's own little isolated private state box, no interaction with any others
17:31 < gmaxwell> yea, well if your 'state' is 1 bit and only changed once....
17:31 < gmaxwell> and starts as zero...
17:38 < amiller> not necessarily?
17:39 < amiller> it's hard to define this even just using generic primitives like universal zk and unuviersal homomorphic encryption
17:39 < amiller> like it would be easy to define as a multiparty copmutation
17:39 < amiller> publicly verifiable private property
17:39 < gmaxwell> yea great, that doesn't help. :P
17:39 < gmaxwell> amiller: the validation essential stuff is just the spentness bit. Pretty much everything else could be encrypted.
17:40 < amiller> but the main problem is that you don't want everyone to have to touch it in every round
17:40 < amiller> only the person doing the transfer should have to interact
17:41 < amiller> so we should have one big encrypted state file where we each know the contents of one part of the file
17:41 < amiller> and if i have privileges to that file, i should be able to update the file without interacting with anyone else, with a publicly verifiable proof that i only interacted with the part that i had authority to
17:41 < amiller> oh or that
17:41 < amiller> perhaps we both have to interact to change both our states
17:41 < amiller> like if i put some of my coins into your account then we have to interact so that you learn you have them
17:41 < amiller> maybe we do a 2 player secure copmutation to pull that off
17:42 < amiller> but the conservation rule would be publicly verifaible
17:43 < amiller> the implicit rule is that people behave "rationally" with respect to incentives like having an auction, but not discretionary
17:43 < amiller> like you should treat all bitcoins as equal and fungible and look only at their amounts
17:43 < amiller> even though that may not be enforced, that's in principle what's expected
18:07 < amiller> maybe removing the blocksize limit could have an unintended consequence of triggering the development of rational mining software
18:08 < amiller> because then it will more clearly be up to individual miners whether to build on a block or delay building on a block for a while
18:16 < gmaxwell> amiller: that kind of decision making is really really bad for convergence.
19:02 < HM2> Ok, time to dive in to Spirit X3
19:03 < HM2> promises 3x the compilation speed of Spirit v2
19:32 < HM2> wow, i managed to fix the broken git HEAD
19:36 < maaku> amiller: are you aware of the "republicoin" discussion that went on surrounding freicoin about a year ago?
19:36 < amiller> no
19:36 < amiller> link?
19:37 < maaku> meh, it's spread all over the freicoin forums, and hasn't been brought together into a unified proposal like freimarkets yet
19:37 < maaku> i can try to find the right threads, but here's a summary :
19:37 < maaku> basically using proof-of-stake + proof-of-work voting to negotiate soft-fork changes
19:38 < amiller> i think proof-of-stake sucks because it's so poorly defined, but i am hoping to change my mind!!
19:38 < amiller> i'm eager to read it
19:38 < maaku> could be any type of soft-fork change, but specifically we were thinking about mandating budgets for the demurrage
19:39 < maaku> and expected that a somewhat parlimentarian style system would emerge - parties advocating their own budgets, forming coalitions, and the one with 51% of the bicamerate PoS + PoW vote would get to say how it is spent
19:40 < amiller> that reminds me a bit of an idea someone told me last week
19:40 < gmaxwell> maaku: I don't understand how having anything but a hashchain majority matters what what is actually a soft forking change... as that majority could just force whatever outcome they want.
19:40 < amiller> about why not make bitcoin, but for the US dollar, since the US has pretty good monetary policy
19:40 < gmaxwell> (or at least force the status quo)
19:40 < amiller> i actually like the idea!
19:40 < amiller> we don't really have a great model for how the monetary policy works
19:40 < amiller> so it's hard to make it an algorithm
19:40 < amiller> on the other hand it has a sort of well defined interface
19:40 < amiller> there's a trusted steward who sets a global interest rate
19:41 < amiller> then that interest rate is offered for overnight borrowing to a handful of trusted/appointed borrowers
19:41 < gmaxwell> amiller: we could call him "real solid"
19:41 < amiller> you could totally import any monetary policy system you like and implement it on top of whatever ledger/transaction/consensus system you want
19:42 < amiller> but hopefully no one would use it because trusted parties suck
19:42 < gmaxwell> There have been a number of coins that basically had centeralized control of inflation. (solidcoin in one of its worthless renditions, for example)
19:42 < amiller> it's not the slightest bit clear to me that parliamentary fighting is any more desirable either :/
19:42 < amiller> i think i like constitutioncoin better than republicoin
19:43 < amiller> ostensibly what we have is constitutioncoin
19:43  * gmaxwell votes to take amiller's bank account and split it equally among everyone else in the channel
19:43 < gmaxwell> All in favor?
19:43 < amiller> lol.
19:45 < maaku> amiller: heh, no, but freicoin has a perpetual 4.9% subsidy... simply giving all of that to the miners may be paying for too much security
19:45 < maaku> finding decentralized solutions to that is not easy...
19:46 < amiller> not easy, granted
19:46 < maaku> the big problem with republicoin is proof-of-stake - all the current systems suck, big time
19:46 < gmaxwell> maaku: yea thats one of the main arguments against any kind of inflationry coin, ... certantly giving the money to miners is potentially insane.
19:46 < amiller> who else do you give it to
19:47 < maaku> amiller: the republicoin answer is basically the same as the current (real-world) status quo: let a government elected by the people distribute it
19:48 < gmaxwell> amiller: you could lower inflation if you're paying too much for security.
19:48 < amiller> maaku, ^
19:48 < gmaxwell> but you'd still need a virtual bernake to make that call.
19:49 < maaku> gmaxwell: except in freicoin where "inflation" is determined by the nature of money, not security needs (4.9% demurrage required for 0% basic interest, nothing to do with security needs)
19:49 < maaku> but that's a discussion for #freicoin
19:49 < gmaxwell> maaku: I was just saying in the abstract.
19:50 < gmaxwell> The decision problem still exists even in the simplest case.
19:50 < maaku> the real issue with republicoin is that there isn't to my knowledge an adequate proof-of-stake voting system
19:51 < maaku> all the current ones suck big time...
19:51 < gmaxwell> I don't think one is possible.
19:51 < gmaxwell> :(
19:51 < gmaxwell> (This bums me out greatly)
19:51 < gmaxwell> (because in general POS is a great idea, but it seems like you need a consensus system on top of it to make it actually work)
19:51 < gmaxwell> If you give me timelock encryption then I think I can make POS work.
19:52 < gmaxwell> Or at least almost work enough.
19:52  * amiller gives gmaxwell some timelock encryption??
19:53 < gmaxwell> amiller: e.g. I think you can do a POS consensus with timelock encrypted votes to prevent censorship. By the time anyone knows what the old state is, it's hopelessly burried.
19:53 < gmaxwell> (you use proofs that the hidden states are valid)
19:54 < gmaxwell> and timelock encryption means someone can't wedge the system by failing to ultimately disclose.
19:54 < maaku> gmaxwell: i'm fine with a side-chain. i'm even fine with public votes, although obviously something homomorphic would be better
19:54 < maaku> but yeah it would be a lot easier (trivial, almost) with time-lock encryption...
19:54 < gmaxwell> maaku: the problem with public votes is not that they're public, is that it allows whomever controls the consensus system that gathers them to censor the votes so the outcome is as they choose.
19:55 < maaku> ah, so proof-of-stake would essentially become proof-of-work once 50% of miners are corrupted
19:56 < gmaxwell> right. "I don't like this vote very much, bye bye"
19:56 < maaku> amiller: this is probably the best post : http://freicoin.freeforums.org/demurrage-should-it-all-go-to-miners-t20-40.html#p354
19:56 < maaku> but google 'republicoin site:http://freicoin.freeforums.org' to find some others
19:57 < maaku> it's an idea i would like to pursue, but the technical issues need to get worked out first...
19:57 < amiller> "I have an answer, albeit not a strong one: their own economic self-interest in the future of Freicoin."
19:57 < amiller> i'd love to understand that better but it's hard to reason about
19:58 < amiller> it's not totally wrong but it's tricky
19:58 < amiller> people are like, systematically myopic
20:00 < gmaxwell> maaku: another way to make POS votes work is to require _every_ coin to vote. But then your system dies the first time a key is lost. :(
20:00 < maaku> amiller: i have a crushing rejoinder which will squash any doubts
20:00 < maaku> you're right
20:00 < maaku> like i said, it's not a strong argument
20:01 < maaku> but it is basically the analagous situation as real life politics - what stops the big guys from buying the politicians votes?
20:01 < amiller> nothing, that's exactly what happens
20:01 < maaku> well, nothing really. that is what happens. but within limits
20:01 < gmaxwell> s/stops/tames/
20:01 < amiller> the limits aren't reliable
20:02 < gmaxwell> sure but it's not unbounded. It's actually pretty tricky to achieve any constraint at all.
20:02 < amiller> Okay so i'm writing up (for a lovely forum post) the idea of doing this soft blacklist
20:02 < amiller> i'm stuck on something
20:02 < amiller> besides getting two consecutive blocks
20:02 < maaku> as I said, not a strong argument, but there is enough room that a middleground might exist.. or at least hope for one
20:02 < amiller> there might be a way to just do one block, and incentivize people to take my block
20:02 < amiller> suppose there are two blocks at roughly the same time
20:02 < amiller> it's undefined which one people will choose right?
20:02 < amiller> whichever one they get first?
20:02 < amiller> there's no prioritization about blocks right now
20:03 < amiller> but suppose one block contains any anyone can pay transaction or something that only is valid if that blocks gets accepted
20:03 < amiller> you could then either mine on block A and get nothing, or mine on block B and get a bonus!
20:03 < sipa> the best pick (for consensus) is the one that you have most confidence in others will also pick
20:03 < amiller> the problem is you can't spend the coinbase immediately and you can't make a transaction pegged to one block
20:04 < amiller> you can in freimarkets where there's an OP_HEIGHT code
20:04 < amiller> is there any way to do that? to give a fee to the miner of the next block for building on the current block?
20:05 < maaku> amiller: give them the fee in the output of the coinbase
20:05 < amiller> no because you can't spend coinbase for 100 blocks
20:05 < maaku> they can't spend it immediatly, but they know it's there
20:05 < maaku> or am i missing something?
20:05 < amiller> they don't get it, the 100th block miner gets it
20:05 < maaku> oh i c
20:05 < gmaxwell> which they have hashrate/total_hashrate probablity of earning.
20:06 < gmaxwell> You can also lower the variation by 'announcing' a not yet valid spend cascade that spread it out over many blocks.
20:07 < gmaxwell> e.g. at height 100 that miner gets half, at 101, that miner gets 1/4, at 102 that miner gets 1/8... and so on.
20:11 < gmaxwell> amiller: speifically preventing this is why I'd said in the OWAS thread that the OWAS payments had to be maturity gated.
20:11 < gmaxwell> otherwise you get stupid randsom effects that screw up consenus.
20:11 < amiller> i'm going to call this a "feather-fork"
20:11 < amiller> because it's like a softer soft fork that only lasts for a couple blocks and only might work
20:12 < amiller> but may still have an influence
20:18 < maaku> i assume you would do that using time locked transactions?
20:19 < gmaxwell> maaku: yea, to space them out.
20:19 < gmaxwell> e.g. one locked at +100, +101, etc.
20:43 < petertodd> BlueMatt: Well frankly I think that's a dumb rule. For instance, would you object to SPV nodes relaying block headers to each other to be sure they had the best chain? I can't see why. Then if you don't object to that, why not relaying blocks too? Relaying transactions of course can have DoS issues, but if you solve those with a PoW or something, again, why not? Knowing more information will never harm you.
20:44 < BlueMatt> petertodd: spv nodes shouldnt relay headers to each other that they cant verify, no
20:44 < BlueMatt> petertodd: spv nodes shouldnt connect to each other to begin with, really
20:45 < gmaxwell> BlueMatt: why not? if both parties connected are consentual participants?
20:45 < gmaxwell> E.g. "I didn't verify this, you still want it?"
20:45 < gmaxwell> "You know I'm stupid, but if you want me to tell you what I hear, I will."
20:45 < BlueMatt> gmaxwell: consensual in this case means policy defined by developer of spv nodes...
20:46 < gmaxwell> BlueMatt: or whatever they've negoiated.
20:46 < gmaxwell> (the nodes I mean)
20:46 < BlueMatt> and developers shouldn't make their policy of spv nodes to peer with other nodes
20:46 < BlueMatt> if someone wants to do that, they sure can
20:46 < BlueMatt> but thats up to their implementation
20:47 < gmaxwell> BlueMatt: right now SPV nodes are pretty vulnerable to a multitude of attacks, increasingly so as the number of accessible full nodes continues to drop.  One strategy to combat this might be for higher resource SPV nodes to connect to each other too.
20:52 < BlueMatt> gmaxwell: problem: full nodes aren't available as much as they should be, solution: work around the problem by coding lots of logic for spv nodes to rumor between each other
20:52 < BlueMatt> seems wrong to me
20:52 < BlueMatt> could just code some logic to make full nodes more appealing to run...
20:52 < gmaxwell> BlueMatt: Maybe. Depends on how fundimental the lack of full nodes problem is.
20:52 < gmaxwell> These aren't mutually exclusive. We may eventually need _both_.
20:52 < BlueMatt> true, but Ive seen no data to indicate the issue is really unsolvable with reasonable work?
20:53 < gmaxwell> I don't think we fully understand the reduction in reliable full nodes.
20:53 < BlueMatt> maybe, but I see no reason to code the spv rumoring for some time to come unless we've come a long way
20:54 < gmaxwell> yea, I missed the beginning of you and PT's conversation.  This is #bitcoin-wizards after all, and I was just chiming in that I don't think it would be unreasonable in the long term to have SPV nodes who are willing and able play a bigger role in the network.
20:55 < petertodd> BlueMatt: why?
20:55 < petertodd> BlueMatt: heck, blockheaders over twitter is genuinely useful
20:55 < BlueMatt> petertodd: blockheaders over twitter comes from a full node...
20:55 < gmaxwell> BlueMatt: bitcoin-qt's performance has improved _tremendously_ as has its reliablity (except on OSX).
20:55 < BlueMatt> gmaxwell: I dont really like that idea, but yes its an option...
20:56 < BlueMatt> gmaxwell: better: partially-verifying nodes playing a bigger role
20:56 < petertodd> BlueMatt: that's irrelevant
20:57 < petertodd> BlueMatt: blockheaders over twitter is validatable by the fact it's the longest valdi sets of headers you know of, *nothing* else
20:57 < petertodd> Let alone once we start talking about partial probabalistic validation schemes w/ fraud proofs...
20:57 < gmaxwell> BlueMatt: ultimately the shift in nodes type may just be that people do not see any reason to run anything but spv nodes anymore.
20:58 < BlueMatt> petertodd: my point is that, in the current network, there is NO reason for an spv node to take information from a node it knows is not doing any verification
20:58 < BlueMatt> in the future, maybe it will be neccessary
20:58 < BlueMatt> but not now
20:58 < petertodd> BlueMatt: how does the SPV node know the node it's talking to is doing verification?
20:58 < BlueMatt> gmaxwell: yes, which is why nodes should upgrade
20:59 < BlueMatt> petertodd: it doesnt, but it also shouldnt actively seek out nodes it knows arent verifying and ask them for data
20:59 < gmaxwell> BlueMatt: I am concerned that upgrading is now less of an option, since it seems to be socially accepted that SPV or webwallet is all you need. Sort of a moot debate unless it exists.
21:00 < BlueMatt> webwallets we cant really control (but that doesnt cause a decrease in spv:full node ratio, so..meh), but spv clients can upgrade to full nodes if they have the resources
21:00 < petertodd> BlueMatt: I can fire up a thousand fake full nodes on amazon ec2 for not that much money; SPV nodes just don't know. They're much better off passing around block header information as widely as possible to try to detect them being isolated by false full nodes.
21:00 < BlueMatt> and since so may spv wallets are bitcoinj.......
21:01 < petertodd> BlueMatt: There is just *no* case where finding out that there exists a longer set of headers than the one the full nodes you're talking to claim exist will be harmful to you if you can't trust those full nodes.
21:02 < petertodd> BlueMatt: Also, FWIW I *have* done something similar to that: I fired up enough EC2 instances doing the bloom io attack that I saw random nodes all over the network falling behind in consensus. Cost me ~$50 or something IIRC.
21:02 < BlueMatt> petertodd: Im looking at it a different way: if you're an spv node and have X outbound connections you want to make, should you connect to other spv nodes (which not only are non-verifying, but will likely only stay online for some brief period of time)
21:02 < BlueMatt> or would you rather connect to full nodes?
21:03 < petertodd> BlueMatt: If there were infinite full node capacity lying around, then yes, you'd want to connect to full nodes. But there isn't, so it's reasonable to connect to SPV nodes.
21:03 < BlueMatt> and since spv nodes generally also dont listen....
21:03 < petertodd> BlueMatt: Not yet, but they may start to in the future, hence why I mentioned that example in my BIP.
21:06 < petertodd> BlueMatt: I hope you understand that's a *very* different argument than "SPV nodes shouldn't be relaying stuff"
21:06 < BlueMatt> spv nodes relaying headers also doesnt apply in this case since headers arent filtered
21:07 < BlueMatt> (in the BIP, that is)
21:07 < petertodd> BlueMatt: No, but if your relaying headers, there's no reason not to relay blocks too.
21:07 < BlueMatt> petertodd: in the future, sure, but, again, in this case it makes absolutely no sense
21:07 < petertodd> BlueMatt: (modulo bandwidth)
21:07 < petertodd> BlueMatt: "in this case" meaning the situation right now?
21:08 < BlueMatt> as in in the BIP
21:08 < BlueMatt> really, I dont like the NODE_BLOOM bit without thinking hard about how to announce you are a fully verifying node and not an archive node and all that stuff
21:08 < petertodd> BlueMatt: Right, will if it causes enough constination - given it's not why I added that example in the BIP anyway - I'll just re-write it to talk about a hypothetical NODE_BLOCKCHAIN or something where NODE_BLOOM means "filter that information against this filter"
21:09 < BlueMatt> sgtm
21:09 < petertodd> BlueMatt: If anything, NODE_BLOOM and some future NODE_ARCHIVAL_BLOCKS makes a lot of sense due to the differences in what you're trying to optimize for if you're serving up SPV clients vs. you want to serve up archival history efficiently.
21:10 < petertodd> https://github.com/bitcoin/bitcoin/pull/2900#issuecomment-23274616
21:10 < BlueMatt> definitely, and Id kinda like to see all the bits come in one bip, but that probably isnt reasonable to push it through...
21:11 < petertodd> BlueMatt: yeah, I think it's fine to just have a bip saying "here's this NODE_BLOOM bit, it means we're willing to filter stuff"
21:11 < petertodd> Heck, as I said to sipa the other day for now NODE_BLOOM and nothing else is an abstract art piece where you promise you'll filter the nothingness. :P
21:11 < gmaxwell> BlueMatt: we could just someday do a flag overview bip that overviews them and points out their interaction.
21:11 < gmaxwell> hahahahahah
21:12 < BlueMatt> OH GOD
21:12 < BlueMatt> NOOOOOOO
21:12 < gmaxwell> petertodd: "collision free bloom node"
21:13 < petertodd> gmaxwell: "Can nothing collide with itself?"
21:13 < gmaxwell> What is the sound of an empty hash table? Can it be local?
21:14 < petertodd> gmaxwell: We'll have to test for non-compliant implementations that fail to accept filter* requests.
21:15 < warren> petertodd: I'm working on one right now...
21:17 < petertodd> warren: the implementation is all well and nice, but I expect an artists statement to go along with it
--- Log closed Thu Oct 17 00:00:16 2013