05:53:57agorist000:IIRC the new 0.10.0 version uses deterministic signing with libsecp256k1. Is this correct?
05:54:17phantomcircuit:agorist000, yes
05:54:21phantomcircuit:signing but not verification
05:54:50agorist000:Does that mean that the 3rd party TXID malleability problem is solved?
05:56:12agorist000:I see. What else is needed for this to be solved then?
05:56:22gmaxwell:agorist000: thats a complete and total misunderstanding of what malleability and determinstic signing mean.
05:56:32gmaxwell:its unrelated.
05:56:44gmaxwell:determinstic signing does not and cannot make the signatures unique.
05:58:16gmaxwell:agorist000: malleability is an intentional feature it cannot be solved without abandoning useful features (like lighthouses' kickstarter transaction); perhaps you only intend to say unwelcome malleability? thats addressed by BIP 62.
06:00:23agorist000:I see. Thanks for taking the time to explain. I shall have to research further.
06:02:30Luke-Jr:do we need BIP 62 if we end up adding a new OP_CHECKSIG with Joseph's sighash changes?
06:07:04gmaxwell:gmaxwell has left #bitcoin-wizards
06:10:59maaku:Luke-Jr: yes they are mostly unrelated
06:11:31Luke-Jr:implementation-wise, yes; but what does BIP 62 solve that the latter does not?
06:11:41maaku:Joseph's suggestions (if they work... they at minimum require storing more informatino per UTXO than we currently are) are active opt-in
06:11:55maaku:bip 62 are opt-out
06:12:55maaku:and they cover different cases -- e.g. bip 62 doesn't protect against signer malleability, but it does work out of the box for "normal" transactions
06:13:20maaku:whereas Joseph's extensions do protect against signer malleability but are only really usable in certain constructs. they are not generally safe
06:16:09Luke-Jr:I disagree that BIP62 is any more opt-out..
06:17:54GreenIsMyPepper:Mmm I guess I see BIP 62 as a "nice to have", but it seems to get you convenience more than security? If an output is a single person/address, the receiver can just re-sign.
06:18:21maaku:Luke-Jr: what I meant is that typical use of the bitcoin protocl is protected by malleability by default with bip62. to be vulnerable you have to "opt out" by using different sighash modes for example
06:18:35GreenIsMyPepper:Whereas a normalized sighash flag lets you spend from a mutated transaction with a multisig output, which is when malleability is actively dangerous IMO
06:18:44Luke-Jr:maaku: you first have to opt-in by using v2 txs
06:19:10maaku:Luke-Jr: eh.. so? that's a trivial one line fix for any infrastructure
06:19:35maaku:GreenIsMyPepper: did you see my point about the normalized txid?
06:19:48GreenIsMyPepper:maaku: which point? sorry
06:20:00maaku:there isn't a way to calulate that from the infromation in the UTXO
06:20:06maaku:*the UTXO db
06:20:24Luke-Jr:maaku: current implementation in Bitcoin Core of the UTXO db*
06:20:30GreenIsMyPepper:no you'd need to also include the normalized txid as part of the UTXO
06:21:06Luke-Jr:* Luke-Jr still prefers using "hash of the scriptPubKey", which doesn't have any requirement to change UTXO db format
06:21:19maaku:right so at minimum you'd have to upgrade the UTXO db on startup, including re-downloading blocks with unspent txns if pruning is enabled (which is likely to be deployed first...)
06:22:04GreenIsMyPepper:Luke-Jr: I can understand the argument that people do silly things like reuse addresses, so keeping them from shooting themselves in the foot might make sense, even if that means UTXO size is ~doubled
06:22:05maaku:Luke-Jr: at the cost of not being sufficient if you care about more than just the on output
06:22:48bramc:bip 62 doesn't fix the problem that you can't know a utxo output id until after the transaction has been committed
06:23:06maaku:bramc: for certain transactions it does
06:23:25maaku:if you assume that the signers don't re-sign with a different nonce, of course
06:23:33bramc:maaku, Let me rephrase, until after you know a valid signature for the transaction
06:24:47GreenIsMyPepper:maaku: it's not unsolvable. for older transactions the normalized txid can only spend from tx version number above 3, etc.
06:24:55bramc:gmaxwell, How do lighthouse transactions work? The web page doesn't go into much detail.
06:25:31GreenIsMyPepper:but that entails some risk as well for some clients that don't check or download the transactions they're spending (blockchain.info?)
06:25:51maaku:gmaxwell is gone. i angered him. but the search term you might want is "assurance contract"
06:26:03maaku:hearn gave a good talk about it at the 2014 conference too, which hopefully is available online
06:26:19phantomcircuit:bramc, iirc they're basically just anyone can pay
06:27:35maaku:GreenIsMyPepper: it's probably easier and better to just upgrade the db, if this feature is wanted bad enough to be deployed
06:27:46maaku:i just wasn't sure if you had considered this issue
06:29:55GreenIsMyPepper:maaku: Didn't consider blockchain pruning, just older txes, it's a good point.
06:32:43bramc:I'm not quite following how SIGHASH_ANYONECANPAY works
06:33:53maaku:bramc: you dont sign input ids
06:34:20bramc:It seems like in lighthouse, somebody creates a transaction which sends the goal amount to a specific output, and then everybody else adds in bits to act as its inputs
06:34:30GreenIsMyPepper:anyonecanpay means you don't sign any input other than your own
06:35:03bramc:So how are signatures of the other inputs included then? And how do they specify the output?
06:35:45GreenIsMyPepper:they are included as part of the transaction, the other inputs are not SIGNED as part of your own input signature
06:36:38bramc:But there has to be some signature of the input utxos somewhere to make their spending valid
06:37:24phantomcircuit:bramc, each input signs the outputs
06:37:28phantomcircuit:or something to that effect
06:37:31phantomcircuit:i cant 100% remember
06:37:51GreenIsMyPepper:the signature is included as part of your own input. presume 100 inputs, one of them your own. you sign all outputs and your OWN input, all other inputs are not signed. your signature included as part of the transaction
06:38:19bramc:It seems like the big advantage is that the pledgers can go offline before everything goes through, otherwise there's a lot of round and round with getting the transaction re-signed as you find that some of the inputs have changed
06:39:13GreenIsMyPepper:bramc: this is the most accurate description out there (the stuff in the wiki has some small errors) Page 35: http://enetium.com/resources/Bitcoin.pdf
06:40:35bramc:Thanks GreenIsMyPepper that's a document I should read through in its own right
06:42:09GreenIsMyPepper:np, yeah, the primary value of anyonecanpay in lighthouse afaik is asynchronous transaction creation and an inability to attack by just refusing to sign after tx construction
06:43:09bramc:It seems like the initial bitcoin version was something satoshi had spent quite a bit of time on before releasing it
06:45:40bramc:The only real hint I've seen to satoshi's identity is that john gilmore was just a liiitle too quick about giving a deep insight in response to the initial post. I suspect he knows who satoshi is.
06:46:22maaku:fyi satoshi speculation is frowned upon here. no good comes of that.
06:46:40bramc:Fair enough, that's all I have to say on the matter anyway
06:48:04bramc:Not sure how I feel about sigtypes. My mental model has mostly had transactions including all inputs and outputs in a single signed entity.
06:49:02bramc:sigtypes feels both overkill for what's actually used right now and underpowered for possible future extension
06:51:17bramc:Anyway, I definitely need to read through the entire developer reference in detail, to make sure I've got everything, and because that's a lot easier than wading through the wiki. At least for me it is, because that's the way my brain works.
06:51:37GreenIsMyPepper:Yeah, exotic sighash combinations are very rarely used. Some seem completely pointless until you think about it for a long time (sighash_none can turn a 2-of-2 into a 1-of-1)
06:52:11GreenIsMyPepper:after it hits the blockchain
06:52:59bramc:If you throw in schnorr signatures there isn't clear utility even for multisig, just regular sig, hash preimage, and nlocktime
06:53:25bramc:That first comma should probably have been a period.
06:55:57bramc:Here's the opposite question: Is there any real downside to making everything ANYONECANPAY?
06:56:10bramc:I mean, if you're starting over from scratch
06:58:56GreenIsMyPepper:You may want to define the person paying. There is a minor side issue that the transaction fees are implicitly defined so by controlling both inputs and outputs you're implicitly writing the transaction fee as part of your signature. With anyonecanpay, the fee is not defined.
06:59:29GreenIsMyPepper:By subtracting inputs minus outputs.
07:00:00bramc:So how do you get the fee with anyonecanpay?
07:00:20GreenIsMyPepper:When you sign an anyonecanpay transaction the transaction fee is not defined, it is effectively set by the last payer
07:00:28GreenIsMyPepper:the last signer, i mean.
07:00:54bramc:So if you overshoot lighthouse the extra all goes to a transaction fee?
07:01:02GreenIsMyPepper:The miners get the extra fees
07:01:09GreenIsMyPepper:miner (no s)
07:02:03GreenIsMyPepper:So if total input is 1.1 BTC and output is 1 BTC, implicitly the transaction fee paid to the miner is 0.1 BTC
07:02:22bramc:Yeah that I understand. That edge case of lighthouse seems suboptimal though
07:03:00GreenIsMyPepper:TBH i don't know how lighthouse solves this.
07:03:33hearn:lighthouse does not let you over-pledge
07:03:40bramc:My suspicion is that it tries to keep everyone from overshooting. That of course has problems with a miner who messes with the transaction making everybody think it's short when it isn't
07:04:03hearn:miners do not have access to the pledge data before the contract is finalised and broadcast
07:04:15bramc:hearn, how does it enforce that?
07:04:19hearn:enforce what?
07:04:29bramc:A miner could participate in the transaction forming and mess with it
07:05:02hearn:"mess with it" how? pledges are typically stored on a server that's co-operating with the project owner. random people cannot simply delete other peoples pedges
07:05:34GreenIsMyPepper:Signatures are not exchanged between participants, only to the project owner?
07:06:01GreenIsMyPepper:So a zero-fee tx will never get broadcast? ok, makes sense.
07:11:17bramc:If you fix malleability properly ANYONECANPAY is a little weird because two different outputs could have nothing differentiating them
07:11:31bramc:Of course, if you don't reuse keys that won't happen...
07:31:33GreenIsMyPepper:Depends on what you mean by fixing malleability. For non-chained transactions you use a normalized transaction id by stripping scriptSig, you can't realistically spend from a different output. But yeah, if you strip all input sigs to fix malleability reusing keys can be disastrous.
07:33:07GreenIsMyPepper:Sorry, I meant, strip all input txids to fix malleability to fix malleability reusing keys can lose money.
07:35:38bramc:Depending on how it's implemented it might just result in the later transaction being declared invalid
07:35:50bramc:Because it's redundant
07:36:25bramc:Of course that could also mean that someone could permanently make a transaction non-committable on a reorg, which seems like a bad thing.
07:37:28GreenIsMyPepper:Yes, using a normalized txid has situations which don't solve malleability in chained transactions and anyonecanpay transactions. Stripping out the input txid entirely can solve it, but entails risks.
07:38:09GreenIsMyPepper:for users that reuse transactions, but should be acceptable for wallets which don't expose bitcoin addresses.
07:47:08bramc:In the case of one input and one output you might as well have both the input and the output be specified in a single descriptor
07:52:56bramc:Okay, here's my thought: The utxo should be specified based on a list of all the inputs and the outputs. The real question is how signatures of the inputs can be combined to validate a transaction
07:53:44bramc:So the simplest signature type is to give the whole utxo being signed. Next simplest is to sign its own input and the output and sign that.
07:55:35bramc:So utxos referring to each other directly with no reference to signatures is still the 'right' way to do it, but there has to be some kind of extension mechanism for signatures, or at least something equivalent to supporting anyonecanpay
07:55:43GreenIsMyPepper:Do you mean to use the index position in the utxo instead of txids?
07:56:40GreenIsMyPepper:because then reorgs start to get very messy...
07:57:19sipa:it means you're relying on blockchain functionality to define transaction validity
08:02:44maaku:GreenIsMyPepper: for what its worth I think a strip-outpoints sighash mode will be way easier to get into core than upgrading the utxo db to store a normalized id
08:03:08maaku:and accomplishes the same thing so long as you don't reuse addresses...
08:04:56GreenIsMyPepper:I would prefer it as well. Users can be kept from screwing up by not using that sighash flag at all.
08:06:06maaku:right it's not something that will accidentally happen
08:07:16GreenIsMyPepper:The primary problem is whether malleability for multisig P2SH addresses which the user enters is a problem, if it is, then it might be nice to use a normalized id.
08:07:35GreenIsMyPepper:spending from that multisig P2SH, but again, that requires a pretty complicated wallet anyway...
08:08:34GreenIsMyPepper:However, I guess the problem is *really* about wallets not going to re-sign transactions automatically, so if it was defaulted to use a normalized txid, then it's far easier
08:09:29GreenIsMyPepper:I presume if one directly connected to a miner, the miner may have sufficient incentive to fix the transaction id FOR you to collect the fee :]]
08:12:08GreenIsMyPepper:But yeah, I suppose something like stripping the input entirely is more necessary for functionality, normalized is safety scissors and the question is how costly/painful the UTXO transition would be.
08:13:26maaku:i don't see the safety aspect ... the use cases are non-overlapping
08:16:49GreenIsMyPepper:Currently, the benefit would be current uses of bitcoin pay to address, they don't need to re-sign. Oh also, defaulting to normalized is safer when your alternative is to strip out the input (SIGHASH_NOINPUT) in case you receive another payment after that (can't control others making mistakes, only your own).
08:20:00maaku:right, but my point is current users also don't need malleability protection
08:21:03maaku:you need malleability protection for protocols that are not being done today -- and the implementation of those protocols will use the strip-outpoints flag
08:21:46maaku:i wish it was possible to soft-fork checksig :\
08:22:54bramc:My point is, you ideally avoid the malleability problem entirely by having utxos be indexed without including their signatures, and anyonecanpay functionality can be built into that by having new signature types
08:22:58sipa:it is; repurpose nop as checksig2
08:23:04GreenIsMyPepper:I don't disagree, however, people will do stupid things if there was only SIGHASH_NOINPUT. If you treat SIGHASH_NORMALIZED as a honeypot alone it has value, but that's being really cynical.
08:23:44bramc:Of course, bitcoin doesn't actually work that way, and none of the altcoins have fixed that problem...
08:26:09maaku:sipa: that was an engineers lamentation, the NOP space being limited and such
08:26:22sipa:right, sure
08:27:44bramc:Also by making it so that it's a signature extension, it's then possible to make it so that some of the signatures are for everything and some are for their own inputs which might add some flexibility
08:28:08bramc:Also doesn't add anything to the overall size in the end
08:32:45maaku:hrm.. actually you could avoid the checksig{3,4,5,5,6...} problem by having the checksig2 take a sighash mask. then checksig2 could be soft-fork upgradeable...
08:32:48fluffypony:oh forgot to mention earlier this week, for andytoshi and adam3us in particular, MRL has a new research bulletin out that covers traceability attacks, temporal associations when selecting outputs to mix with, and an association by use attack: https://lab.getmonero.org/pubs/MRL-0004.pdf
08:33:27fluffypony:recommendations are made for fixing the traceability attacks (basically enforce global minimum mixin, and provide a path for unmixable outputs / dust to eventually be extracted)
08:33:41fluffypony:and an idea for reducing association by use attacks
08:34:25fluffypony:but temporal associations are trickier, and it comes down to choosing a reasonable distribution for selecting outputs to mix with (and there's not really enough data to make that determination)
08:36:04Luke-Jr:maaku: no need for a mask I think, just have it behave as OP_NOP for any unrecognised SIGHASH flag
08:41:40maaku:Luke-Jr: then it's trivial to steal coins
08:42:02maaku:a sighash is in the signature and fully malleable
08:42:09Luke-Jr:maaku: uh, if you use an unrecognised SIGHASH flag..
08:42:13Luke-Jr:isn't it in the key?
08:42:19maaku:no, the sig
08:42:28maaku:that's what i'm saying, put a mask in the key
08:42:43maaku:so you constrain what can be malleated
08:44:22Luke-Jr:if we don't do that, we could add key recovery to the new checksig. or would that be too slow?
08:45:09sipa:only slightly slower
08:45:23Luke-Jr:I guess we still can even with a mask, just the data would be only a mask
08:54:11rusty2:rusty2 has left #bitcoin-wizards
09:05:16card.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:16card.freenode.net:Users on #bitcoin-wizards: andy-logbot Dr-G3 adam3us Guyver2 justanotheruser NewLiberty Ody10 shesek lclc arubi hktud0 moa huseby jaekwon_ PaulCapestany espes__ GreenIsMyPepper bramc [7] dc17523be3 sneak zooko ebfull pigeons d1ggy dgenr8 nuke1989 dabura667 SwedFTP flower_ wallet42 prodatalab weex coinrookie Emcy Cory melvster kmels RoboTeddy Rynomster ryanxcharles Burrito bepo GAit MoALTz_ hashtag LarsLarsen CodeShark grandmaster epscy nanotube gavinandresen cryptowest
09:05:16card.freenode.net:Users on #bitcoin-wizards: DougieBot5000 p15_ tromp cluckj Starduster go1111111 binaryatrocity waxwing spinza andytoshi hashtag_ antgreen bliljerk101 pukie amincd luktgf embicoin luny tromp__ wizkid057 starsoccer xabbix comboy nsh Taek PRab adlai iddo EasyAt maaku Logicwax Pan0ram1x c0rw1n helo null_radix bosma sipa btcdrak NikolaiToryzin s1w Visheate crescendo livegnik asoltys_ optimator gribble fluffypony Meeh cursive yoleaux dansmith_btc [d__d] berndj Luke-Jr morcos
09:05:16card.freenode.net:Users on #bitcoin-wizards: nickler jgarzik Fistful_of_Coins dardasaba sl01 isis gwillen stonecoldpat BlueMatt face airbreather dasource bedeho smooth phantomcircuit ajweiss sdaftuar coryfields Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo forrestv Muis cfields platinuum Oizopower BananaLotus catlasshrugged Keefe JonTitor petertodd kanzure eric mappum jbenet wiz grubles midnightmagic heath gnusha warren Adrian_G Iriez lechuga_ dignork kinlo
09:05:16card.freenode.net:Users on #bitcoin-wizards: jessepollak ahmed_ Graet ryan-c Eliel veox amiller warptangent indolering K1773R TD-Linux leakypat CryptOprah Apocalyptic guruvan Anduck paperbot fenn harrow a5m0 SubCreative d9b4bef9 DoctorBTC mr_burdell NeatBasis Hunger- davout Alanius brand0 @ChanServ throughnothing btc___ HM2 azariah MRL-Relay otoburb hguux__ so phedny roasbeef BrainOverfl0w wumpus jcorgan jaromil bbrittain
09:24:48Ody10:Ody10 has left #bitcoin-wizards
09:45:01yoleaux:9 Oct 2014 15:41Z brisque: is there a document that has a list of inaccuracies in that unmentionable book?
09:45:16brisque:"Trust is deeply built into DemocracyOS using decentralized authority to certify every single decision made."
09:46:53brisque:kanzure: sure, lots of them are already on the wiki.
09:50:45fluffypony:"DemocracyOS is coded entirely in javascript."
09:51:05fluffypony:* fluffypony twitches
09:56:32brisque:if you make some assumptions about how they have designed the thing (it's not described), one gets the impression that "blockchain" is being used as a buzz word without consideration for what it actually affords a system that really does need authentication and sybil resistance.
10:03:21fluffypony:adlai: "affords" in the sense of "adds to" or "supplies"
10:15:03brisque:well the blockchain is quite interesting in that you have something with very good brand power (it's the first distributed consensus) with almost no applicability outside of canonical ordering. it's slow, awkward and ridiculously expensive, so you'd better have a very good rationality for throwing it into a design. as far as difficulty of justifiability goes, a block chain is well up there with shag carpet.
10:15:44nsh:but it really holds the room together
10:16:39Eliel:nsh: that it does :P
10:23:59sipa:brisque: plus it really only works with a sufficiently strong incentive structure
10:24:18sipa:making it hard to use for things that don't have any value to distribute to cooperating nodes
10:27:18brisque:sipa: I've seen that justified as "well people run debian mirrors with no incentive", but I think that's missing the point that bitcoin is on a whole different scale of resistance heating. if you're at the risk of someone overtaking your network at ease with EC2, then it's probably not realistic to call it a distributed consensus.
10:28:23sipa:brisque: well, cost and reward
10:28:51sipa:many distributed network are pretty easy to attack for a well-funded entity, but with very little gain from doing so
10:29:06sipa:if the gain is faking monetary transactions, that's very different
11:07:30brisque:sipa: that's a good way of putting it, I've never really thought of bitcoin as incentivising malice before.
11:28:58Taek:sipa: one reason you might want to combine multiple outputs under 1 signature is donation addresses
11:33:41sipa:Taek: help
11:33:57sipa:i think we should get rid of donation addresses
11:34:03sipa:they;re terrible for privacy
11:34:25Taek:for the sender too?
11:34:46sipa:for every single bitcoin user
11:35:32sipa:i think bitcoin as it's used today is pretty much unusable as a monetary system due its terrible privacy because of this
11:36:36Taek:hmm. I can't say I've thought about it enough to disagree competently
11:36:40sipa:i wonder how people would feel if their bank account's value was public
11:37:58cbeams:sipa: I've often thought of setting up a simple http service that accepts a GET request and responds with a new HD-generated address.
11:38:04brisque:sipa: I think the only reason there's not more attention given to bitcoin privacy is that it's not particularly tangible. the term is "losing" privacy, but there's not an immediate impact most of the time compared with say, losing your money.
11:38:19cbeams:so you'd have 'donation URLs' vs. donation addresses
11:38:34brisque:cbeams: electrum supports that, not that you'd know.
11:38:43sipa:cbeams: payment protocol, please
11:38:48sipa:this exists
11:40:06sipa:brisque: yup
11:40:34cbeams:I guess the question, then, is why aren't people using what already exists?
11:40:55brisque:like I said, there's no immediate tangible impact.
11:41:45Taek:It's the same reason people don't use encryption when they email each other: their tools don't enable it automatically.
11:41:50brisque:when you reuse an address a tentacle doesn't reach through your window and grab you out of your chair, therefor it's perfectly fine. stop worrying.
11:43:07sipa:cbeams: because the idea of account==address is too appealing
11:43:14sipa:it's a mental model people can grasp
11:43:43cbeams:agree, but it seems to me that there isn't a convenient alternative even for those who *are* privacy minded.
11:43:44sipa:and it's transparent due to several websites
11:44:21cbeams:modify what I wrote above regarding a simple http service as "a simple payment-protocol-based http service"
11:44:29cbeams:not tied to electrum necessarily,
11:44:50sipa:cbeams: it has problems, because the server can steal your coins
11:44:51cbeams:just something standalone that people could download and run, and then advertise a url for
11:45:01sipa:(by giving out its own addresses, rather than the users)
11:45:05Eliel:no tangible impact plus it's more work to do it properly.
11:45:17sipa:it's fixable
11:45:23sipa:but few people seem to care
11:45:34Eliel:the first part wouldn't matter too much if it was easy to do it properly :)
11:48:21cbeams:sipa: regarding the server giving out its own addresses, I don't see how this is any more of a risk than a MITM modifying a static donation address.
11:48:54sipa:cbeams: indeed, but it's under the user's control
11:49:11cbeams:i.e. if the assumption is that everyone runs his own donation address service, and everyone trusts his own server, then risk is pretty well contained, no?
11:49:14sipa:MitM seems less of a problem, because nobody expects it to solve the problem
11:49:27fluffypony:cbeams: why not just use OpenAlias?
11:49:35sipa:(like: if i email you my address, people will trust that email delives the mail corrects)
11:49:35cbeams:first I've heard of it.
11:49:36fluffypony:Electrum 2.0 has an OpenAlias plugin
11:50:22sipa:fluffypony: doesn't seem to solve anything imho
11:50:33sipa:your address is still public?
11:51:07fluffypony:sipa: yes, which doesn't matter for Monero because of the dual-key stealth addresses, but sure, more of a concern with Bitcoin
11:51:08brisque:sipa: for monero in particular that's not a problem, their addresses are alike "stealth" addresses.
11:51:15sipa:i see
11:51:18fluffypony:until stealth addresses become popular in BTC
11:51:39sipa:i really dislike stealth addresss
11:51:52fluffypony:oh interesting - may I ask why?
11:51:57sipa:they're a distraction that avoids building a real solution
11:52:08sipa:(which is out of band negotiation of transactions)
11:52:52sipa:which has so many extra advantages (better privacy, messaging, atomic refunds, no need to scan the blockchain for incoming transactions, ...)
11:53:18fluffypony:yeah we've been playing around with some ideas for exactly that
11:53:32fluffypony:but very far away
11:53:34brisque:fluffypony: scaling reusable addresses is a terrible problem, if nothing else.
11:53:39Eliel:it'd probably be doable to create a javascript module that takes a public key, makes a random number for each donation and then uses a similar derivation to BIP32 to make a new address for each donator. However, you'd either need to store all the random numbers somewhere or generate them from a sequence... both are a bit hairy with just javascript.
11:53:40sipa:stealth addresses are the correct solution for a small subset of problems
11:54:06sipa:but they're also a more convenient solution for many problems that can be solved in a much better way
11:54:24sipa:apart from the fact that no deployed solution exists fro them
11:54:27brisque:Eliel: I've thought of that before, but nothing stops people from just slurping the MPK and scanning for the addresses themselves. there's no additional privacy gained by it.
11:54:34fluffypony:Eliel: if they're deterministic then an attacker can determine them
11:54:40fluffypony:yeah what brisque said
11:54:54Eliel:ah yes, sequence is a no go then
11:55:03fluffypony:if you're trying to avoid address reuse then you may as well publish a deterministic pubkey
11:55:03Eliel:has to be random numbers
11:55:14sipa:fluffypony: that doesn't solve the privacy problem
11:55:15fluffypony:but if it's for privacy then deterministic is a no-go
11:55:22fluffypony:sipa: yep ^^
11:55:33sipa:avoiding address reuse is not the goal, it's a means
11:56:29brisque:fluffypony: publishing a MPK is pretty scary in terms of non hardened derivitation, it means that information leaks become critical flaws, or at the very least it enables people to be spear phished by leveraging their misunderstanding of deterministic wallets.
11:57:20fluffypony:yup, I was merely following the train of thought from Eliel's idea :)
12:01:09Eliel:being able to do this properly kind of really calls for a secure distributed messaging system.
12:01:54sipa:why? there is no need for anything distributed here
12:02:07sipa:transaction and key negotiation is a private business between sender and receiver
12:02:14sipa:tcp/ip works fine
12:02:37sipa:use tor if you need better privacy
12:02:52Eliel:mostly because it's enough work to set up a secure (as in, no third party able to read your stuff) messaging system that most don't bother
12:04:46brisque:I'm not sure peer to peer privacy is a huge problem at this point in time, it's completely overwhelmed by other privacy flaws. maybe once those are on their way to being solved we can care about more communication magic.
12:06:42Eliel:basically, if we had such a system, it could be integrated into a bitcoin wallet and you could then publish a single identifier (public key) and others could send coins by generating a new address with it on the fly and sending you the private key. You could then combine the private keys to send the coins onward.
12:07:38Eliel:but since you don't have a messaging system you can trust to just work, that's not feasible.
12:08:15sipa:we have a messaging system
12:08:17sipa:it's called tcp/ip
12:08:21brisque:if you're attempting to donate to someone to pay an invoice, you already have HTTP to do that
12:08:27maaku:Eliel: you're solving this on the wrong layer
12:09:10Eliel:sipa: tcp/ip lacks the key feature of what I just described.
12:09:51sipa:which is?
12:10:51Eliel:sipa: if the recipient is not online, communication just fails.
12:10:57fluffypony:Eliel: Monero does what you're describing but completely statically without requiring you or the sender to be online - a Monero address is two pubkeys serialised, to send a tx you compute a "destination" for outputs based on those two keys + some random data, so where an output goes to is not an address
12:11:12sipa:Eliel: meh
12:11:32sipa:Eliel: email works too without people being online the whole time
12:13:38Eliel:sipa: it works, most of the time, yes. But it's fragile and for most people there's a third party with access to their email.
12:15:14sipa:Eliel: that can be solved by encryption
12:15:26sipa:Eliel: have an address that's a url + encryption key
12:15:53Eliel:and now you have a system that's way too complex to setup for it to get much use.
12:17:06sipa:gmail doesn't require setup, does it?
12:17:13sipa:nothing that people can't handle
12:17:32Eliel:email itself, no. Actually using the encrypted messages, especially if you want it automated, hell yes.
12:17:56sipa:i don't understand
12:18:11sipa:it's exactly like bitcoin addresses today
12:18:31sipa:except the communication doesn't go over the blockchain, but using a mailbox-type service
12:19:19sipa:the sender creates an encrypted message with a fully-signed but unpublished transaction, sends it to the mailbox service
12:19:32sipa:the receiver's client fetches the message, decrypts it, validates it, and broadcasts it
12:19:54sipa:the message contains both the transaction as the nonce used to generate the destination key
12:20:17sipa:so it's impossible for the transaction to arrive at the receiver without him knowing the nonce to spend the coins
12:22:43Eliel:the problem is, both the sender and receiver would need to have already setup their bitcoin wallets with their email. Just putting up a single bitcoin address as a donation address is still much easier and just works.
12:22:58sipa:i don't mean using actual email
12:23:05sipa:just an email like system
12:23:12sipa:integrated in wallet software
12:23:30sipa:and i don't care that it just works
12:23:33sipa:paypal also just works
12:25:07Eliel:ok, if you create a new kind of service for just bitcoin-wallet messaging, you could potentially make it easy enough that it does not rely on the donation sender having to do any setup.
12:26:10Eliel:that'd at least make it sensible for donation receiver to set it up in a privacy enhancing way
12:26:30brisque:making some sort of communication network on top of bitcoins sounds like a horrible idea, frankly. stealth addresses are more preferable than that.
12:26:41Eliel:... but this sounds just like payment protocol :P
12:26:50sipa:Eliel: it is the payment protocol
12:27:26Luke-Jr:brisque: uh, there's already a communication network
12:27:31Luke-Jr:otherwise bitcoin wouldn't work
12:27:43sipa:with an extension
12:27:43sipa:(to support encryption)
12:28:15brisque:Luke-Jr: not entirely what I meant. "communication" being anything other than flooding transactions and blocks.
12:28:43Luke-Jr:brisque: well, that's still better than stealth addresses at least IMO
12:29:01Luke-Jr:probably wouldn't be that hard either - you could even have nodes pay an intermediary peer to relay if they can't connect directly
12:35:13brisque:Luke-Jr: that would result in bitcoin just being people's go-to flood network for everything under the sun, you can't do any sort of targeted routing within the current design (and I don't think you'd want to). an intermediary fee wouldn't work just due to dust and privacy.
13:52:24instagibbs:Flood network should really not be touched in favor of extra-consensus matters, I think most would agree
13:55:54brisque:if nothing else you quickly run into flooding problems. if you rate limit (like free transactions today) you make a trivial to jam and thus totally unreliable way of getting messages around. you could add some hashcash into the mix, but you get back to the core problem of hashcash where any level of difficulty that would hinder an attacker makes it unusable for an end user.
14:07:25instagibbs:centralization ftw!
14:07:43fluffypony:nah, just blockchain all the things
14:08:15instagibbs:I saw electrum people are working on(?) some sort of messaging layer using SMTP
14:08:47fluffypony:nah it's more like payment protocol
14:08:48instagibbs:only saw some slides, and unfortunately they're passing around MPKs it appears
14:09:07fluffypony:but over email
14:09:15fluffypony:I have an intense dislike for email as a mechanism
14:09:22brisque:that's unpleasant as hell.
14:10:25instagibbs:fluffypony: why?
14:10:50fluffypony:instagibbs: I find it unreliable
14:11:08brisque:instagibbs: you've got to admit, it hasn't aged particularly well.
14:11:33instagibbs:Right, but I'm wary of re-creating wheels
14:11:53fluffypony:emails can be silently dropped for any number of reasons, and even the most well-learned antispam system has false positives
14:12:10brisque:reference for instagibbs "slides" reference. https://electrum.org/bitcoinaliases.pdf
14:18:18brisque:I assume in that model the server has to have an address indexed full node to do lookups against, otherwise an attacker can do a trivial denial of service attack where they request past the victim's address lookup cap limit, but never send anything to the addresses.
14:21:18brisque:the idea is a little uncomfortable anyway, despite it's name a MPK really is quite private material. a compromise of that server would both nullify any gain given by not reusing address, and it would also provide name to MPK maps. in fact it's probably worse than just reusing addresses, leaking a MPK is a disaster.
14:22:35sipa:at least the privacy leak is restricted to the server by default (assuming no worse leak)
14:22:51sipa:as opposed to to the entire world, in case of reusing addresses
14:23:38sipa:not disagreeing with you, though
14:25:04kanzure:"i guess you could say it's sort of a dark optimism"
17:58:23brisque:brisque has left #bitcoin-wizards
20:32:07lnr:lnr has left #bitcoin-wizards
20:46:31bramc:I wonder about parsimony in signing library APIs. You should be able to squeeze out a few bytes by making the API 'Is this a valid signature of this thing?' instead of 'what is this a signature of?'. Some for the corresponding public key.
20:50:18bramc:So the verify function takes a target signature, a public key, and a purported signature, and it returns True or False based on whether that signature is valid for that public key and target.
20:50:41bramc:But maybe some of this doesn't save any bytes. Or is done that way already. I'll have to work through the details eventually.
22:43:23ebfull:so i've been way out of the loop... what's going on with SNARKs? any cool advancements or libraries?
22:48:13justanotheruser:ebfull: nothing new afaik. theres always been this https://github.com/scipr-lab/libsnark