01:14:08kanzure:"Program synthesis in reverse engineering" http://www.nosuchcon.org/talks/2014/D1_01_Rolf_Rolles_Program_Synthesis_in_reverse_Engineering.pdf
06:07:30kanzure:"Synthesis of masking countermeasures against side channel attacks" http://www.ece.vt.edu/chaowang/pubDOC/EldibW14CAV.pdf
07:58:31Taek:If you use schnorr signatures, could you spend multiple outputs with a single signature?
07:58:49Taek:you'd take the pubkeys of each output and add them up, and then take each of the signatures and add those up
07:58:56sipa:no
07:59:16Taek:where's my misunderstanding?
07:59:19sipa:the receiver could choose a pubkey that is the inverse of the sum of some other destinations
07:59:26sipa:cancelling their key out
08:01:36Taek:oh. Thanks
08:02:16sipa:what you can do is batch validation
08:02:27sipa:which adds the validity equations for each signature up
08:02:50sipa:with a validation-time random factor
08:03:11sipa:but that does mean you need a per-entry signature in the data structure still
08:03:21sipa:as you can't let the signer decide on the factors
08:03:33Taek:but verification is faster?
08:03:37sipa:yes
08:03:45sipa:a bit over twice as fast
08:06:19fluffypony:Pity about the name
08:06:33sipa:?
08:06:45fluffypony:Schnorr
08:06:51sipa:why?
08:07:01brisque:lamport signatures sound cooler.
08:07:16fluffypony:I struggle to say it with a straight face
08:07:26brisque:Blum Blum Shub is worse
08:07:39fluffypony:Especially when you say it with a thick Afrikaans accent
08:07:49fluffypony:And roll the r's
08:08:05brisque:BBS is still worse.
08:08:24fluffypony:Definitely
08:09:20fluffypony:I do enjoy the tongue twister that is Shamir's a Secret Sharing Scheme
08:09:27sipa:fluffypony: you need to invent a signature scheme
08:09:43fluffypony:fluffy signatures?
08:10:19Taek:ponysigs
08:10:41fluffypony:Spagni Signatures will be eternally mispronounced, except by Italians
08:10:46brisque:needs to be an agreement that all cryptographic concepts have ridiculous names. 'Super Fluff Fluff Pont Time"
08:10:59brisque:s/pont/pony/
08:11:02fluffypony:Hah hah brisque
08:12:01fluffypony:altcoins are way ahead of you on that with their Dark Gravity Well difficulty retarget algorithms
08:12:16brisque:Dark Gravity Wave, actually.
08:12:21Taek:Kimoto Gravity Well is a kickass name
08:12:30fluffypony:Omg, even better
08:12:52brisque:pity it's a terrible concept which basically breaks the proof of work entirely.
08:12:58fluffypony:So does Light Gravity Wave also behave like a particle?
08:13:08fluffypony:* fluffypony nerdjokes
08:13:17brisque:it means you can isolate a node and then feed it super low difficulty blocks after 30 minutes or something, and they'd never notice.
08:20:14fluffypony:Oh, sipa, I've added IPv6 support to the DNS seeder for use with Namecoin Core, would you like me to PR it upstream?
08:24:18sipa:sure
09:01:34Guyver2:Guyver2 has left #bitcoin-wizards
09:05:15hobana.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:15hobana.freenode.net:Users on #bitcoin-wizards: andy-logbot Dr-G2 Mably paveljanik lclc vmatekole hktud0 Cory p15_ Starduster_ jcorgan wallet42 toffoo justanotheruser zooko dc17523be3 damethos prodatalab koeppelmann sneak kinlo RoboTeddy d1ggy hashtagg_ waxwing forrestv huseby embicoin Guest2979 GreenIsMyPepper skyraider phantomcircuit jgarzik cryptowest BlueMatt Pan0ram1x coinrookie ryanxcharles p15x luny Emcy mkarrer melvster DougieBot5000 jaromil espes__ x98gvyn fanquake tromp_ dgenr8
09:05:15hobana.freenode.net:Users on #bitcoin-wizards: Apocalyptic PaulCapestany gwillen dasource jaekwon_ alferz bbrittain fenn nuke1989 GAit gribble c0rw1n hashtag_ amincd HM2 prepost shesek tromp ahmed_ eordano Logicwax nickler Alanius face PRab BananaLotus guruvan ryan-c MoALTz lnovy DoctorBTC adlai sipa harrow grandmaster Luke-Jr OneFixt amiller go1111111 ebfull cluckj brisque cfields sdaftuar veorq coryfields devrandom helo bosma Hunger- xabbix burcin runeks null_radix bedeho copumpkin
09:05:16hobana.freenode.net:Users on #bitcoin-wizards: gmaxwell SwedFTP LarsLarsen epscy nanotube binaryatrocity spinza andytoshi bliljerk101 wizkid057 starsoccer comboy nsh Taek iddo EasyAt maaku btcdrak NikolaiToryzin s1w Visheate crescendo livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc [d__d] berndj morcos Fistful_of_Coins dardasaba isis airbreather smooth ajweiss Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo Muis platinuum Oizopower Keefe
09:05:16hobana.freenode.net:Users on #bitcoin-wizards: catlasshrugged JonTitor petertodd kanzure eric mappum jbenet wiz midnightmagic heath gnusha warren Adrian_G Iriez lechuga_ dignork jessepollak Graet Eliel veox warptangent indolering K1773R TD-Linux leakypat CryptOprah Anduck a5m0 d9b4bef9 mr_burdell NeatBasis davout brand0 @ChanServ throughnothing btc___ azariah MRL-Relay hguux__ so phedny roasbeef BrainOverfl0w wumpus
09:05:16hobana.freenode.net:[freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
10:45:48gmaxwell:[OT] Latest subnormality is really good (http://www.viruscomix.com/page588.html), I often look with sadness on how our cultural works look on technology as sort of a recieved artifact, unaware of the enormors effort and care that goes into building the most banal detals, and the weight of the myriad small choices on those building the things.
11:13:12Taek:I wonder if that culture is one of the reason alcoins are so prevalent
11:13:19Taek:*altcoins
11:13:39Taek:people think you can just twist a few knobs and introduce a few features and it'll work just as well as the original plus have more features
11:14:41Taek:and they fail to appreciate how hard it was to get the knobs and feature set correct in the first place
11:17:57sipa:or specifically fail to recognize that lot of the design is to prevent against malicious or unintended incentives
11:18:25sipa:and not strictly necessary to function properly in a laboratory setting
11:20:03gmaxwell:At least no one is dying due to it... (we hope!) But yea, I've had thoughts along those lines. It's sad too, because there is great joy in craftsmanship too that we fail to share with people.
11:20:13fluffypony:Definitely, they pick magic numbers "intuitively" with little to no thought given to the consequences
11:22:29fluffypony:gmaxwell: I've been accused of being a perfectionist because stuff isn't rushed out haphazardly
11:22:37fluffypony:As if that's a bad thing
11:23:10fluffypony:But it's because of the culture of "fail fast, fall often" that has spilled over
11:24:01Taek:"fail fast, fail often" is very valuable advice when applied to the right places
11:24:10Taek:financial software just isn't one of them
11:24:11fluffypony:Yes
11:24:22fluffypony:Like a hipster startup:-P
14:23:14JoiIto:JoiIto is now known as JoiIto_
14:24:00JoiIto_:JoiIto_ is now known as joiito
14:52:41dgenr8:some good places to fail are during design and in the laboratory
14:52:57dgenr8:mix
14:52:59sipa:sure
14:53:13sipa:but they only tell you things about scenarios you thought of
14:59:15kanzure:http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/keynote-gavin-andresen/
15:01:27sipa:ugh, bip66 is not malleability :)
15:01:51sipa:bip62 is malleability, but that isn't implemented
15:11:24Luke-Jr:and it was know much longer than 1 year ..
15:12:05Luke-Jr:(but that was the question-asker)
15:25:12kanzure:http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/arvind-narayanan/
15:30:10dgenr8:sipa: agreed, so more "you", the better at these phases. collaborative spririt, you know
15:30:44sipa:dgenr8: sure, being open and experimenting is all fine
15:31:03sipa:dgenr8: i don't think anyone argues against that
15:31:25sipa:just the mentality of "it seems to work in practice, thus it's ready to ship" is very non-true in an adverserial setting
15:47:22kanzure:http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/andrew-miller/
15:49:33waxwing__:waxwing__ is now known as waxwing
16:18:42kanzure:http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/matt-corallo-sidechains/
16:53:29kanzure:BlueMatt: you are significantly easier to type than others :)
16:53:49kanzure:i think you choose sentence structure based on qwerty layout in your head, that's the only explanation
17:04:17heath:anyone have a link to the smartcolors library?
17:04:54heath:https://www.reddit.com/r/Bitcoin/comments/2pt4kl/reddit_announces_reddit_notes_aka_reddit_bitcoin/cn06h17 for reference
17:13:48kanzure:not using testnet during a demonstration is reckless. "nah let's just use mainnet. that's best practice, right?"
18:14:30kanzure:http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/zerocash-and-zero-knowledge-succint-arguments-of-knowledge-libsnark/
18:16:57heath:petertodd: is the smartcolors lib available yet?
18:17:18heath:if i had known the mit btc conf was going on, i would have stayed just a few more days!
18:32:51petertodd:heath: client still hasn't given the ok, but it will be, equally if you want to use it for osmething just email me and I'll give you access
19:32:26kanzure:http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/peter-todd-scalability/
20:45:05amiller:random_walker said that mulltisig proliferation is awfully low, like 1% at its peak... petertodd said it's like 8%, im trying to figure out what the deal is
20:45:46amiller:its possible to imagine counting by number of transactions (containing a multisig), number of utxos, or number of multisig'ed bitcoins
20:46:23brisque:amiller: http://p2sh.info/
20:47:09kanzure:there was p2sh.info a while back
20:47:16kanzure:damn how did brisque beat me
20:47:39brisque:kanzure: lets pretend freenode goofed and the comments happened simultaneously.
20:47:55kanzure:okay :)
21:27:59arubi__:arubi__ is now known as arubi
21:31:12Eliel:amiller: From the looks of it, soon it might not even be possible to count who users multisig and who doesn't. https://freedom-to-tinker.com/blog/stevenag/threshold-signatures-for-bitcoin-wallets-are-finally-here/
21:31:55Eliel:... ok, I fail bad at english grammar here :P
21:32:29kanzure:if you mean "count" as in "count from blockchain data", that may already be impossible since the blockchain does not record users
21:32:42kanzure:although you may be able to make up lower and upper bounds on estimation
21:33:53Eliel:kanzure: anyway, there's someone claiming to have created a multisig system that looks like a traditional bitcoin transaction to outside observers.
21:34:18kanzure:yep
21:34:29kanzure:see my transcript here http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/arvind-narayanan/
21:36:00brisque:is this the same one that was announced a while ago and was revoked for having some cryptographic flaws?
21:36:06brisque:(an improvement of it, I mean)
21:36:20kanzure:i hope not. i would expect that to have been mentioned.
21:36:42amiller:uh, yeah it is that same thing but an improved version of it
21:37:48amiller:https://freedom-to-tinker.com/blog/stevenag/threshold-signatures-and-bitcoin-wallet-security-a-menu-of-options/ he talks about the improvements and the prior problems here
21:38:35moa:amiller: what did you think? seems interesting enough
21:38:46gmaxwell:The scheme turns out to require a trusted dealer, which I think mostly only makes it interesting in contrived situations.
21:39:07amiller:gmaxwell, that's gone now, that's been gone since may last year
21:39:10amiller:see above post
21:39:29kanzure:gmaxwell: from the snarks territory were you already aware that they had dropped trusted setup? http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/zerocash-and-zero-knowledge-succint-arguments-of-knowledge-libsnark/
21:40:12amiller:kanzure, to be clear the libsnark multi-party setup is something we've talkeda bout before as an option too, but the libsnark crypotgrapers worked out a customized efficient protocol for it
21:41:32kanzure:hm.
21:41:47kanzure:i need "diff vision" goggles for these talks.
21:41:52gmaxwell:amiller: There was another option that required a surplus of signers (beyond the information theoretic bound), which was again also lame.
21:42:16gmaxwell:(and then they also waved their hands and say you could use a generic MPC scheme, well duh.)
21:42:40amiller:in that May 2014 post i linked above, they have a table that summarizes all of this
21:42:56kanzure:oh you're right actually, they overly stated their claim about not requiring trusted setup
21:43:05kanzure:"Another way around trusted setup is using MPC, but this is a topic for a different talk" <-- multiparty computation
21:43:22kanzure:"The trusted setup limitation can be removed, and I am going to talk about that later in the talk." i guess this didn't hpapen
21:43:23amiller:no you misheard bro
21:43:33amiller:they said another way around trusted stup is using PCP (probablistically checkable proofs)
21:43:42amiller:those are a topic for a diff. talk because they're ridiculous expensive for the prover
21:43:42kanzure:damn
21:43:48brisque:"For Bitcoin, multisig is good but it has drawbacks like it destroys anonymity and it forces you to display your security on the blockchain." ugh.
21:43:51kanzure:thank you
21:44:19amiller:lol if you're taking transcript requests, i noticed in todd's talk you wrote PACKSAUCE or something instead of paxos :p
21:44:20gmaxwell:amiller: Yes, so-- original scheme that requires a trusted setup, OR you get something that requires extra signers beyond the information theoretic bound, or you get 2 of 2 only and they aren't even sure it can be applied to ECDSA (people in bitcoin space had previously published a two of two scheme, though it's only single use), or you get MPC.
21:44:36kanzure:amiller: btw this is actually a git repo, just git clone
21:44:52amiller:kanzure, k thx
21:45:10kanzure:that said, both things are fixed now
21:45:22amiller:gmaxwell, i'm not sure how to interpret this table with two rows, for gennaro (2t-1)-n and gennaro t-1
21:45:57andytoshi:the "single use" scheme is the one with pallier encryption?
21:46:00gmaxwell:kanzure: Using MPC is _not_ removing trusted setup. (the PCP based schemes if made pratical would be neat but the proofs are much larger, and I believe it's not possible to make it have perfect zero knoweldge)
21:46:16kanzure:yeah i think i need to just attach -wizards logs to the end of these files
21:46:28amiller:https://freedom-to-tinker.com/blog/stevenag/threshold-signatures-for-bitcoin-wallets-are-finally-here/ this is the newest blog post btw on it, i think this hasn't been pasted here yet
21:47:01kanzure:Eliel pasted that about 15 minutes ago :)
21:47:58amiller:gmaxwell, MPC with *any 1 out of N* needs to be honest/uncompromised, with efficiency enough to have a large N, is pretty good though
21:48:13amiller:but yeah it's defnitely not the same as 'no trusted setup' either
21:50:45waxwing:ok so reading here i wasn't crazy, it did seem really weird to use exotic stuff like paillier homomorphisms and then at the end say 'oh just run a live disk image on your desktop, it's trusted'.
21:52:03brisque:I was thrown by the comment about keeping bitcoin anonymous by not revealing you're using multisig. in terms of privacy that's the least of your worries.
21:52:11gmaxwell:amiller: yea, indeed. doubly so if you can prevent participants from jamming it.
21:52:41gmaxwell:brisque: I dunno about that; it stinks that using multisig puts you in a different anonymity set.
21:53:28gmaxwell:But, sadly, it seems that accountable multisig and private multisig are at least somewhat incompatible. And accountable multisig seems to be very important (turns out people want to know which of their keys were compromised if something bad happens).
21:54:29brisque:gmaxwell: half the time just using a different client does that too. it reminds me a lot of the alt.anonymous.messages group, where everything seemed to be pretty much the same but almost all messages were revealed by subtle differences in the implementations of the clients people used. ( reference https://ritter.vg/p/AAM-defcon13.pdf )
21:54:43kanzure:hmm i wonder if key compromise can be made more obvious in the alternative scenario
21:56:14kanzure:well, you could always leave some bitcoin around that can be spent by that private key i guess, but your attacker may not care about that particular stash
21:56:28gmaxwell:I have an efficient schnorr signature scheme which can be indistinguishable from 1 of 1 if all the signers participate, and accountable otherwise... which seems pretty good to me.
21:57:40andytoshi:gmaxwell: does everyone have to know the message to "participate"?
21:58:07gmaxwell:kanzure: we've seen with brainwallets that attackers in practice already do smart things, even in competition with each other, to avoid getting detected for better payoffs. Esp since for accountability, you've split your key between {you, service provider, your backup (which the service provider also has a crackable copy of} .. you _really_ want there to exist transferable proof if the service p
21:58:13gmaxwell:rovider screws you over.
21:59:41gmaxwell:andytoshi: yes, well hash of it. I'm just referring to polysig with hashtree encoding of the coefficients, so you can hide all but 1+(n-non_signers) of them and hide their count.
22:00:45gmaxwell:(though on that point with a MAST like script even just N of N or N of M. is sufficient to get an indistinguishability from 1 of 1 in the case where all are available to sign.
22:01:10kanzure:also, we got a question into the conference to ask "why do you recommend not using bitcoind?" (which was interpreted as "not use bitcoin" at first -_-), and the answer back was "because private key management" :/
22:06:26gmaxwell:WHY DOES THIS N of M scheme have Paillier code?!?#! https://freedom-to-tinker.com/blog/stevenag/threshold-signatures-for-bitcoin-wallets-are-finally-here/
22:07:58gmaxwell:anyone have a link to the new paper they seem to be mentioning in that post?
22:08:50andytoshi:kanzure: :/ i'm sympathetic to that ... though obvs no to a "don't use bitcoind" extent ... this is a -dev thing but i think the default keypool size should be closer to 10000 than to 100
22:08:54gmaxwell:oh duh first link.
22:09:43brisque:andytoshi: that said, there's something to be said for avoiding half measures
22:10:36andytoshi:brisque: well something like bip32 has its own problems which are even harder to explain to users than "your backups invisibly expire". if there was a clearly total solution i think it'd have been implemented
22:11:07andytoshi:lol is http://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf being slashdotted?
22:12:30brisque:andytoshi: https://webcache.googleusercontent.com/search?q=cache:THbcH32NFtAJ:www.cs.princeton.edu/~stevenag/threshold_sigs.pdf+&cd=1&hl=nl
22:13:18gmaxwell:bleh 3t-2 rounds of interaction.
22:13:20brisque:I don't imagine that server is particular well provisioned
22:24:31waxwing:gmaxwell: something wrong with Paillier specifically? they just need an additive homomorphism, right.
22:25:15gmaxwell:waxwing: it's a huge amount of additional complexity. E.g. zero probablity of adding this to libsecp256k1.
22:25:26waxwing:right
22:26:04gmaxwell:and it's a whole additional orthorgonal set of cryptographic assumptions.
22:26:08waxwing:i was a bit taken aback to see both Paillier and ZKP in there
22:27:14gmaxwell:the code doesn't seem to include anything for dealerless establishment of the paillier keys, unless I'm missing it. (I know it can be done.)
22:27:57waxwing:refs 21-23 in the doc. exercise for the reader maybe :)
22:30:07gmaxwell:I wish I could really convince them that w/ dealer setup is uninteresting.
22:30:59kanzure:andytoshi: even if you don't use bitcoind for key management there are many good and important reasons to be running it, these companies should not be recommending no bitcoind
22:31:31kanzure:this is to the level where it may be appropriate to say this is actively harmful
22:32:12gmaxwell:kanzure: were they any more clear about what they mean by "key management"?
22:32:25kanzure:well they wanted you to use their api for multisig
22:32:34kanzure:so therefore don't install bitcoind and don't develop with bitcind
22:32:36kanzure:*bitcoind
22:33:09gmaxwell:So that argument wouldn't be removed by anything short of integrating third party mediated multisig?
22:33:10kanzure:(also they were using mainnet in a live demo. armory gets bonus points for later using testnet instead.)
22:33:39kanzure:gmaxwell: hm? i am not claiming they had a good argument.
22:34:08kanzure:"key management" is not at all the important decision for whether you should run bitcoind or not. it's totally superfluous.
22:34:58gmaxwell:I'm asking because e.g. switching to determinstic keypool via hardened bip32 is no more than a couple hours work, as the code for that is all there.
22:35:21gmaxwell:And so if we can do some small thing that silences a really dangerous and foolish argument, I'm all for it.
22:35:48kanzure:ah interesting, i was not aware of that. well, they were claiming (and so was chain.com also claiming) that running bitcoind is "superfluous" (that was the word used in public) to getting development work done.
22:35:53andytoshi:kanzure: i usually hear "key management" meaning backup problems, in which case hardened bip32 would totally solve it ... so to gmaxwell +1
22:36:19gmaxwell:Though it really irritates me to hear "doesn't use determinstic wallets" called key management, key management is half the _opposite_ of that, in that you actually _should_ be retiring old keys if you have good key management.
22:36:28kanzure:well, i didn't type the transcripts for these because i felt like it would be morally wrong for me to promote that, so i can't pull up the exact quotes now
22:36:50kanzure:gmaxwell: this was a lot of stuff like "bitcoind is confusing and hard and complex, so therefore you should just use our third party api instead, you'll get up and running in like 2.5 minutes"
22:37:48gmaxwell:kanzure: Do you agree with the "bitcoind is confusing and hard and complex" ? That kind of baffles me, in particular because many of the api's I've seen are an copies of bitcoind's (with some additional features).
22:37:56kanzure:i don't agree at all
22:38:05kanzure:i think it is actively dangerous and harmful to their customers and the community
22:38:06andytoshi:gmaxwell: there is such a thing as a "puncturable PRF" which lets you mar a PRF key so it can't be evaluated at specific points. this'd let you have deterministic and expirable keys..
22:38:18kanzure:i mean i think it is harmful to claim that bitcoind should not be used
22:38:28brisque:kanzure: it's a pretty dangerous implication that companies barrier to bitcoin is setting up a daemon.
22:38:57gmaxwell:kanzure: I know I was just asking about the first half. I don't agree with the second even if the first half is true, but regardless if the first half is true it ought to be fixed.
22:39:01andytoshi:you can puncture at individual points, or on prefixes ... i sholud look into the efficiency of these babies (it never occured to me since i use them as a building block for obfuscation crypto, so every other inefficiency pales beside the obfuscation itself)
22:39:18kanzure:gmaxwell: ah, well my experience with bitcoind has been totally pleasant.
22:39:39gmaxwell:andytoshi: I'm actually not following how a punctureable PRF is useful there.
22:40:26andytoshi:gmaxwell: you store the PRF key, your ecdsa keys are PRF(K, index), then once you've used some key (say, you've spent the coins associated to its address and this spend is long buried) you puncture the PRF key at its index
22:40:35kanzure:gmaxwell: i think that swithcing to deterministic hardened bip32 keypool things would be a very useful strategy to argue that (in addition to all of the normal and sane reasons that everyone should use bitcoind) moving to a third party api is harmful, and additionally unnecessary.
22:40:45andytoshi:gmaxwell: and from the punctured key you can restore all your keys except those whose indices you've punctured out
22:40:56andytoshi:s/all your keys/all your ecdsa keys/
22:41:05gmaxwell:andytoshi: what we want for key management is for you to be able to rotate out your master keys, so that your old backups become less of a liability when you no longer need them. So after the fact puncturing doesn't solve that.
22:41:44kanzure:hoever, i suspect that brisque is right and they will just claim "it's infrastructure that we don't want to have to run" or something... or "walletnotify is too hard to configure", i dunno.
22:41:44gmaxwell:moving to #bitcoin-dev
22:41:45andytoshi:oh, yeah, derp
23:37:21adlai:kanzure: in petertodd's transcript, "Anothe rissu eis"
23:37:39kanzure:and here i thought he was just speaking incantations
23:42:42kanzure:adlai: fixed
23:52:26Eliel:I've been wondering about the possibility of making use of the bitcoin mining process for microtransactions. I mean, there is value in being presented unsuccesful, but reasonably difficult to find block candidates that would've paid your address were they actually a block.
23:52:49Eliel:from the coinbase tx I mean
23:53:26gmaxwell:Eliel: sure, thats completely reasonable. And also people seem to have no interest in it. :(
23:54:00Eliel:I don't think too many even realize it's possible
23:54:12gmaxwell:It was more widely discussed back in 2011 at least.
23:55:02Eliel:that'd mean very few people.
23:55:25Eliel:in terms of how big the community is now
23:57:27Eliel:I guess the biggest issue is perhaps a lack of implementations for actually making practical use of this. I don't know of any wallet software that could support this.
23:59:29gmaxwell:amusingly, bitcoin core's wallet can support this in the sense that you can give it a block and it will happily show you the coinbase payment and then switch it to -1 confirms when it falls out of the chain.
23:59:39lechuga_:i wonder if anyone has implemented a pkcs#11 client for bitcoind