--- Log opened Mon Dec 16 00:00:59 2013
00:26 < gmaxwell> andytoshi: you need to convert all the numbers to integers. Don't use floats for this stuff.
00:26 < gmaxwell> andytoshi: you can just remove the . and you have an integer. :P
03:34 < adam3us> seems like it would be better if people who pool mine without using getblocktemplate (without being a full node) got their coinbase from power users they know (finding full nodes at random would be vulnerable to sybil)
03:35 < adam3us> otherwise its a vote abdication leading to policy centralization and double spend abuse (like ghash.io seemingly gaming the satoshi-dice clone)
03:35 < maaku> adam3us: is there any one left that doesn't use getblocktemplate (excepting stratum)?
03:36 < maaku> getwork can't keep up with asic speeds
03:36 < adam3us> maaku: i do not know - the last time i asked about this people told me GBT is the answer, and then after a bit they said however few are using it; if there is a reversal of that situ its good
03:37 < adam3us> why cant the same be done with leased equipment or user owned but datacenter hosted - user provides coinbase for mining
03:37 < adam3us> maaku: i think getwork is a confused design, the client miner can chose the work - thats the point of hashcash - its fully decentralized
03:38 < maaku> adam3us: that's how getwork was meant to be used
03:38 < maaku> satoshi did not foresee mining pools
03:39 < maaku> pools just adopted the same interface as the distributed client (getwork)
03:39 < adam3us> maaku: as i understand it getwork is a mechanism for a miner to ask a pool for a section of work, which is a misthink - no one needs to ask a pool for anything other than the pools current preferred reward address
03:40 < warren> adam3us: does it help at all that my key is here?  https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-downloader/wtogami-key.pgp
03:40 < adam3us> maaku: the search space is not scarce and does not need to be manually divided up; the client should pick a random starting point
03:40 < wumpus> getwork is confused design, but I thought about no one was using it anymore?
03:40 < maaku> adam3us: getwork predates pools
03:41 < wumpus> there have been plans to deprecate it
03:41 < maaku> getworks predates the idea of pools
03:41 < maaku> how does your mining program ask for a block from your locally running full-node bitcoind instance?
03:41 < maaku> getwork was the answer to that
03:41 < adam3us> maaku: what proportion of mining is happening using getwork do we think?
03:41 < maaku> ~zero
03:41 < wumpus> getblocktemplate
03:42 < maaku> at 4GH/s you are making 1 getwork call per second
03:43 < maaku> most of the hash power of the network is in asics orders of magnitude larger than that
03:43 < maaku> meaning 10's, 100's, 1000's of network calls to getwork
03:43 < maaku> doesn't scale
03:43 < adam3us> maaku: that seems silly and an invitation for network induced miner dead time - you need only to make 1 request per successful pool win (if the pool changes its reward address)
03:44 < adam3us> maaku: ok you are saying stall due to asic has pushed people off getwork, which is a good side-effect
03:44 < maaku> adam3us: yes
03:44 < adam3us> maaku: now what about proportion of pooled miners that are building their own blocks?
03:44 < maaku> as soon as asics hit the market, getwork died and getblocktemplate/stratum replaced it
03:45 < maaku> adam3us: 1%
03:45 < maaku> the p2pool miners
03:46 < adam3us> maaku: you think none of the miners are running full nodes, or if they are the full node is not used to construct the block to put in the coinbase?
03:46 < adam3us> maaku: (none of the pooled miners)
03:46 < maaku> adam3us: none of the pools that I am aware of let you construct your own blocks
03:46 < warren> adam3us: very few of the miners run a full node, maybe some do part time when they do wallet tx
03:46 < maaku> maybe Luke-Jr's does, I wouldn't be suprised
03:47 < maaku> the pool gets control over what goes in their blocks - that's part of the agreement
03:47 < maaku> if you want to construct your own blocks, that's what p2pool is for
03:47 < adam3us> warren: (pgp key) a bit maybe - is that some strongly controlled position of the bitcoin github?  (my main point was a gentle reminder - put your full fp on the card:)
03:48 < adam3us> maaku: well people tell me p2pool has scaling issues at present
03:48 < warren> adam3us: recent mining clients have the ability to do local block submission, it helps in block propagation (helps against orphans) and possible fallback to solo mining if the pool is down.  Not sure if any pool supports this yet.
03:49 < adam3us> maaku: and people complain about the centralization risks of pooled mining, where its not that expensive to maintain your own full node and construct your own block
03:49 < adam3us> maaku: why would the pool care or have a legitimate need to consider whats in the block? that sounds like a dangerous contract
03:49 < warren> adam3us: p2pool's scaling issues are partly psychological, partly dust, partly because it is a single thread.  It isn't THAT bad.  I invested a good deal of money into improving it further since I don't have time to code on it now.  https://bitcointalk.org/index.php?topic=329860.0
03:50 < adam3us> warren: yes i remember that thread
03:50 < warren> adam3us: there's considerable disadvantage to block propagation and losses to orphans for the average home solo miner.
03:51 < adam3us> anyway for whatever reason p2pool is 1% so defacto pools are controlling blocks which is bad
03:51 < warren> I agree.
03:52 < warren> p2pool even has a good solution against orphans with the tx pre-forwarding.
03:52 < adam3us> warren: wouldnt it be possible for the solo to tell the pool what the winning block serialization is, compactly
03:52 < adam3us> p2pool has no fee also
03:52 < warren> adam3us: sure, just few if any pools are doing it that way now, I think.
03:53 < warren> adam3us: the vast majority of pools are run by people who copied code from github and don't understand it.  They get exploited all the time and lose money.
03:53 < adam3us> warren: are there code/apis existing that even support a pooled miner uploading the winning block to the pool (in raw or compressed eg ref to txs + raw missing tx)?
03:54 < adam3us> warren: yeah we need an economy of clues factor (or a dis-economy of scale)
03:56 < adam3us> was talking to justus at the conf, he suggested maybe a not-very-decentralized kind of 'candidate block' and then users can encode an actual block compactly as a patch/diff to that
03:56 < warren> adam3us: looked at how p2pool does it?  It's already very good there.
03:57 < warren> it only works for immediate peers
03:57 < adam3us> warren: no i dont know p2pool low level details
03:58 < gmaxwell> So, — tuning back to my computer for a minute to fill in some details here.
03:58 < gmaxwell> Getwork is mostly not used anymore for the reasons maaku named.
03:58 < adam3us> i just would like to see a way to reduce the centralization even if its something stupid like advertising p2pool if it can take the load (like why would someone pay 5% to big pool whos operator is doing stupid stuff)
03:59 < gmaxwell> The vast majority of miners use this protocol "stratum" that slush created which is somewhat poorly documented. It gives miners a coinbase transaction and a hashtree path to it. The miners can't see or control the transactions (though there are some not widely supported extensions to show them the transactions)
04:00 < gmaxwell> A few pools support using getblocktemplate directly. (Basically just ones running the pool server software luke wrote)
04:01 < gmaxwell> Though because it doesn't hide transaction data from the hashers it takes more bandwidth.
04:01 < adam3us> gmaxwell: whats the difference or benefit gbt offers over stratum?  it gets the to download the block?
04:02 < gmaxwell> If you're using GBT with bfgminer (luke's miner software) it can do useful stuff like locak submission.  The miner software also does some sanity checking of the work, but right now the most material check is just self-consistency, e.g. the hasher can detect (and will refuse to participate) if a pool directs them to fork back a chain they worked on previously.
04:03 < gmaxwell> GBT also allows malleability of the block, with the pool signaling what kinds of modifications the hasher is allowed to make.
04:03 < adam3us> as it stands would most of the network hashrate blindly vote that 1+2=100?  (create fake tx out value fooling spv clients) if a dozen hosts / routers on the internet were hacked
04:03 < gmaxwell> Though even that limited level of sanitization (and mutation) is only done by bfgminer, which is— I believe— the somewhat less popular miner software.
04:03 < adam3us> gmaxwell: fork reject is good
04:04 < gmaxwell> adam3us: yes, pratically all the hash power would let the pool produce a billion bitcoin subsidy, I think. Though anything gbt mining gets enough data to do more.
04:04 < adam3us> gmaxwell: does gbt check values? or i mean does it receive enough info to check values?
04:05 < gmaxwell> A thing luke, myself, and peter todd were talking about a while back was getting software support for "coinbase only pooling"— where you do a GBT request to a pool to get a permitted coinbase transaction, then get the rest of the block from a local (or just different) source.
04:05 < maaku> adam3us: i don't know what you mean by check values, but gbt provides enough information to fully reconstruct the block
04:06 < maaku> well, assuming you can fetch/find the relevant transactiosn
04:06 < gmaxwell> adam3us: it gets enough information to do stateless checks. Though without a trusted bitcoin there isn't enough data to check that much. BFGminer does a couple stateless checks. CGminer does no checks at all.  BFG can also do local submission, e.g. when it finds a block it can send it to a local daemon as well as the pool (or to multiple pools for that matter)
04:06 < gmaxwell> maaku: gbt sends the transactions.
04:06 < maaku> oh i thought it was just the tx hashes
04:06 < adam3us> maaku: i mean mining validates two things: non-double spend and that inputs add to outputs (i am not sure even spv nodes would accept a > 25 coin reward??)
04:07  * maaku goes to read the bip
04:07 < gmaxwell> Nope.
04:07 < gmaxwell> adam3us: they absolutely will accept a >25 coin reward, because the generated coins include _fees_ which are not statelessly verifyable.
04:07 < gmaxwell> As are no-double-spends unless you just mean doublespends within a single block.
04:09 < gmaxwell> (the local submission stuff, if anyone used it would break any pools attempt to do 'selfish mining' without the hashers being complicit in it)
04:09 < adam3us> gmaxwell: i guess would could impose some sanity eg reward < 50 as fees are << reward for now - no good thing can come.  i know someone could accidentally spend > 1btc fee but that is probably a mistake
04:10 < adam3us> gmaxwell: local submission could be good for that reason
04:10 < gmaxwell> adam3us: there are blocks with subsidy >> 50
04:10 < adam3us> gmaxwell: but surely thats a costly mistake rather than anything good
04:10 < gmaxwell> I think the record holder is something like 350 or something like that.
04:10 < maaku> people have accidentally spent 100's btc fees
04:11 < adam3us> maaku: right, but its a mistake - you could usefully declare such transactions invalid (some simple heuristic)
04:11 < gmaxwell> in any case, limiting inflation to 25 BTC from space doesn't really help that much. Esp since you can create inflation against spv clients simply by spending inputs that never existed.
04:11 < maaku> adam3us: does it matter? if you don't claim it some other pool will
04:11 < adam3us> maaku: as i understand it miners were gracious enough to refund it, but they would not have to
04:12 < maaku> at least if you claim it you can be kind and offer it back
04:12 < adam3us> maaku: well if its invalid its not even forwarded, your client should reject even sending it - mistakes were people lose large amounts of money are not good
04:14 < adam3us> see its an interesting thing - many people have views and things to say in support of decentralization - maybe there are simple things that could be done to support decentralization (like get users to chose their own block) while using pools to even out luck; or just encourage p2pool if it can take the load
04:15 < gmaxwell> adam3us: well thats the "coinbase only pooling"— user chooses their own block, pooling only for the payment.  But it needs some software work: A new GBT extension to say "send me only a coinbase", miner support to merge work from two sources, and poolserver work to accept shares.  ... plus its becoming increasingly hard to get miners to even run bitcoind/bitcoin-qt
04:17 < gmaxwell> (at least coinbase only mining would decouple the choice of policy with choice of income-pooling, even in a world where hashers were still blindly handing over their votes to quasianonymous parties on the internet)
04:17 < adam3us> gmaxwell: that latter thing i was thinking could be combated without a full node, eg get people to get a coinbase feed from somone else (anyone other than a pool)
04:19 < adam3us> gmaxwell: in principle picking a coinbase at random from non-pool entities could be better, though that is sybil attackable.  eg why not pick one from a power user you know who is running a full node, thats far better than trusting a pool; and also i like encouraging that the client locally submit to disrupt selfish stuff
04:19 < gmaxwell> it could be, yes, it's still handing over control... but without the barriers to entry where we seem to always have a mining oligarchy due to the obvious improvements to variance from being with a large pool in a world where miners really have few objective things to guide their decisions.
04:19 < adam3us> gmaxwell: i wonder if people like pools like a form of team-play, leaderboard thing
04:20 < gmaxwell> yes, to some extent, though I think that has mostly passed. It was certantly a big thing in the pre-asic times.
04:22 < gmaxwell> adam3us: I think that a lot of the hashers are basically just "mental bandwidth limited" are are picking "safe" popular choices, and that why you see them paying remarkably high fees. But I'm guessing. No one is studying this... and I'm not sure how you'd go about doing it.
04:22 < adam3us> was there ever a conclusion to cex.io investigation of the double spend attack?
04:22 < gmaxwell> adam3us: they said they'd look into it, no further comments. Subsiquently ghash.io dropped their fees from 3% to 0%.
04:22 < adam3us> (on the satoshi-dice clone)
04:23 < gmaxwell> Just keeping up with the hardware vendors, — new products and which thing is the scam of the week— could easily be a full time job.
04:25 < gmaxwell> (and ghash.io is the largest pool now, with 27.23% of the hashpower, though its impossible to know how much of that is actually public miners vs just cex itself, or how much of CEX mining power is "owned" by the public, vs internally owned)
04:26 < gmaxwell> In other news, 50btc still claims to have 3.2TH/s, and I think they stopped paying people over two months ago now.
04:27 < adam3us> gmaxwell: so cex.io is both a hosted mining (with public ownership or lease) and a publicly accessible pool?
04:27 < adam3us> gmaxwell: 50btc LOL ha ha
04:28 < gmaxwell> Yea, so the same party owns cex.io and ghash.io. Ghash.io is their mining pool which is available to the public (via a somewhat unfriendly registration process that involves making a cex.io account)
04:29 < adam3us> gmaxwell: bitcoin .. like swift, but where half federated nodes are run by people who dont care, dont read instructions, dont update software
04:30 < gmaxwell> cex.io is a large initially privately owned mining farm, which then created a trading market for selling hashpower to the public (and allowing the public to trade the hashpower between each other). In theory you can pay CEX to derack your hashpower and send you hardware, I'm not aware of anyone having done this. All cex.io hashpower is pointed at ghash.io.
04:31 < gmaxwell> adam3us: they might have cared but they just got scammed by three hardware vendors and are too busy rebooting their rasberry pis and praying that they'll break even.
04:31 < adam3us> gmaxwell: i am just thinking one could separate the luck pooling from the vote pooling.  then any big players keen to disavow centralization could show statistics of where the vote is being used
04:32 < gmaxwell> adam3us: yes, thats the idea behing the "coinbase only pooling" I mentioned before. It's technically simple, just needs some software development, and perhaps some bludgoning to convince pool ops that they should support it, and miners that they should use it.
04:32 < adam3us> gmaxwell: so terminology coinbase = the pools reward address?
04:33 < warren> adam3us: coinbase tx pays out to any defined address(es)
04:33 < gmaxwell> Coinbase being the reward transaction.
04:33 < adam3us> gmaxwell, warren: ok
04:34 < warren> adam3us: I think only eligius and p2pool payout directly to miners in coinbase tx
04:34 < gmaxwell> The idea is that the pool would just give you the transaction (plus flags for which modifications you were allowed to make to it), and you'd submit shares back.
04:34 < gmaxwell> Other pools have in the past, I'm not sure if any others do right now.
04:35 < adam3us> gmaxwell: well my way of thinking is to be aghast that the pool thinks it has any say - ie the block should contain the pools reward addr (the coinbase) and the rest should be chosen freely by the miner :)
04:36 < warren> gmaxwell: did you already mention the huge coinbase tx issue?
04:36 < gmaxwell> sure, and it could have been that way today, except no one thought of it in 2010. ... back then the example protocol was getwork.
04:36 < adam3us> gmaxwell: i guess its a transfer of the hashcash logic - the coinbase is the resource address, the rest is miner chosen
04:37 < gmaxwell> And a lot of miners— even pool operators— have only a very limited understanding of how this stuff actually works, so the idea that you could split up the decisions from the payment pooling was not obvious to people.
04:37 < adam3us> *** depressing state of affairs, tolerated with cynical dark humor by all
04:37 < gmaxwell> (or that you could make decenteralized pools)
04:37 < gmaxwell> and now we have intertia _plus_ centeralized systems are always easier.
04:39 < adam3us> i wonder if there could be an engineered dis-economy of scale, just enough to disrupt stupidity, centralized
04:39 < gmaxwell> adam3us: Well there is amiller's anti-cloud-hashing idea, but it's a bit rocket sciency, both economically and technically.
04:40 < adam3us> gmaxwell: it didnt quite work also if i recall
04:40 < nsh> (also in the sense that it uses rocket engines)
04:41 < gmaxwell> Amiller suggests that if the network would accept instead of a block you submit a zero knoweldge proof that you know of a block at this position and would like to instead pay some other address. .. so anyone running a miner can trivially steal solutions.
04:42 < gmaxwell> I think it would "work" ... but it runs into problems like right now people happily give money to cloud hasing places without any evidence at all that the cloud place isn't robbing them blind.
04:42 < adam3us> gmaxwell: i wonder if momentum could work (the proof of work based on birthday collisions) we laughed at its failures but perhaps it is fixable
04:43 < adam3us> gmaxwell: seemingly a defacto proof that technical approaches have limited effect on the stupid or careless shall we say
04:43 < gmaxwell> e.g. amiller's design would totally kill pooled mining, with a possible outcome of all hashing being cloud hashing... because at least a huge centeralzied place has a reputation to protect.
04:47 < adam3us> so about momentum briefly. i could find no proper description of it but basically the idea is the entries in the memory table are themselves small proofs of work (25-bit?), and then the task is to find H(a)=H(b) and finally H(a,b) < target now i think the thing is the target is high enough that memory is filled quickly
04:47 < adam3us> (though i see no reason restricting memory)
04:47 < adam3us> otherwise it suffers from quadratic advantage in fast cpu & ram
04:48 < adam3us> as well as compact storage
04:48 < adam3us> (eg lossy storage like bloom filter to do a tmto to fit it into a gpu)
04:48 < gmaxwell> I'm not sure how this helps anything. I follow that you can probably set the parameters so that it doesn't create an advantage for being a larger hasher.
04:49 < gmaxwell> we had big farms with gpus, amd is now raising their gpu prices due to litecoin. I don't think hardware selection saves you from consolidations, being worthless does. :P
04:49 < adam3us> gmaxwell: amiller's thing might be easy to make work no?  as i recall we were talking about eg chameleon hash so the miner can chose after the fact what the reward address is
04:50 < adam3us> gmaxwell: yes probably no diff from that perspective
04:51 < adam3us> gmaxwell: it might be hard to pool two fast computers super-linearly with momentum because of latency and bandwidth of ethernet vs ram, however simpler proof of work doesnt have that problem to start with
04:52 < gmaxwell> adam3us: I think it's tricker than that, because you can't have people going and replacing 'ordinary blocks' later. ... but regardless, as I mentioned above, I don't think it helps even if its easier because while it would kill pooled mining completely dead, people would still cloud mine... and without pooling they'd probably only cloud mine.
04:52 < adam3us> gmaxwell: in principle a fixed momentum could be a memory hard proof of work, but with no memory to verify.  verification is h(a)=?h(b) mod 2^k, and h(a,b)<target
04:53 < gmaxwell> The way all the popular pools today (excepting p2pool) work their operators could be easilly skimming a couple extra percent from users nearly undetectably in any case... and few care (as measured by the p2pool hashrate).
04:53 < adam3us> gmaxwell: yes and cloud mining is in many ways worse - even if he user is independent, the hosting provider can comply with court orders to tamper and not tell user (gag on top)
04:54 < gmaxwell> or it could all be going along in a lovely way ... until it isn't and all the hardware has been handed over to someone else.
04:54 < adam3us> gmaxwell: i am having a "if they dont care" make some technical approach to make them care moment - eg hack them, or make them easier to hack
04:54 < adam3us> we are lacking a disincentive to idiocy motivator
04:55 < gmaxwell> well, I don't have anything to offer, in darker moments I've mused that the only "fix" is to go out and run dishonest pools and mining companies and just rip people off—  ... but even there, that doesn't work: it's already been done and here we are.
04:56 < gmaxwell> I suppose that in the limit, with enough theft, people will eventually clue up or go broke... but a little doesn't appear to be enough.
04:57 < adam3us> gmaxwell: anyway something useful from this discussion, it seems there is scope within coinbase only eg gbt extension to give people who do care something they can do using existing pools; though why they would not use p2pool already is a mystery (if it really does scale)
04:57 < gmaxwell> as I mentioned before, 50btc is eating all coins, and it still has non-trivial hashpower. People even show up on IRC asking about it from time to time... I went and updated the wiki page the last time someone showed up in #bitcoin-mining asking about using it: https://en.bitcoin.it/wiki/Comparison_of_mining_pools
04:58 < adam3us> gmaxwell: LOL pps fee=100%, 1.8TH ha ha ha
04:59 < gmaxwell> adam3us: p2pool scales but has some tradeoffs in the payment mechensim / variance.  ... at least right now it 'scales' by keeping the pool-wide share rate to 1 share per 30 seconds. Which means that if you're a "small" miner, e.g. 60gh/s you're only getting a couple shares a day, and not getting paid in every block.  So higher variance than you would get mining at eligius.
05:01 < gmaxwell> Personally I think people worry too much about variance— if you're getting paid multiple times a week— meh, nothing bad will happen.  But its a much more visible thing to miners than things like the risk of a pool attacking the network or skimming an extra 1% on top of their 3% stated fees.
05:02 < gmaxwell> plus you have to run p2pool which adds an extra 500MB memory and 2kB/s of network traffic, on top of running a full node.  Coinbase-only could let you have more payment pooling flexibility, and potentially outsource the full node running to a third party (distinct from the pool)
05:03 < adam3us> gmaxwell: according to 50btc.com it has 3.26 TH i guess its not so much only $1670/day
05:04 < adam3us> gmaxwell: i do like stuff Luke-Jr does.  like down prioritizing reused address and other fun.  would happily delegate vote to him
05:05 < gmaxwell> yea "only" $1670/day.   "I'm in the wrong business" when you could just run a pool for a bit then stop paying people and recieve $1670/_day_. :P
05:05 < adam3us> gmaxwell: of couse he already has 12%
05:06 < hno> gmaxwell, I would hope it declines rapidly if trying to pull that off.
05:06 < gmaxwell> yea, thats a somewhat recent event.
05:06 < gmaxwell> hno: they stopped paying over two months ago. It did decline rapidly, but it seems like it's taking a loooong time to die completely.
05:07 < gmaxwell> there are people who lost >100 btc in accrued funds on the pool.
05:07 < hno> right, that pool...
05:08 < adam3us> gmaxwell: $600k/year :) seems odd - their own stats show their % nosedivided from 122TH in oct to 3TH now.  even so they had 3% fee so 3% of 122 > 100% of 3.26 (just) seems more like bitrot- but why bitrot something paying high income? weird
05:08 < gmaxwell> basically every major pool has been hacked at some point, except eligius.  (and maybe except ghash.io, but I'm actually not sure there)
05:10 < gmaxwell> adam3us: well they were losing their position due to growth of cex hashrate. ... now, they claim to have been "hacked" so it may not have been a choice,  but otherwise 100% of 3TH _plus_ hundreds of btc in balances  vs 3% of 122 with prospects of rapid declines in the share of the total...
05:10 < hno> same rule as always.. keeping funds online / at control of others (not sure there is a distiction between those two) is high risk.
05:12 < adam3us> gmaxwell: but it seems bizarre - hacked and locked out and hackers just left it that way? didnt care?  "hacked" ie they took their own funds and pretended it was a hack and moved onto other projects
05:12 < gmaxwell> I, personally, think the latter is fairly likely.. but the pool was basically always very absentee-operated. E.g. lost a whole bunch of blocks when p2sh was deployed because they hadn't updated.
05:15 < gmaxwell> The way it played out is that they were "hacked" and then didn't respond at all for two weeks. The 'hackers' scrambled up everyone's balances and ran off with all they could. it's since been locked down and there is apparently some story about some randsom for the balance data.
05:16 < adam3us> eligius approach for immediate payout in the coinbase is more sensible, then miners can validate their address is in the coinbase and central theft risk is largely avoided
05:17 < gmaxwell> not completely, since it could be live stolen, — e.g. hack in and make it pay any found blocks to the attacker until someone notices.
05:18 < gmaxwell> but there are independant people running sanity checkers on the eligius coinbases.
05:18 < gmaxwell> and the operators phone numbers are on the website and irc channel, so its unlikely that would last long
05:30 < maaku> adam3us: how do you distribute mining fees if the pool doesn't select transactions?
05:32 < maaku> gah, tx fees
05:33 < gmaxwell> maaku: pretty straight forward, you report the fees in your shares submitted to the pool, and the pool does some proportional thing for at least the fees portion of the payout.
05:36 < maaku> gmaxwell: so you pass fees as a parameter to gbt? i guess that can work
08:43  * andytoshi-logbot is logging
08:57 < andytoshi> nOgAnOo: http://download.wpsoftware.net/bitcoin/wizards/
08:57 < andytoshi> i should probably have the logbot announce that url..
09:11 < michagogo|cloud> andytoshi: Note that freenode policy is that public logs of a channel need to be authorized by channel operators, and all users need to be made aware (the suggested method is a note in the topic)
09:12 < michagogo|cloud> (chanserv says that the only op in here is mindspillage... no idea who that is)
09:16 < michagogo|cloud> Google (and NickServ's listing of the cloak on the account) suggests it's someone named Kat Walsh, a former chair of the Wikimedia Foundation and attorney for Creative Commons
09:17 < michagogo|cloud> Still no idea who this person is and why she registered this channel...
09:18 < pigeons> michagogo|cloud: someone in this channel is very close to her
09:19 < pigeons> i've seen him use her irc account, as can sometimes happen when you share machines with someone
09:19 < michagogo|cloud> Ahhhhhh
09:19 < michagogo|cloud> A google search for (mindspillage OR "kat walsh") bitcoin
09:20 < michagogo|cloud> turns up http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/03/03
09:20 < michagogo|cloud> Hi Greg :-)
09:20 < michagogo|cloud> Gregory Maxwell (greg@wikimedia/KatWalsh/x-0001) is authed as mindspillage
09:21 < michagogo|cloud> They share a NickServ account? o_O
09:23 < michagogo|cloud> ;;later tell gmaxwell I noticed http://en.wikipedia.org/wiki/User:Gmaxwell has an outdated version of your pgp key... missing 2 UIDs, 2 subkeys, and 158 signatures
09:23 < gribble> The operation succeeded.
09:27 < andytoshi> michagogo|cloud: thx
09:30 < andytoshi> ;;later tell gmaxwell freenode policy is that i notify a channel op before running andytoshi-logbot, and that the log url ( http://download.wpsoftware.net/bitcoin/wizards/ ) wind up in the channel topic
09:30 < gribble> The operation succeeded.
09:31 < michagogo|cloud> andytoshi: s/notify/ask permission from/
09:31 < andytoshi> oh :)
09:32 < andytoshi> if anyone has a problem, i will take it down -- but i have mentioned to gmaxwell that i'm running this log bot before
09:33 < michagogo|cloud> andytoshi: It's actually in the motd
09:33 < michagogo|cloud> - We would like to remind you that unauthorised public logging of channels on the network is prohibited. Public channel logging should only take place where the channel owner(s) has requested this and users of the channel are all made aware (if you are publically logging your channel, you may wish to  keep a notice in the topic and perhaps as an on-join
09:33 < michagogo|cloud> message).
09:33 < michagogo|cloud> (minus a few line breaks)
09:34 < andytoshi> yeah, i see it now
09:35 < andytoshi> i'll stop publishing the logs until i get an ack from someone
09:38 < michagogo|cloud> andytoshi: At the moment, it's not "someone", it's greg
09:39 < michagogo|cloud> (or jgarzik, if he decides that he wants to get freenode staff to op him in here)
09:53 < andytoshi> michagogo|cloud: did you get my message late last night, saying i fixed the donation address thing with the coinjoiner?
09:53 < andytoshi> http://testing.wpsoftware.net/coinjoin/sign.php?session=b3b098642a36f1aa62a333f5a15a6e98a04dfb7622e4eb3dd74f3d706f149d7b
09:53 < michagogo|cloud> I signed and submitted
09:54 < michagogo|cloud> (earlier, when I saw that)
09:55 < andytoshi> hmm, i'm pretty sure i did as well
09:55 < andytoshi> i re-submitted just in case, otherwise i've got a new bug :(
10:00 < michagogo|cloud> just resubmitted just in case
10:01 < andytoshi> thx
10:01 < andytoshi> it looks like all the signatures are in the database, if it's not working then there's a merging problem
10:11 < michagogo|cloud> andytoshi: any luck?
10:14 < andytoshi> michagogo|cloud: yeah, the outputs are subtly different for what i signed and what you signed
10:14 < andytoshi> like, the scriptpubkeys have slightly different hex
10:15 < andytoshi> but, the DB shouldn't have accepted any such discrepancies, so i'm not sure (a) how this could even happen or (b) how it got through the site's input filter
10:16 < andytoshi> i signed 76a9143312004af0b4d2323676e488ae6900c9cb3b38c888ac:10000000
10:16 < andytoshi> u signed 76a9148c04bfe5e2a91b609b92d4f7af6cadda9d1e47e088ac:10000000
10:16 < andytoshi> oh, those are actually completely different..
10:17 < andytoshi> what i wrote there is scriptPubKey:nValue
10:21 < andytoshi> ok, this is embarassing ... i changed the output of coinjoin a few days ago, and i updated the PHP code to check errors correctly when validating unsigned transactions
10:22 < andytoshi> but forgot to update the code which validted signed transactions
10:26 < andytosh1> you submitted a signed transaction that didn't match the one offered by the site (probably because you re-submitted your signed transaction from last time, but this is a new session so the inputs/outputs got reordered)
10:26 < michagogo|cloud> I did?
10:27 < andytosh1> it appears so, yeah
10:27 < andytosh1> one moment, i'll clear out the signed transactions from the db and we can both resubmit
10:27 < andytosh1> done
10:27 < andytosh1> oops, i have to put the seed one back :P
10:29 < andytosh1> ok, can you try again?
10:31 < michagogo|cloud> done
10:32 < michagogo|cloud> andytosh1: submitted
10:33 < andytosh1> thx, got yours
10:34 < andytosh1> seems like it did not get mine..
10:40 < andytosh1> ok, now the one that i submitted, bitcoind cannot decode :} but again, php is accepting it..
10:45 < andytoshi> awesome, it went through :) tx d08ed6edab38bbd80eb96739777b096ccc654f5a1c398baeeaa11355b6d75bd6
10:45 < andytoshi> thanks a ton for testing, i'm glad we had so much bad input
11:02 < jgarzik> hrm
11:03 < jgarzik> Has anyone worked on a script form that does "<multisig> AND <multisig>"?
11:03 < jgarzik> OP_AND is disabled
11:19 < nsh> HULK SPLIT!
11:24 < gmaxwell> jgarzik: works for true false, also you can do that with OP_IF, or with just two CHECKMULTISIG VERIFY in a row
13:01 < jgarzik> gmaxwell, I was thinking "if multisig then multisig else false endif".  Two multisig in a row should work too...
17:33 < andytoshi> if i want to update my joiner to use blinded addresses, what user tools (if any) exist for this?
17:34 < andytoshi> if i write some, what papers should i read re implementing the crypto?
17:37 < nsh> andytoshi, what are blinded addresses?
17:37 < andytoshi> nsh: https://en.wikipedia.org/wiki/Blind_signature is a good overview
17:37 < nsh> chaum's blind sigs?
17:37 < andytoshi> yeah
17:37 < nsh> kk, reading
17:37 < gmaxwell> andytoshi: see maaku's git repo.
17:37 < andytoshi> cool, thx
17:38 < gmaxwell> (He implemented RSA blind signatures for this stuff)
17:45 < andytoshi> he has, for example, in the function _pad_message "REVIEW: I need a professional cryptographer...Does it matter in this particular applicaiton if the padding is deterministic instead of random?"
17:45 < andytoshi> if there are any professional cryptographers on here, i am curious too :)
18:25 < maaku> i asked that of gmaxwell iirc, and no it doesn't matter
18:25 < maaku> but also, it doesn't matter if it is deterministic or not
18:25 < maaku> the protocol changed a bit since I wrote that
18:40 < nsh> maaku, issue that springs to mind is that blind signing is insecure if the keys are also used to encrypt, which is generally not (so far, to my knowledge) the case with bitcoin privkeys, but worthy of consideration nevertheless
18:41 < maaku> coinjoin keys are ephemeral RSA keys used for that join only
18:41 < nsh> ah
18:42 < maaku> although I would prefer schnorr ec blind signatures using one of djb's curves, if someone went through the trouble of working out how to do that
18:43 < maaku> but yeah, throwaway keys on a different curve, so not much danger of that
18:43  * nsh nods
18:43 < maaku> i just wasn't sure if deterministic padding weakened the signature or otherwise led to any sort of attack
18:44 < gmaxwell> maaku: funny, I was going to make a comment to that effect;  "if you feel like implementing something, blind schnorr would probably be better"
18:44  * nsh reads http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html
18:46 < maaku> all the pieces are there, I think, but I wouldn't trust myself to put them together
18:46 < maaku> I'm an informed user of crypographic systems, not an experienced practitioner of the art
18:47 < maaku> but RSA is hard to f@&# up
18:48 < gmaxwell> Hm? ha. Thats exactly the opposite of my view.
18:48 < jrmithdobbs> rsa is pretty easy to fuckup
18:48 < gmaxwell> RSA is pretty easy to F^$%# up and EC systems tend to be harder— in general.
18:48 < jrmithdobbs> especially if you have to write it for multiple different hw platforms or runtime environments
18:48 < gmaxwell> "Oh you thought you were signing? HAH No. You were decrypting things for me. Sucks to be you!"
18:48 < maaku> i meant not implement correctly -- fewer moving parts with rsa
18:48 < jrmithdobbs> ya
18:49 < jrmithdobbs> that ya was to gmaxwell's comment
18:50 < jrmithdobbs> maaku: a lot of the errors you can make implementing rsa are less immediately obvious but more completely destructive to the security of your protocol/use
18:50 < maaku> jrmithdobbs: i'm aware
18:50 < gmaxwell> maaku: well fair enough, though once you have the primitives already
18:50 < andytoshi> i'd be interested in looking at schnorr signatures, i've got a few papers about them backlogged
18:52 < maaku> gmaxwell: yeah that's what i'm saying - i don't trust myself to modify djb's sources to do schnorr blind sig and trust that it actually *is* correct signature primatives
18:53 < maaku> but if someone where to write that, it'd be easier and safer to integrate into coinjoin implementations (and faster, and higher secuirty level .. really no downsides)
18:54 < gmaxwell> maaku: well I believe that no changes are required in the validator, so that should help gain confidence that its correct.
18:55 < gmaxwell> e.g. it should just need a blind/unblind/and blindsign function (and the latter only because the normal signing functions do the hash internally).. and the result should be verifyable with an unmodified code.
19:02 < adam3us> maaku: i might be persuaded to try that (EdDSA ==EC Schnorr blind sig)
--- Log closed Tue Dec 17 00:00:02 2013