| 05:53:57 | agorist000: | IIRC the new 0.10.0 version uses deterministic signing with libsecp256k1. Is this correct? |
| 05:54:17 | phantomcircuit: | agorist000, yes |
| 05:54:21 | phantomcircuit: | signing but not verification |
| 05:54:50 | agorist000: | Does that mean that the 3rd party TXID malleability problem is solved? |
| 05:55:08 | phantomcircuit: | no |
| 05:56:12 | agorist000: | I see. What else is needed for this to be solved then? |
| 05:56:22 | gmaxwell: | agorist000: thats a complete and total misunderstanding of what malleability and determinstic signing mean. |
| 05:56:32 | gmaxwell: | its unrelated. |
| 05:56:44 | gmaxwell: | determinstic signing does not and cannot make the signatures unique. |
| 05:58:16 | gmaxwell: | 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:23 | agorist000: | I see. Thanks for taking the time to explain. I shall have to research further. |
| 06:02:30 | Luke-Jr: | do we need BIP 62 if we end up adding a new OP_CHECKSIG with Joseph's sighash changes? |
| 06:07:04 | gmaxwell: | gmaxwell has left #bitcoin-wizards |
| 06:10:59 | maaku: | Luke-Jr: yes they are mostly unrelated |
| 06:11:31 | Luke-Jr: | implementation-wise, yes; but what does BIP 62 solve that the latter does not? |
| 06:11:41 | maaku: | 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:55 | maaku: | bip 62 are opt-out |
| 06:12:55 | maaku: | 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:20 | maaku: | whereas Joseph's extensions do protect against signer malleability but are only really usable in certain constructs. they are not generally safe |
| 06:16:09 | Luke-Jr: | I disagree that BIP62 is any more opt-out.. |
| 06:17:54 | GreenIsMyPepper: | 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:21 | maaku: | 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:35 | GreenIsMyPepper: | 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:44 | Luke-Jr: | maaku: you first have to opt-in by using v2 txs |
| 06:19:10 | maaku: | Luke-Jr: eh.. so? that's a trivial one line fix for any infrastructure |
| 06:19:35 | maaku: | GreenIsMyPepper: did you see my point about the normalized txid? |
| 06:19:48 | GreenIsMyPepper: | maaku: which point? sorry |
| 06:20:00 | maaku: | there isn't a way to calulate that from the infromation in the UTXO |
| 06:20:06 | maaku: | *the UTXO db |
| 06:20:24 | Luke-Jr: | maaku: current implementation in Bitcoin Core of the UTXO db* |
| 06:20:30 | GreenIsMyPepper: | no you'd need to also include the normalized txid as part of the UTXO |
| 06:21:06 | Luke-Jr: | * Luke-Jr still prefers using "hash of the scriptPubKey", which doesn't have any requirement to change UTXO db format |
| 06:21:19 | maaku: | 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:04 | GreenIsMyPepper: | 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:05 | maaku: | Luke-Jr: at the cost of not being sufficient if you care about more than just the on output |
| 06:22:48 | bramc: | 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:06 | maaku: | bramc: for certain transactions it does |
| 06:23:25 | maaku: | if you assume that the signers don't re-sign with a different nonce, of course |
| 06:23:33 | bramc: | maaku, Let me rephrase, until after you know a valid signature for the transaction |
| 06:24:47 | GreenIsMyPepper: | maaku: it's not unsolvable. for older transactions the normalized txid can only spend from tx version number above 3, etc. |
| 06:24:55 | bramc: | gmaxwell, How do lighthouse transactions work? The web page doesn't go into much detail. |
| 06:25:31 | GreenIsMyPepper: | 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:51 | maaku: | gmaxwell is gone. i angered him. but the search term you might want is "assurance contract" |
| 06:26:03 | maaku: | hearn gave a good talk about it at the 2014 conference too, which hopefully is available online |
| 06:26:19 | phantomcircuit: | bramc, iirc they're basically just anyone can pay |
| 06:27:35 | maaku: | GreenIsMyPepper: it's probably easier and better to just upgrade the db, if this feature is wanted bad enough to be deployed |
| 06:27:46 | maaku: | i just wasn't sure if you had considered this issue |
| 06:29:55 | GreenIsMyPepper: | maaku: Didn't consider blockchain pruning, just older txes, it's a good point. |
| 06:32:43 | bramc: | I'm not quite following how SIGHASH_ANYONECANPAY works |
| 06:33:53 | maaku: | bramc: you dont sign input ids |
| 06:34:20 | bramc: | 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:30 | GreenIsMyPepper: | anyonecanpay means you don't sign any input other than your own |
| 06:35:03 | bramc: | So how are signatures of the other inputs included then? And how do they specify the output? |
| 06:35:45 | GreenIsMyPepper: | they are included as part of the transaction, the other inputs are not SIGNED as part of your own input signature |
| 06:36:38 | bramc: | But there has to be some signature of the input utxos somewhere to make their spending valid |
| 06:37:24 | phantomcircuit: | bramc, each input signs the outputs |
| 06:37:28 | phantomcircuit: | or something to that effect |
| 06:37:31 | phantomcircuit: | i cant 100% remember |
| 06:37:51 | GreenIsMyPepper: | 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:19 | bramc: | 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:13 | GreenIsMyPepper: | 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:35 | bramc: | Thanks GreenIsMyPepper that's a document I should read through in its own right |
| 06:42:09 | GreenIsMyPepper: | 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:09 | bramc: | It seems like the initial bitcoin version was something satoshi had spent quite a bit of time on before releasing it |
| 06:43:27 | maaku: | maybe |
| 06:45:40 | bramc: | 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:22 | maaku: | fyi satoshi speculation is frowned upon here. no good comes of that. |
| 06:46:40 | bramc: | Fair enough, that's all I have to say on the matter anyway |
| 06:48:04 | bramc: | 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:02 | bramc: | sigtypes feels both overkill for what's actually used right now and underpowered for possible future extension |
| 06:51:17 | bramc: | 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:37 | GreenIsMyPepper: | 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:51:45 | GreenIsMyPepper: | multisig |
| 06:52:11 | GreenIsMyPepper: | after it hits the blockchain |
| 06:52:59 | bramc: | If you throw in schnorr signatures there isn't clear utility even for multisig, just regular sig, hash preimage, and nlocktime |
| 06:53:25 | bramc: | That first comma should probably have been a period. |
| 06:55:57 | bramc: | Here's the opposite question: Is there any real downside to making everything ANYONECANPAY? |
| 06:56:10 | bramc: | I mean, if you're starting over from scratch |
| 06:58:56 | GreenIsMyPepper: | 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:29 | GreenIsMyPepper: | By subtracting inputs minus outputs. |
| 07:00:00 | bramc: | So how do you get the fee with anyonecanpay? |
| 07:00:20 | GreenIsMyPepper: | When you sign an anyonecanpay transaction the transaction fee is not defined, it is effectively set by the last payer |
| 07:00:28 | GreenIsMyPepper: | the last signer, i mean. |
| 07:00:54 | bramc: | So if you overshoot lighthouse the extra all goes to a transaction fee? |
| 07:01:02 | GreenIsMyPepper: | The miners get the extra fees |
| 07:01:09 | GreenIsMyPepper: | miner (no s) |
| 07:02:03 | GreenIsMyPepper: | 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:22 | bramc: | Yeah that I understand. That edge case of lighthouse seems suboptimal though |
| 07:03:00 | GreenIsMyPepper: | TBH i don't know how lighthouse solves this. |
| 07:03:33 | hearn: | lighthouse does not let you over-pledge |
| 07:03:40 | bramc: | 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:03 | hearn: | miners do not have access to the pledge data before the contract is finalised and broadcast |
| 07:04:15 | bramc: | hearn, how does it enforce that? |
| 07:04:19 | hearn: | enforce what? |
| 07:04:29 | bramc: | A miner could participate in the transaction forming and mess with it |
| 07:05:02 | hearn: | "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:34 | GreenIsMyPepper: | Signatures are not exchanged between participants, only to the project owner? |
| 07:05:54 | hearn: | yes |
| 07:06:01 | GreenIsMyPepper: | So a zero-fee tx will never get broadcast? ok, makes sense. |
| 07:11:17 | bramc: | If you fix malleability properly ANYONECANPAY is a little weird because two different outputs could have nothing differentiating them |
| 07:11:31 | bramc: | Of course, if you don't reuse keys that won't happen... |
| 07:31:33 | GreenIsMyPepper: | 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:07 | GreenIsMyPepper: | Sorry, I meant, strip all input txids to fix malleability to fix malleability reusing keys can lose money. |
| 07:35:38 | bramc: | Depending on how it's implemented it might just result in the later transaction being declared invalid |
| 07:35:50 | bramc: | Because it's redundant |
| 07:36:25 | bramc: | 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:28 | GreenIsMyPepper: | 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:09 | GreenIsMyPepper: | for users that reuse transactions, but should be acceptable for wallets which don't expose bitcoin addresses. |
| 07:47:08 | bramc: | 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:56 | bramc: | 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:44 | bramc: | 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:35 | bramc: | 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:43 | GreenIsMyPepper: | Do you mean to use the index position in the utxo instead of txids? |
| 07:56:40 | GreenIsMyPepper: | because then reorgs start to get very messy... |
| 07:57:19 | sipa: | it means you're relying on blockchain functionality to define transaction validity |
| 08:02:44 | maaku: | 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:08 | maaku: | and accomplishes the same thing so long as you don't reuse addresses... |
| 08:04:56 | GreenIsMyPepper: | I would prefer it as well. Users can be kept from screwing up by not using that sighash flag at all. |
| 08:06:06 | maaku: | right it's not something that will accidentally happen |
| 08:07:16 | GreenIsMyPepper: | 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:35 | GreenIsMyPepper: | spending from that multisig P2SH, but again, that requires a pretty complicated wallet anyway... |
| 08:08:34 | GreenIsMyPepper: | 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:29 | GreenIsMyPepper: | 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:08 | GreenIsMyPepper: | 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:26 | maaku: | i don't see the safety aspect ... the use cases are non-overlapping |
| 08:16:49 | GreenIsMyPepper: | 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:00 | maaku: | right, but my point is current users also don't need malleability protection |
| 08:21:03 | maaku: | 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:46 | maaku: | i wish it was possible to soft-fork checksig :\ |
| 08:22:54 | bramc: | 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:58 | sipa: | it is; repurpose nop as checksig2 |
| 08:23:04 | GreenIsMyPepper: | 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:44 | bramc: | Of course, bitcoin doesn't actually work that way, and none of the altcoins have fixed that problem... |
| 08:26:09 | maaku: | sipa: that was an engineers lamentation, the NOP space being limited and such |
| 08:26:22 | sipa: | right, sure |
| 08:27:44 | bramc: | 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:08 | bramc: | Also doesn't add anything to the overall size in the end |
| 08:32:45 | maaku: | 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:48 | fluffypony: | 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:27 | fluffypony: | 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:41 | fluffypony: | and an idea for reducing association by use attacks |
| 08:34:25 | fluffypony: | 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:04 | Luke-Jr: | maaku: no need for a mask I think, just have it behave as OP_NOP for any unrecognised SIGHASH flag |
| 08:41:40 | maaku: | Luke-Jr: then it's trivial to steal coins |
| 08:42:02 | maaku: | a sighash is in the signature and fully malleable |
| 08:42:09 | Luke-Jr: | maaku: uh, if you use an unrecognised SIGHASH flag.. |
| 08:42:13 | Luke-Jr: | isn't it in the key? |
| 08:42:19 | maaku: | no, the sig |
| 08:42:28 | maaku: | that's what i'm saying, put a mask in the key |
| 08:42:43 | maaku: | so you constrain what can be malleated |
| 08:43:28 | Luke-Jr: | hm |
| 08:44:22 | Luke-Jr: | if we don't do that, we could add key recovery to the new checksig. or would that be too slow? |
| 08:45:09 | sipa: | only slightly slower |
| 08:45:23 | Luke-Jr: | I guess we still can even with a mask, just the data would be only a mask |
| 08:54:11 | rusty2: | rusty2 has left #bitcoin-wizards |
| 09:05:16 | card.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:16 | card.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:16 | card.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:16 | card.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:16 | card.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:48 | Ody10: | Ody10 has left #bitcoin-wizards |
| 09:45:01 | brisque: | http://democracyos.org/ |
| 09:45:01 | yoleaux: | 9 Oct 2014 15:41Z brisque: is there a document that has a list of inaccuracies in that unmentionable book? |
| 09:45:16 | brisque: | "Trust is deeply built into DemocracyOS using decentralized authority to certify every single decision made." |
| 09:46:53 | brisque: | kanzure: sure, lots of them are already on the wiki. |
| 09:50:45 | fluffypony: | "DemocracyOS is coded entirely in javascript." |
| 09:51:05 | fluffypony: | * fluffypony twitches |
| 09:56:32 | brisque: | 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:00:20 | adlai: | s/affords/costs/? |
| 10:03:21 | fluffypony: | adlai: "affords" in the sense of "adds to" or "supplies" |
| 10:15:03 | brisque: | 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:44 | nsh: | but it really holds the room together |
| 10:16:39 | Eliel: | nsh: that it does :P |
| 10:23:59 | sipa: | brisque: plus it really only works with a sufficiently strong incentive structure |
| 10:24:18 | sipa: | making it hard to use for things that don't have any value to distribute to cooperating nodes |
| 10:27:18 | brisque: | 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:23 | sipa: | brisque: well, cost and reward |
| 10:28:51 | sipa: | many distributed network are pretty easy to attack for a well-funded entity, but with very little gain from doing so |
| 10:29:06 | sipa: | if the gain is faking monetary transactions, that's very different |
| 11:07:30 | brisque: | sipa: that's a good way of putting it, I've never really thought of bitcoin as incentivising malice before. |
| 11:28:58 | Taek: | sipa: one reason you might want to combine multiple outputs under 1 signature is donation addresses |
| 11:33:41 | sipa: | Taek: help |
| 11:33:55 | Taek: | ? |
| 11:33:57 | sipa: | i think we should get rid of donation addresses |
| 11:34:03 | sipa: | they;re terrible for privacy |
| 11:34:25 | Taek: | for the sender too? |
| 11:34:35 | brisque: | definitely. |
| 11:34:46 | sipa: | for every single bitcoin user |
| 11:35:32 | sipa: | 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:36 | Taek: | hmm. I can't say I've thought about it enough to disagree competently |
| 11:36:40 | sipa: | i wonder how people would feel if their bank account's value was public |
| 11:37:58 | cbeams: | 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:04 | brisque: | 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:19 | cbeams: | so you'd have 'donation URLs' vs. donation addresses |
| 11:38:34 | brisque: | cbeams: electrum supports that, not that you'd know. |
| 11:38:43 | sipa: | cbeams: payment protocol, please |
| 11:38:48 | sipa: | this exists |
| 11:40:06 | sipa: | brisque: yup |
| 11:40:34 | cbeams: | I guess the question, then, is why aren't people using what already exists? |
| 11:40:55 | brisque: | like I said, there's no immediate tangible impact. |
| 11:41:45 | Taek: | It's the same reason people don't use encryption when they email each other: their tools don't enable it automatically. |
| 11:41:50 | brisque: | 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:07 | sipa: | cbeams: because the idea of account==address is too appealing |
| 11:43:14 | sipa: | it's a mental model people can grasp |
| 11:43:43 | cbeams: | agree, but it seems to me that there isn't a convenient alternative even for those who *are* privacy minded. |
| 11:43:44 | sipa: | and it's transparent due to several websites |
| 11:44:21 | cbeams: | modify what I wrote above regarding a simple http service as "a simple payment-protocol-based http service" |
| 11:44:29 | cbeams: | not tied to electrum necessarily, |
| 11:44:50 | sipa: | cbeams: it has problems, because the server can steal your coins |
| 11:44:51 | cbeams: | just something standalone that people could download and run, and then advertise a url for |
| 11:45:01 | sipa: | (by giving out its own addresses, rather than the users) |
| 11:45:05 | Eliel: | no tangible impact plus it's more work to do it properly. |
| 11:45:17 | sipa: | it's fixable |
| 11:45:23 | sipa: | but few people seem to care |
| 11:45:34 | Eliel: | the first part wouldn't matter too much if it was easy to do it properly :) |
| 11:48:21 | cbeams: | 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:54 | sipa: | cbeams: indeed, but it's under the user's control |
| 11:49:11 | cbeams: | 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:14 | sipa: | MitM seems less of a problem, because nobody expects it to solve the problem |
| 11:49:27 | fluffypony: | cbeams: why not just use OpenAlias? |
| 11:49:35 | sipa: | (like: if i email you my address, people will trust that email delives the mail corrects) |
| 11:49:35 | cbeams: | first I've heard of it. |
| 11:49:36 | fluffypony: | Electrum 2.0 has an OpenAlias plugin |
| 11:49:39 | fluffypony: | openalias.org |
| 11:50:22 | sipa: | fluffypony: doesn't seem to solve anything imho |
| 11:50:33 | sipa: | your address is still public? |
| 11:51:07 | fluffypony: | 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:08 | brisque: | sipa: for monero in particular that's not a problem, their addresses are alike "stealth" addresses. |
| 11:51:15 | sipa: | i see |
| 11:51:18 | fluffypony: | until stealth addresses become popular in BTC |
| 11:51:39 | sipa: | i really dislike stealth addresss |
| 11:51:52 | fluffypony: | oh interesting - may I ask why? |
| 11:51:57 | sipa: | they're a distraction that avoids building a real solution |
| 11:52:08 | sipa: | (which is out of band negotiation of transactions) |
| 11:52:52 | sipa: | which has so many extra advantages (better privacy, messaging, atomic refunds, no need to scan the blockchain for incoming transactions, ...) |
| 11:53:18 | fluffypony: | yeah we've been playing around with some ideas for exactly that |
| 11:53:32 | fluffypony: | but very far away |
| 11:53:34 | brisque: | fluffypony: scaling reusable addresses is a terrible problem, if nothing else. |
| 11:53:39 | Eliel: | 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:40 | sipa: | stealth addresses are the correct solution for a small subset of problems |
| 11:54:06 | sipa: | but they're also a more convenient solution for many problems that can be solved in a much better way |
| 11:54:24 | sipa: | apart from the fact that no deployed solution exists fro them |
| 11:54:27 | brisque: | 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:34 | fluffypony: | Eliel: if they're deterministic then an attacker can determine them |
| 11:54:40 | fluffypony: | yeah what brisque said |
| 11:54:54 | Eliel: | ah yes, sequence is a no go then |
| 11:55:03 | fluffypony: | if you're trying to avoid address reuse then you may as well publish a deterministic pubkey |
| 11:55:03 | Eliel: | has to be random numbers |
| 11:55:14 | sipa: | fluffypony: that doesn't solve the privacy problem |
| 11:55:15 | fluffypony: | but if it's for privacy then deterministic is a no-go |
| 11:55:22 | fluffypony: | sipa: yep ^^ |
| 11:55:33 | sipa: | avoiding address reuse is not the goal, it's a means |
| 11:55:43 | fluffypony: | yeah |
| 11:56:29 | brisque: | 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:56:38 | sipa: | yup |
| 11:57:20 | fluffypony: | yup, I was merely following the train of thought from Eliel's idea :) |
| 12:01:09 | Eliel: | being able to do this properly kind of really calls for a secure distributed messaging system. |
| 12:01:54 | sipa: | why? there is no need for anything distributed here |
| 12:02:07 | sipa: | transaction and key negotiation is a private business between sender and receiver |
| 12:02:14 | sipa: | tcp/ip works fine |
| 12:02:37 | sipa: | use tor if you need better privacy |
| 12:02:52 | Eliel: | 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:46 | brisque: | 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:42 | Eliel: | 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:38 | Eliel: | but since you don't have a messaging system you can trust to just work, that's not feasible. |
| 12:08:15 | sipa: | we have a messaging system |
| 12:08:17 | sipa: | it's called tcp/ip |
| 12:08:21 | brisque: | if you're attempting to donate to someone to pay an invoice, you already have HTTP to do that |
| 12:08:27 | maaku: | Eliel: you're solving this on the wrong layer |
| 12:09:10 | Eliel: | sipa: tcp/ip lacks the key feature of what I just described. |
| 12:09:51 | sipa: | which is? |
| 12:10:51 | Eliel: | sipa: if the recipient is not online, communication just fails. |
| 12:10:57 | fluffypony: | 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:12 | sipa: | Eliel: meh |
| 12:11:32 | sipa: | Eliel: email works too without people being online the whole time |
| 12:13:38 | Eliel: | 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:14 | sipa: | Eliel: that can be solved by encryption |
| 12:15:26 | sipa: | Eliel: have an address that's a url + encryption key |
| 12:15:53 | Eliel: | and now you have a system that's way too complex to setup for it to get much use. |
| 12:17:06 | sipa: | gmail doesn't require setup, does it? |
| 12:17:13 | sipa: | nothing that people can't handle |
| 12:17:32 | Eliel: | email itself, no. Actually using the encrypted messages, especially if you want it automated, hell yes. |
| 12:17:56 | sipa: | i don't understand |
| 12:18:11 | sipa: | it's exactly like bitcoin addresses today |
| 12:18:31 | sipa: | except the communication doesn't go over the blockchain, but using a mailbox-type service |
| 12:19:19 | sipa: | the sender creates an encrypted message with a fully-signed but unpublished transaction, sends it to the mailbox service |
| 12:19:32 | sipa: | the receiver's client fetches the message, decrypts it, validates it, and broadcasts it |
| 12:19:35 | sipa: | done |
| 12:19:54 | sipa: | the message contains both the transaction as the nonce used to generate the destination key |
| 12:20:17 | sipa: | so it's impossible for the transaction to arrive at the receiver without him knowing the nonce to spend the coins |
| 12:22:43 | Eliel: | 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:58 | sipa: | i don't mean using actual email |
| 12:23:05 | sipa: | just an email like system |
| 12:23:12 | sipa: | integrated in wallet software |
| 12:23:30 | sipa: | and i don't care that it just works |
| 12:23:33 | sipa: | paypal also just works |
| 12:25:07 | Eliel: | 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:10 | Eliel: | that'd at least make it sensible for donation receiver to set it up in a privacy enhancing way |
| 12:26:30 | brisque: | 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:41 | Eliel: | ... but this sounds just like payment protocol :P |
| 12:26:50 | sipa: | Eliel: it is the payment protocol |
| 12:27:26 | Luke-Jr: | brisque: uh, there's already a communication network |
| 12:27:31 | Luke-Jr: | otherwise bitcoin wouldn't work |
| 12:27:43 | sipa: | with an extension |
| 12:27:43 | sipa: | (to support encryption) |
| 12:28:15 | brisque: | Luke-Jr: not entirely what I meant. "communication" being anything other than flooding transactions and blocks. |
| 12:28:43 | Luke-Jr: | brisque: well, that's still better than stealth addresses at least IMO |
| 12:29:01 | Luke-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:13 | brisque: | 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:24 | instagibbs: | Flood network should really not be touched in favor of extra-consensus matters, I think most would agree |
| 13:55:54 | brisque: | 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. |
| 13:56:31 | sipa: | indeed |
| 14:07:25 | instagibbs: | centralization ftw! |
| 14:07:43 | fluffypony: | nah, just blockchain all the things |
| 14:08:15 | instagibbs: | I saw electrum people are working on(?) some sort of messaging layer using SMTP |
| 14:08:47 | fluffypony: | nah it's more like payment protocol |
| 14:08:48 | instagibbs: | only saw some slides, and unfortunately they're passing around MPKs it appears |
| 14:09:07 | fluffypony: | but over email |
| 14:09:15 | fluffypony: | I have an intense dislike for email as a mechanism |
| 14:09:22 | brisque: | that's unpleasant as hell. |
| 14:10:25 | instagibbs: | fluffypony: why? |
| 14:10:50 | fluffypony: | instagibbs: I find it unreliable |
| 14:11:08 | brisque: | instagibbs: you've got to admit, it hasn't aged particularly well. |
| 14:11:33 | instagibbs: | Right, but I'm wary of re-creating wheels |
| 14:11:53 | fluffypony: | emails can be silently dropped for any number of reasons, and even the most well-learned antispam system has false positives |
| 14:12:10 | brisque: | reference for instagibbs "slides" reference. https://electrum.org/bitcoinaliases.pdf |
| 14:18:18 | brisque: | 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:18 | brisque: | 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:35 | sipa: | at least the privacy leak is restricted to the server by default (assuming no worse leak) |
| 14:22:51 | sipa: | as opposed to to the entire world, in case of reusing addresses |
| 14:23:38 | sipa: | not disagreeing with you, though |
| 14:25:04 | kanzure: | "i guess you could say it's sort of a dark optimism" |
| 17:58:23 | brisque: | brisque has left #bitcoin-wizards |
| 20:32:07 | lnr: | lnr has left #bitcoin-wizards |
| 20:46:31 | bramc: | 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:18 | bramc: | 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:41 | bramc: | 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:23 | ebfull: | so i've been way out of the loop... what's going on with SNARKs? any cool advancements or libraries? |
| 22:48:13 | justanotheruser: | ebfull: nothing new afaik. theres always been this https://github.com/scipr-lab/libsnark |