| 00:40:05 | petertodd: | bramc: yeah, UTXO control is needed for the fidelity-bonded ledgers I was working on last year - AKA federated sidechains + fraud punishment/protection. |
| 00:42:01 | petertodd: | bramc: basically the fraud punishment script evaluates proofs of fraud by the signers, allows a tx to be created returning some of the funds back to their rightful owners, leaving the rest controlled by the same rules. slightly more complex version would use the "rachetting" mechanism to discover what was the longest chain signed by the federated signers first - the utxo control in the latter case implements state, thus finding the longest chain |
| 00:42:43 | bramc: | petertodd, fidelity-bonded ledgers are on my list of things to figure out, is there a good link for it? |
| 00:42:45 | petertodd: | bramc: may be combined with more recent proof-of-publication theory to ensure the chain is simply the most recent published on the master blockchain |
| 00:43:01 | petertodd: | bramc: search for that term on the bitcoin-dev mailing list - had a whole write up on it |
| 00:43:43 | petertodd: | bramc: main thing I didn't make clear enough back then was fraud can *also* be an absense of an action - e.g. satisfying a withdrawl request by a customer - I thought it was obvious at the time, but apparently not :/ |
| 00:44:22 | bramc: | This post? http://sourceforge.net/p/bitcoin/mailman/message/30531383/ |
| 00:44:33 | petertodd: | bramc: that's why last year I was talking about proof-of-publication with regard to the fraud proofs themselves - there must be conensus about all the *known fraud* for the fidelity bond to work, particularly, the ability to sell fidelity bonds, which is in turn critical to ensuring they are valuable even when the owner wants to disconvintue the service |
| 00:44:39 | kanzure: | http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01786.html |
| 00:44:47 | petertodd: | yeah |
| 00:45:36 | kanzure: | https://bitcointalk.org/index.php?topic=146307.0 |
| 00:45:51 | petertodd: | yup, that too |
| 00:46:32 | petertodd: | and lots of bitcoin-wizards discussion :/ unfortunately a bunch of it was done in private between me and gmaxwell too; probably should post those logs one of these days |
| 00:46:45 | bramc: | kanzure, Already had that link on my todo list |
| 00:47:52 | petertodd: | bramc: anyway, the key thing to understand with this fraud proof stuff, is the whole purpose is basically to trade off resources for a type of "trust but verify" "consensus" |
| 00:48:22 | bramc: | petertodd, I'm still not sure what at a high level fidelity bonded transactions really do |
| 00:48:25 | petertodd: | bramc: so there isn't global consensus about what actually happened, but there is global consensus that as far as anyone knows that entity hasn't been accued/proven of fraud yet |
| 00:48:52 | petertodd: | bramc: do you think you know at a high level what a fidelity bond is? |
| 00:49:08 | petertodd: | *accused/proven |
| 00:51:25 | bramc: | petertodd, I know what I read on wikipedia just now |
| 00:51:55 | petertodd: | bramc: haha, that's not it :) fidelity bonding in this context is crypto-specific |
| 00:52:11 | bramc: | In that case I have no idea |
| 00:53:36 | petertodd: | so in an abstract sense, I make a crypto identity, I make that identity expensive to obtain by sacrificing some value, I make a promise to adhere to some crypto-verifiable protocol, where fraud can be cheaply proven, and if anyone has evidence of fraud, they publish it via some public medium and everyone else stops trusting that crypto identity |
| 00:54:25 | kanzure: | and person with fraud evidence gets the bond value? |
| 00:54:27 | gmaxwell: | it's even more powerful if publishing proof of fraud can get you paid a little bit, to incentivize actually disclosing it when you find it. |
| 00:54:38 | kanzure: | but it's not required in the definition? |
| 00:54:41 | gmaxwell: | kanzure: they can't get all of it usually, without creating incentive problems. |
| 00:54:47 | petertodd: | if the fidelity bond can be *sold* to another party, the actual holder can be anonymous as even if they chose to disconinue using the identity it still has value, so no incentive to commit fraud |
| 00:54:59 | gmaxwell: | (e.g. where you commit fraud then race to report yourself) |
| 00:55:18 | gmaxwell: | the idea of getting paid is just to overcome indifference to reporting it and pay for the cost of doing so. |
| 00:55:30 | gmaxwell: | otherwise it's important that you can't just cash it out. |
| 00:56:10 | petertodd: | the trick is if you are to sell them, then proofs of fraud often *must* be done on a proof-of-publication medium - like a block chain - or the buyer has no way of knowing if there is unchallenged fraud out there. (though I've since realised you can use proof-of-publication with the *actions* instead) |
| 00:56:14 | kanzure: | what's the right heuristics for users that are aware that someone has a "reputational bond"? e.g. try not to transact in amounts greater than or equal to the amount recoverable in the event of a fraud proof? |
| 00:56:32 | petertodd: | kanzure: with a bank it'd be "don't have more deposits than the bond is worth" |
| 00:56:58 | petertodd: | kanzure: easy to prove with merkle-sum-trees, though there can be edge cases re: accepting a bunch of deposits at once that have to be handled carefully |
| 00:59:35 | petertodd: | fwiw it was fun bringing up this stuff with some regulators at the recent barclays hackathon I was at - blew their minds that not only were banks often made obsolete when trust is *not* involved, but also when it *is* involved - goes against the existing regulatory assumptions on a whole lot of levels |
| 01:00:25 | kanzure: | on a non wizardly note i have been trying to prioritize which awesome things to show regulators |
| 01:00:40 | petertodd: | for instance, there is pressure on these systems to ensure that things like account ledgers are *not* cryptographically verifiable as that forces trust to remain involved, benefiting profiting third-parties like clearance houses, as well as regulators that would prefer identity to remain an integral part of these systems |
| 01:00:49 | petertodd: | kanzure: ^ regulators don't necessarily think this stuff is awesome at all |
| 01:01:07 | kanzure: | heh |
| 01:01:13 | kanzure: | (news incoming soon) |
| 01:01:27 | petertodd: | kanzure: remember, from their point of view they ususally ant 100% visibility into everything that happens, and anything that discourages that or enables alternate ways of operating is bad |
| 01:01:31 | petertodd: | kanzure: ???? |
| 01:01:37 | petertodd: | s/ant/want/ |
| 01:02:23 | petertodd: | you can sometimes argue the opposite - crypto can ensure visibility through visibility proofs - but it can go either way |
| 01:03:01 | amiller: | proof-of-publication, to the extent it's defined clearly at all, doesn't seem a sufficient explanation for a bunch of things |
| 01:03:08 | amiller: | you can publish something and yet everyone can forget about it |
| 01:03:37 | petertodd: | amiller: you seen my uniquebits proof-of-concept? |
| 01:03:51 | amiller: | especially in some hypothetical alt coin where there are orders of magnitude more transactions because there isn't the pressure to fight spam etc. |
| 01:04:16 | petertodd: | so in the case of a bank-to-bank relationship, basically it just ensures that the version of the other parties records that you see is the same one everyone else sees - proof-of-publication does *not* require the actual data to be published, hashes + sigs are sufficient |
| 01:05:07 | amiller: | petertodd, yes but it seems so inefficient as to not be a solution, at least not in the cirucmstances i just described where there's either many more transactions or the cost of data included here is greater |
| 01:06:03 | petertodd: | amiller: you realise the incredibly ugly thing about this for you guys is that systems like uniquebits are much more secure, and for the people who need them they can outbid practically anyone else for proof-of-publication "bandwidth" *and* the way you use this stuff is *strongly* uncensorable |
| 01:06:49 | amiller: | if i were to define rigorously what i think you mean by "proof-of-publication", it would count if everyone alert and online at the time that a message is published 'sees' that message but immediately discards it afterward |
| 01:07:19 | petertodd: | amiller: of course it would - using a blockchain is just a way of guaranteeing the message actualy gets to the people who might want to see it |
| 01:07:34 | petertodd: | amiller: remember that a genuinely jam free network would replace the blockchain |
| 01:07:40 | amiller: | so, add-ons to proof-of-publication might include, proof-of-archival, or proof-of-inclusion-in-an-efficiently-queryable-index |
| 01:07:53 | petertodd: | yup |
| 01:07:55 | amiller: | the latter is exactly what the UTXO set provides, and what ethereum contract storage provides for that matter |
| 01:08:48 | petertodd: | indeed, which means any assumptions about UTXO set growth are bogus |
| 01:09:23 | petertodd: | there are *very* strong incentives for people to use this stuff over much less secure alternatives like Factom's federated model, that requires trusted third parties |
| 01:15:32 | roidster: | roidster is now known as Guest89020 |
| 01:15:44 | petertodd: | amiller: re cost of data, notice how my uniquebits app has the *exact same cost* to do proof-of-publication to secure a set of accounting records as it costs to do *any transaction at all* - which is no surprise given that bitcoin is a proof-of-publication system |
| 01:16:14 | petertodd: | amiller: (well, what I actually implemented was a PGP signature, but obviously that's trivially replaced with a scriptPubKey) |
| 01:16:46 | petertodd: | and my scheme that commits to the next published step makes it completely uncensorable |
| 01:17:18 | amiller: | the point that i'm making for bramc's benefit especially, is that proof-of-publication isn't sufficient for everything |
| 01:17:42 | amiller: | updating the UTXO index to make certain kinds of things efficiently queryable is important too |
| 01:18:37 | petertodd: | well currently it's tough to extract proofs-of-non-publication from bitcoin, but any UTXO index will make that easy |
| 01:19:01 | petertodd: | (where said proofs are meant to be SPV compatible of course - obviously the blockchain is such a proof) |
| 01:19:15 | amiller: | not any UTXO index makes all proofs-of-non-publication easy |
| 01:19:24 | amiller: | you can only do nonmembership proofs when the index is designed to support that |
| 01:20:01 | amiller: | the general form is, you might want to prove that there's no message m that's been published of the form P(m) for some arbitrary predicate P |
| 01:20:30 | amiller: | current utxo basically supports lookup by transaction id hash and that's it |
| 01:21:35 | petertodd: | sure, you could make the UTXO commitment be an unsorted merkle tree, but or, say, one sorted by time, but then SPV wallets can't use it to determine if people have been hiding payments from them |
| 01:21:59 | petertodd: | (again, this is because of the fundemental link between tx's and proof-of-publication...) |
| 01:22:43 | amiller: | i can't figure out if you're taking an opposing position to the point i'm making or not |
| 01:23:12 | petertodd: | well, I'm more making the point that any UTXO commitment that doesn't have that property isn't anywhere near as useful as one that does |
| 01:24:07 | petertodd: | there's a reaosn why all UTXO commitment proposals to date have had that property, with the funny exception of my TXO commitment proposal, which has always been suggested in conjunction with a separate per-block index |
| 01:25:10 | petertodd: | heck, I kinda remember bringing up this use-case as a reason *not* to do UTXO commitments with that type of query, and instead to stick to per-block indexes... IE, specifically to make proof-of-publication harder |
| 01:25:50 | amiller: | i can't tell if you are intending 'proof of publication' to include all possible uses of a utxo-like index |
| 01:25:57 | amiller: | or whether it refers to what you can do without any utxo index |
| 01:26:32 | petertodd: | proof-of-publication is a general concept; how efficient the proofs are is a matter of how the implementation works; a merkleized binary prefix tree makes the proofs very efficient |
| 01:27:07 | amiller: | i think you're being confusing here |
| 01:27:18 | petertodd: | how is that confusing? |
| 01:27:31 | amiller: | as i understand it proof-of-publication is supported by one kind of index arguably the kind that we already have |
| 01:27:59 | amiller: | but i'm trying to point out that there are other legitimate things to want that aren't captured by "proof-of-publication" and you'd want additional indexes to support those |
| 01:28:08 | petertodd: | ok, so, the key thing with proof-of-publication is in 99% of cases it needs to be accompanied by "proof-of-non-publication" to be useful |
| 01:28:59 | petertodd: | right now, for bitcoin a proof-of-non-publication requires ~ all blocks in the time interval of interest (less if you get clever with sha256 midstates) |
| 01:29:11 | amiller: | right sure |
| 01:30:03 | petertodd: | a UTXO commitment does with a binary prefix tree keyed by scriptPubKey makes non-publication easy to prove; even keyed by txid it's still doable-albeit a pain in the ass |
| 01:30:42 | petertodd: | similarly many types of per-block indexes provide similar guarantees, but at n log n space rather than log n |
| 01:30:44 | amiller: | okay so a utxo commitment with binary prefix tree by scriptPubKey is still not general enough to account for all reasonable uses of utxo-like indexes |
| 01:31:04 | amiller: | proof-of-non-publication as i understand it roughly says you can prove that a message M was *not* published |
| 01:31:16 | petertodd: | I'm not saying it is, I'm just saying for the purpose of proof-of-publication it is general enough |
| 01:31:26 | amiller: | that's different than saying that there is no published message M such that P(M), for example |
| 01:31:27 | amiller: | ok |
| 01:31:50 | amiller: | sure, for the purpose of proof-of-(non)-publication, a simple utxo index is sufficient... |
| 01:32:28 | petertodd: | yeah, which is (part) of why I've argued *against* utxo indexes with unlimited size - precisely because they're useful for my proof-of-publication ideas! |
| 01:33:00 | amiller: | i started by saying "Proof-of-Publication" is inadequate for describing all the things you'd want to do with a UTXO-like index, and you responded with "a simple UTXO index is sufficient to implement proof-of-(non)publication" which is a nonsequitur |
| 01:33:04 | amiller: | that's what i think is confusing! |
| 01:33:29 | petertodd: | right, I see why that was confusing |
| 01:34:17 | petertodd: | amiller: keep in mind I frequently am reseaching ideas that could be construed as economic exploits, so we better figure out how useful those exploits are, how censorship resistant they are, and design bitcoin accordingly |
| 01:34:27 | amiller: | yeah |
| 01:35:13 | petertodd: | whereas I get the sense other people are viewing those ideas as exploits, and responding to that by telling people to stop doing them, without bothering to fully understand the scope of them - you don't understand that unless you spend a lot of time improving those "exploits" as much as possible |
| 01:35:33 | petertodd: | e.g. there's a hell of a lot of misinformation going around about how easy to censor this stuff is - turns out it's incredibly difficult to censor |
| 01:35:40 | petertodd: | often flat out impossible |
| 01:58:45 | bramc: | Okay, I just read the backlog. I'm not sure what 'fraud' is here. The main use case is 'this person didn't hand over my gold in meatspace' which seems like a very he said she said unprovable thing. |
| 02:00:53 | bramc: | Also by proof of not publication does that mean 'proof that nobody levied an accusation against me'? |
| 02:01:52 | bramc: | Unfortunately now I need to run, have a good night everybody. |
| 02:02:08 | petertodd: | bramc: well, in the case of an off-chain bank, fraud may be "you didn't give me my money when I asked fo rit back" |
| 05:17:14 | gwollon: | gwollon is now known as gwillen |
| 06:06:22 | prontotest: | prontotest has left #bitcoin-wizards |
| 06:29:19 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:05:15 | 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:15 | card.freenode.net: | Users on #bitcoin-wizards: andy-logbot EasyAt paveljanik soundx CoinMuncher vmatekole jtimon coiner nsh rusty HaltingState NewLiberty devrandom wallet42 TwoKoolFourSkewl TheSeven phantomcircuit gwillen nullbyte ryanxcharles Starduster Nightwolf gazab PaulCapestany luny Tjopper davejh69____ Anduck spinza go1111111 grandmaster postpre adlai zwischenzug austinhill1 Shiftos gues___ Guest4661 mkarrer Dyaheon null_radix kyletorpey Emcy prodatalab tacotime samson_ hashtag_ Dr-G |
| 09:05:15 | card.freenode.net: | Users on #bitcoin-wizards: starsoccer maraoz atgreen nubbins` Aquent Graftec OneFixt Luke-Jr cfields digitalmagus8 c0rw1n stonecoldpat gmaxwell Flyer9933 SubCreative Greed [\\\] pigeons ahmed_ copumpkin gsdgdfs gribble isis nuke1989 dgenr8 jgarzik ebfull tromp super3 andytoshi lechuga_ waxwing bobke btcdrak coutts CryptOprah artifexd Muis hguux_ michagogo kumavis nickler gavinandresen Hunger- v3Rve NikolaiToryzin PRab warptangent Fistful_of_Coins heath koshii HM2 paperbot |
| 09:05:15 | card.freenode.net: | Users on #bitcoin-wizards: kefkius zibbo maaku epscy lnovy jaekwon_ Cory LarsLarsen Guest38445 coryfields iddo otoburb_ kinlo azariah4_ fenn shesek bosma iambernie mr_burdell nsh_ yoleaux btc__ Graet Logicwax pi07r Meeh DoctorBTC mappum K1773R nanotube dansmith_btc kanzure arowser1 hollandais berndj lclc s1w Eliel_ LaptopZZ sneak harrigan JonTitor sl01 Grishnakh sipa Alanius jbenet MRL-Relay fluffypony BlueMatt a5m0 AdrianG livegnik BananaLotus @ChanServ burcin wizkid057 |
| 09:05:15 | card.freenode.net: | Users on #bitcoin-wizards: bbrittain tromp_ Krellan poggy comboy mmozeiko Taek optimator_ Apocalyptic throughnothing petertodd crescendo so [d__d] espes BigBitz jaromil helo Keefe Iriez huseby phedny midnightmagic BrainOverfl0w warren harrow roasbeef ryan-c TD-Linux catcow danneu amiller smooth asoltys |
| 09:28:31 | rusty: | rusty has left #bitcoin-wizards |
| 09:58:41 | bramc: | Sure enough, the coinswap protocol is all about how to keep anonymity and does so in part by making the timelocks be in transactions which are usually cancelled. |
| 10:22:57 | lclc: | lclc is now known as lclc_bnc |
| 10:53:29 | petertodd: | BlueMatt: was considering it |
| 11:58:00 | lclc_bnc: | lclc_bnc is now known as lclc |
| 13:02:29 | lclc: | lclc is now known as lclc_bnc |
| 14:07:00 | lclc_bnc: | lclc_bnc is now known as lclc |
| 14:17:17 | jgarzik: | jgarzik is now known as jgarzik_ |
| 17:08:16 | op_null: | ;;later tell bramc " ..the coinswap protocol is all about..anonymity" I'd hesitate to call it anything beyond a privacy measure. people expecting a system to provide true anonymity are going to be badly burned if it turns out to be flawed (as has happened in the past with services making similar promises). |
| 17:08:17 | gribble: | The operation succeeded. |
| 17:40:27 | lclc: | lclc is now known as lclc_bnc |
| 18:39:14 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 19:02:17 | bramc: | op_null, Hah, I'm not claiming that it produces absolute anonymity, just that the design of the protocol is very much about trying to get as much anonymity as it can under the circumstances |
| 19:04:00 | bramc: | Working on anonymity in general sucks that way |
| 19:05:34 | phantomcircuit: | bramc, i suspect that with coinjoin and fixed size outputs you can achieve anonymity equal to the anonymity of the connection to the coordinator |
| 19:05:53 | op_null: | bramc: yes, I have the same sort of feeling for working on privacy software that I do for wallets in general. no way in hell can I be trusted to write something like that without significant review.. but other people seem to be doing it just fine. |
| 19:06:52 | bramc: | I'm specifically commenting on it because of the question of whether timelocks should be in transactions or utxos. Writing the same protocols with them being in utxos winds up feeling hackier and with more data included in the blockchain |
| 19:07:40 | bramc: | op_null, The creation of tor was very much a 'hold your nose and accept the threat model' admission to practicality. Everybody wanted to work on mixes because those can sort of actually protect privacy |
| 19:08:45 | bramc: | But obviously tor does a lot more for actually protecting anonymity in the real world than email mixes do. |
| 19:11:34 | op_null: | money is high impact too. |
| 19:11:52 | phantomcircuit: | bramc, well yes but only because email security is such shit that nobody sane would send all of their mail through a mix network |
| 19:11:53 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 19:11:55 | op_null: | if people use a "mixer" for many years only to find that it's broken, the impact could be huge. |
| 19:13:57 | bramc: | phantomcircuit, mix nets for high latency things like email can inherently be made much better, because you can quantize when all the mail is sent so an attacker can't correlate by timing, but the problem is people don't want to do everything via email, they want to do everything via the web, so there's many more orders of magnitude cover traffic for real time mix nets than delayed mix nets |
| 19:15:20 | bramc: | op_null, The same concerns apply for all kinds of mixnets, including tor. Working on anonymity sucks like that. |
| 19:16:34 | phantomcircuit: | bramc, yes but it should be possible to implement a mixnet on top of tor |
| 19:17:21 | bramc: | phantomcircuit, Yes you could build an email mixnet on top of tor. That hasn't been done because there's very little demand for it and everybody's busy trying to improve tor itself. |
| 19:19:22 | kanzure: | this one seems to be a thing http://diyhpl.us/~bryan/papers2/security/pynchon/pynchon-spec.txt |
| 19:21:58 | kanzure: | actually i don't understand why this was based on email |
| 19:22:31 | kanzure: | aren't there lots of text-based mixing scenarios that could benefit from not being related to smtp? |
| 19:22:46 | jgarzik: | starttls lol |
| 19:26:50 | bramc: | kanzure, Same reason as tor supports real time TCP: Cover traffic. Usability matters. |
| 19:27:15 | bramc: | kanzure, You might notice that my name is at the top of that thing. Unfortunately I think work on it has stalled out. |
| 19:28:10 | phantomcircuit: | bramc, wouldn't only supporting smtp limit the amount of cover traffic? |
| 19:28:46 | bramc: | phantomcircuit, No, because nobody's asked for any other cover traffic to be supported. You'd have to get people to start using something completely new |
| 19:29:00 | bramc: | Well, these days there are messenger apps, maybe one of them could do it. |
| 19:29:21 | bramc: | But those are also unfortunately very centralized |
| 19:30:08 | bramc: | And you don't really get the anonymity benefits until you start adding hours to the delay times. |
| 19:31:09 | op_null: | I wonder how long it'll take for somebody to set up a darkwallet server, sniff all of the coinjoins and blackmail people for it. |
| 19:31:43 | kanzure: | bramc: were you considering any other sort of protocol other than smtp? |
| 19:31:55 | kanzure: | i don't have any suggestions off the top of my head, so i will pester you for them |
| 19:32:03 | bramc: | I haven't yet *fully* grokked coinswap. Once I do I'll go over coinjoin and be able to speak intelligently about their relative anonymity properties |
| 19:32:42 | phantomcircuit: | bramc, for high volume small messages delays of even a few seconds might be enough |
| 19:32:47 | bramc: | kanzure, This was a number of years ago, when email still ruled the world, so no there weren't any such thoughts but maybe something new could be made now. |
| 19:32:51 | phantomcircuit: | at the very least it would be better |
| 19:32:52 | kanzure: | i don't think xmpp would tolerate multi-month delays |
| 19:33:12 | bramc: | phantomcircuit, Yes it would but it's hard to make pynchon gate work for that. Whether it could is an interesting question. |
| 19:33:30 | isis: | (actually, as a tor developer, i would like to point out that it's currently quite difficult to build an email mixnet on top of tor… we don't support MX or SRV records yet, though there is a proposal to accept all DNS types: https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.txt ) |
| 19:33:52 | kanzure: | but that's "raw" email |
| 19:34:56 | isis: | sure, you can do "not real email" and pass the records around by hand, but the rest of the email world probably won't ever talk to whatever protocol you make up |
| 19:34:58 | bramc: | Really though, the thing holding up even having a good prototype of pynchon gate is resources. I'm busy with other things, Nick is busy with tor, and Len's productivity has been severely limited. |
| 19:36:07 | isis: | having a pyncheon gate would be excellent however :) |
| 19:36:16 | kanzure: | isis: i don't know whether "the rest of the email world" is that important in that scheme, to be honest |
| 19:36:59 | bramc: | isis, no doubt. If anyone goes ahead and builds it we would all be very appreciative. |
| 19:41:21 | isis: | kanzure: i don't know either… though systems which have tried to redesign a privacy-preserving email-like messaging system which required custom servers and clients haven't seen much adoption, so one might prefer a protocol compatible with non-hacked-up Postfix servers in the rest of the email world in order to drive adoption. |
| 19:42:01 | op_null: | compatibility is how you get POODLEs though :) |
| 19:42:08 | isis: | but yes, it also could be junked. there's nothing worth saving from the design of email anyway. :) |
| 19:42:13 | kanzure: | i don't even know if email is good for very long delay... most email clients bury old stuff from the user |
| 19:42:57 | kanzure: | and new replies bump the old email thread, but that's not helpful (the nature of long delays probably requires you to be aware or shown which things you are waiting on, in a more protocol-specific way) |
| 19:43:35 | bramc: | op_null, What do you mean by POODLE? |
| 19:43:36 | kanzure: | well anyway, that is just ui, could still hack email |
| 19:44:04 | op_null: | bramc: sort of a joke, it's the TLS downgrade attack that was quite recent. |
| 19:44:34 | op_null: | bramc: https://www.openssl.org/~bodo/ssl-poodle.pdf |
| 19:49:03 | bramc: | kanzure, Back in the day email clients sorted by received time. An unfortunate number of them now sort by reported send time, which is fairly busted behavior |
| 19:49:49 | op_null: | bramc: I like it. it's a good bug to abuse. |
| 19:50:09 | op_null: | "you never sent that to me!" "sure I did, look it's unread all the way down at the bottom ;)" |
| 19:53:47 | bramc: | Yeah, busted behavior, spammers use it too |
| 19:56:00 | isis: | bramc: if at some point you'll be going over coinjoin and coinswap and their relative anonymity properties, i'd be quite curious to hear your thoughts |
| 19:59:40 | gmaxwell: | he's not going over their privacy properties. He was pondering how timelocks need to work. And observed that coinswap more or less depends on timelocks being specified in the spending transactions (though, this could also be accomplished with delegation). |
| 20:01:47 | zooko: | Wow, this is interesting: http://www.theverge.com/2014/12/10/7361603/bittorrenet-wants-to-change-the-way-the-web-is-built |
| 20:02:21 | op_null: | had better not contain the words "blockchain technology" |
| 20:02:27 | fluffypony: | hah |
| 20:02:29 | fluffypony: | blockchain 3.0 |
| 20:02:43 | zooko: | lol |
| 20:04:59 | bramc: | gmaxwell, There was some earlier discussion where someone said that coinjoin is almost/about as private. I need to finish going over them to respond intelligently to that one. |
| 20:05:39 | fluffypony: | "BitTorrent CEO Eric Klinker" |
| 20:05:42 | fluffypony: | no wonder the public expects Bitcoin to have a CEO |
| 20:06:16 | op_null: | just make it Andreas M. Antonopoulos and get the stupidity over with. |
| 20:07:10 | fluffypony: | * fluffypony giggles |
| 20:07:48 | lechuga_: | zooko: whoa that is cool |
| 20:08:15 | instagibbs: | *adds blockchain to BitTorrent, calls it Bittorrent 2.0* |
| 20:10:49 | fluffypony: | oh speaking of academia with nearly no details - https://www.cryptocoinsnews.com/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/ |
| 20:11:08 | kanzure: | blockchain 4.0 advocates have it all backwards, it's supposed to be exponentially increasing towards 0 |
| 20:11:37 | op_null: | fluffypony: right, more timing bullshit. if everybody who claims to connect to ever node actually did, we'd be in a lot of trouble. |
| 20:11:40 | fluffypony: | old article, but I haven't stumbled across any detail on how "transaction confidence" is determined beyond "a lot of nodes we're watching have received this tx" |
| 20:12:13 | op_null: | "BitPay has done tens of thousands of Bitcoin transactions in this manner and has not had one instance of a double spend." I find that hard to believe. |
| 20:12:34 | kanzure: | consider that the cost of a reorg is pretty high for that 0.0001 BTC transaction you made |
| 20:12:46 | fluffypony: | http://dev.blockcypher.com/reference.html#zero_confirmations |
| 20:12:49 | Luke-Jr: | kanzure: bad logic |
| 20:12:56 | kanzure: | also what size do you expect most bitpay transactions to be |
| 20:13:00 | op_null: | kanzure: I can finney attack you without mining a single block. |
| 20:13:19 | Luke-Jr: | kanzure: if you double spend, you can double spend a lot more than one transaction at once |
| 20:13:24 | kanzure: | maybe their definition of double spend is not double spend zero confirmations |
| 20:13:35 | op_null: | it is. |
| 20:13:48 | Luke-Jr: | accepting UNconfirmed transactions only makes sense if someone is physically in front of you (AND it's low value) |
| 20:13:51 | kanzure: | "double_spend_tx: the hash of the other transaction involved in the double spend attempt" only one? |
| 20:14:15 | kanzure: | op_null: so then you hold that bitpay is intentionally lying ? |
| 20:14:18 | instagibbs: | Luke-Jr: or you're just ok getting double-spent against. Something like a donation jar for music |
| 20:14:24 | op_null: | kanzure: no, the article is. |
| 20:14:29 | Luke-Jr: | "zero confirmation" is snake oil. it's not "zero", it's "not" |
| 20:14:33 | kanzure: | op_null: oh, that's less interesting. |
| 20:14:34 | Luke-Jr: | instagibbs: sure |
| 20:14:55 | Luke-Jr: | instagibbs: you might also have insurance |
| 20:15:12 | op_null: | kanzure: ha, yeah I wrote the tools to hammer the bitcoin network with double spends just to see what would happen. resigned one transaction n times and force pushed the inventory to every connected node. never used it, but it was a fun concept. |
| 20:15:26 | instagibbs: | Bitpay is probably ok given the current volume of txns. But as transactions scale, yeah it's really dangerous sans insurance. |
| 20:16:45 | op_null: | kanzure: I wrote it with the original concept of trying to find dual and tri stack nodes, but it turns out people's mempools are unique enough to act as a fingerprint without poisoning. |
| 20:17:56 | kanzure: | if a transaction is never reported to a service's users, what's the point of fingerprinting their mempool? you wont see results, i think |
| 20:18:42 | op_null: | well, like I said the concept was trying to find nodes with multiple interfaces. |
| 20:18:46 | kanzure: | what are you using these fingerprints for? |
| 20:18:48 | kanzure: | hm |
| 20:20:08 | op_null: | no real use beyond finding out if I could or not. |
| 20:38:17 | gwillen: | +e $a:Profreid |
| 20:38:31 | gwillen: | heh, oops :-) |
| 21:01:15 | bramc: | petertodd, What specific opcode functionality would you like added to support fidelity bonding? |
| 21:48:38 | dgenr8: | double-spend attack designed for a network where miners all mine first spend seen: https://github.com/bitcoin/bitcoin/pull/4570#issuecomment-53138831 |
| 22:02:21 | bramc: | dgenr8, Looks like that just relies on the receiver accepting the transaction way too quickly? |
| 22:05:52 | gmaxwell: | dgenr8: welcome to 2009? That kind of transaction pattern is what I was trying to open your eyes to when you were making proposals that miners orphan blocks which contain "double spends". |
| 22:09:55 | PRab_: | PRab_ is now known as PRab |
| 22:12:16 | midnightmagic: | case- and graph-based reasoning to justify additional tx handling logic is extremely hard to be complete about. presuming I understand the rationale behind the change, (since the code doesn't appear to special-case the way the reasoning does) then the payment graph of cases you are considering is incomplete and similar in nature and scope to (unsolveable IMO) branching and merging problems. |
| 22:14:37 | kanzure: | there's definitely something similar to a merging thing going on here, yeah |
| 22:14:47 | midnightmagic: | but I like the idea of rate-limiting respends. :-) |
| 22:15:20 | kanzure: | in many cases a transaction that gets an extra input or an extra output, all else being equal (like other previously existing outputs), tends to be okay to consider to be the same transaction, i think |
| 22:15:34 | dgenr8: | gmaxwell: you're no fun anymore |
| 22:15:40 | midnightmagic: | lol |
| 22:15:42 | kanzure: | although maybe i should constrain myself to only talking about a user wallet |
| 22:16:34 | kanzure: | it's some sort of bookkeeping-related merging |
| 22:17:07 | kanzure: | at minimum you would probably have to always show the user previous pre-merged stuff so they can follow along with what has happened |
| 22:17:10 | kanzure: | (or not happened) |
| 22:20:10 | bramc: | gmaxwell, Aren't blocks which contain double spends considered ill-formed? |
| 22:20:51 | tromp_: | if the other spend is in ancestor block, then yes of course |
| 22:20:54 | phantomcircuit: | bramc, he's talking about double spend prevention outside of the proof of work consensus system |
| 22:21:00 | midnightmagic: | a block which contains a double-spend or completes a double-spend will simply be rejected outright by the network. |
| 22:21:03 | phantomcircuit: | ie shit that doesn't really work |
| 22:22:21 | bramc: | oh, yeah, double spend prevention is the whole point of bitcoin, if there much you could do outside of that you wouldn't need all that resource waste on mining. |
| 22:22:30 | op_null: | yep |
| 22:23:21 | op_null: | the times people are talking about a double spend, it's usually a finney attack (broadcast a transaction, mine a block with a different transaction spending the same output) |
| 22:24:05 | op_null: | or a full blown reorg where somebody mines back from the head and undoes a transaction, spending it elsewhere. we've seen real world finney attacks, but I don't think any forced reorgs to double spend. |
| 22:25:01 | bramc: | This is why you wait for a few blocks to have passed before counting a transaction as really having happened |
| 22:25:31 | dgenr8: | op_null: you weren't referring to 0-conf in relation to bitpay above? |
| 22:26:11 | op_null: | dgenr8: kinda just in general. |
| 22:40:54 | gmaxwell: | bramc: thus the scare-quotes. |
| 22:41:41 | bramc: | reorg attacks become a problem when transaction fees are far in excess of mining rewards |
| 22:41:49 | gmaxwell: | bramc: in that case it means that block contained transactions you thought it ought to have not contained. |
| 22:57:09 | Greed`: | Greed` is now known as Greed |
| 23:47:23 | starsoccer: | starsoccer is now known as Guest15960 |
| 23:51:55 | gsdgdfs: | gsdgdfs is now known as Transisto |