| 01:10:09 | jgarzik: | sheesh |
| 01:10:19 | jgarzik: | I want a smart contract/agent programming language |
| 01:11:08 | jgarzik: | a HLL that permits description of a multi-step system involving multiple parties, generating helper+validation code for each party |
| 01:13:11 | maaku: | maaku is now known as Guest36070 |
| 01:13:50 | Guest36070: | Guest36070 is now known as maaku |
| 01:22:00 | petertodd: | jgarzik: keep in mind, I'm talking about services that *rely* on zeroconf to be secure, not those who have additional security they can rely on |
| 01:22:44 | petertodd: | (although I'll admit, doing zeroconf double-spends on a physical atm machine is slightly gutsy...) |
| 01:26:28 | jgarzik: | petertodd, There is a layer of "business rule security" where it varies wildly depending on business model, customer relationship length, etc. whether or not it is worth it to attack |
| 01:27:35 | jgarzik: | That includes the cost of law enforcement cudgels, or the simple severing of a product delivery (subscription) upon non-payment. Or cancellation of goods prior to order shipment. |
| 01:27:35 | petertodd: | jgarzik: indeed, and at the same time, double-spend attacks do appear to be highly succesful even without replace-by-fee |
| 01:28:14 | jgarzik: | petertodd, Of course. That was always the case. A simple race double spend could always be initiated with zero miner collusion. I did that occasionally to test things, even. |
| 01:28:23 | jgarzik: | *network race |
| 01:29:31 | jgarzik: | petertodd, Both you and Mike Hearn tend to lend towards hyperbole on the 0conf issue, where there are really many shades of grey |
| 01:30:17 | petertodd: | what makes you think that? I've said a numerous times that accepting zeroconf is perfeclty ok *if* you're not relying on it, which is true |
| 01:30:29 | jgarzik: | petertodd, For a business that ships physical goods, accepting 0conf is in effect just a way to speed your checkout process along. The shipment of physical goods normally takes many hours or days, permitting plenty of time for actual confirmations to occur. |
| 01:30:30 | petertodd: | e.g. my usual analogy of resturant bills |
| 01:30:38 | petertodd: | and yes, I use that one too |
| 01:31:25 | petertodd: | that's got nothing to do with my point re: replace-by-fee: make it clear to users what the actual security is, and let them make informed decisions about how to protect their transactions |
| 01:32:10 | petertodd: | like I keep saying, wallets should have an "attempt undo" button |
| 01:53:26 | andrew: | andrew is now known as justanotheruser |
| 01:56:29 | dsnrk: | petertodd: even if the button wasn't connected to anything, it would push the idea that 0conf is totally unsafe. |
| 01:57:31 | dsnrk: | jgarzik: ideally you'd have a flow where the user gets to the end, sends the BTC and gets a message like "we've seen your transaction, we'll send you a confirmation email when everything is peachy". |
| 01:59:19 | petertodd: | dsnrk: indeed, and without miner support tx propagation is sufficiently unreliable that undos even minutes later succeed a small % of the time |
| 01:59:51 | jgarzik: | dsnrk, again, it depends on the business scenario. If you just purchased a subscription, and 0conf doesn't confirm, it is easy to revoke the subscription until payment is sorted. |
| 02:01:21 | dsnrk: | certainly, I was more talking non-service |
| 02:01:54 | petertodd: | dsnrk: I suspect the most vulnerable aren't businesses, they're your person-to-person bitcoin traders - mycelium in that regard is a disaster waiting to happen |
| 02:02:29 | dsnrk: | I know. I winced when I saw that "feature". |
| 02:03:08 | petertodd: | yeah, I'm glad my reddit post showing how easy it was to double spend got the visibility it did |
| 02:03:32 | dsnrk: | you seem to get some flak for your reddit posts I've noticed |
| 02:04:48 | petertodd: | different causes depending on the posts you're talking about - with the double-spending one I think there's a lot of people who are very wedded to the notion that bitcoin works well for person-to-person stuff |
| 02:05:34 | petertodd: | I found this recent reply especially funny: http://www.reddit.com/r/Bitcoin/comments/27hecs/github_add_replacebyfee_logic_to_the_mempool_by/ci14pz4 |
| 02:06:29 | dsnrk: | it's like replacing the airbags in your car with lead bricks. it works really well until it doesn't. |
| 02:07:11 | petertodd: | indeed |
| 02:08:17 | dsnrk: | bitcoin is absolutely terrible for in person things, I've always thought it weird that people would assume it can do that |
| 02:08:45 | petertodd: | I suspect people aren't always entirely clear on what exactly bitcoin *is* good for |
| 02:11:31 | shesek: | petertodd, I do find some sense in that... it might be a good idea to provide some tools for detection and handling of double spends |
| 02:12:19 | shesek: | specifically, implementing child-pays-for-parent and responding to double spends by burning everything on fees is something that I'd like to see implemented before replace-by-fee becomes common |
| 02:12:46 | petertodd: | shesek: well, interestingly since the recent mutability issue lots of wallets had double-spend issues fixed as a side effect |
| 02:13:36 | dsnrk: | there's sort of workarounds you can have that makes getting weak confirmations possible (merged mined side chains, intermediary blocks) but you still never end up with the credit card like system where the client sees instant confirmation and the vendor has fairly good assurance of payment. |
| 02:13:38 | petertodd: | I suspect implementing the non-child-pays-for-parent version of scorched earth might be more reliable, the one that requires the sender to use SIGHASH_ANYONECANPAY |
| 02:14:11 | petertodd: | dsnrk: yup, and I really worry that some of these weaker workarounds, especially things like double-spend detection, are going to incentivise people to attack the greater bitcoin system to achieve double-spends |
| 02:14:20 | shesek: | petertodd, how did handling mutability effect the handling of double spends? |
| 02:15:17 | shesek: | petertodd, attack the bitcoin system in what why? |
| 02:15:32 | petertodd: | shesek: mutability from a wallet's perspective is just another type of double-spend |
| 02:16:01 | petertodd: | shesek: for instance if you're relying on seeing double-spend alerts, I can attack you by sybil attacking you, and to do that I'm likely sybil attacking much of the network |
| 02:16:15 | dsnrk: | petertodd: I'd also say that if people push for "double spend detection" other more interesting systems (I am quite fond of the intermediary block thing that was mentioned once by gmax) end up getting ignored. |
| 02:16:25 | petertodd: | shesek: similarly for "weak confirmations" the amount of hashing power required can be quite small, which makes selling hashing power to attackers possibly profitable |
| 02:16:43 | petertodd: | dsnrk: absolutely, and detection is a really weak defense anyway |
| 02:17:20 | dsnrk: | don't know if that's true or not, but the impression I get from bitcoin development is that a lot of interesting things get lost to bike shedding PoW and other high-discussion low-impact low-value topics. |
| 02:18:12 | shesek: | depends on how you define "defense"... for a merchant that have a large window of time where he can stop handling the order (i.e. when delivering a physical product), detecting it is quite important |
| 02:18:23 | petertodd: | dsnrk: oh for sure, I'd say replace-by-fee is an example, fortunately it's an example where running code can change the conversation :) |
| 02:18:56 | petertodd: | shesek: yes, but usually in those cases you can just wait for a confirmation... the actual window where unconfirmed detection makes sense isn't big |
| 02:18:58 | shesek: | and what's "weak confirmations"? |
| 02:19:50 | petertodd: | shesek: schemes where you have a "commitment chain" with a short interval and much lower difficulty, and violating your commitment is punished somehow |
| 02:20:26 | dsnrk: | shesek: uh, sort of not well formed ideas I don't think. one of them involved having all the miners work on a intermediary block chain in the style of p2pool. people would get confirmations as part of that very rapidly but with not complete confidence. it's something which could lay on top of bitcoin today with no alterations to the core. |
| 02:20:29 | shesek: | ah, its what dsnrk just mentioned, isn't it? |
| 02:20:45 | shesek: | Do you have a link for that? Google doesn't seem to bring anything up for "weak confirmations" |
| 02:20:58 | petertodd: | shesek: it's been discussed here I'm sure |
| 02:22:13 | shesek: | dsnrk, so users can see that miners/pools are committing to putting some transactions in the next block, and would have a proof that they committed to it |
| 02:22:19 | dsnrk: | indeed |
| 02:22:30 | shesek: | but the miner doesn't actually have to include that transaction if he doesn't want to? |
| 02:22:41 | shesek: | so basically, you would get a proof that he cheated |
| 02:23:05 | shesek: | and possibly some system for punishing them when they do? |
| 02:23:11 | dsnrk: | well they would be working to solve a block with their proofs |
| 02:23:59 | dsnrk: | in the design I've seen described you wouldn't be able to punish them as such, it would be totally opt-in and not part of the protocol at all |
| 02:26:02 | shesek: | so, this intermediary blockchain is completely separate to the real one? would they get anything at all for working on it? |
| 02:26:48 | petertodd: | shesek: that's one of the problems with the idea! |
| 02:27:17 | shesek: | yeah, they're wasting hashing power on a PoW that gives them nothing |
| 02:27:18 | petertodd: | if they're getting something for it, you've basically just reduced the block interval, which is part of the economics of bitcoin |
| 02:27:34 | petertodd: | shesek: it'd be merge mined, so the hashing power isn't directly wasted |
| 02:28:12 | shesek: | ah, I see |
| 02:28:47 | shesek: | well, it could make sense for pools to participate in something like that - they'd get some more confidence from their users |
| 02:29:07 | shesek: | assuming that users (mostly miners) would care about that |
| 02:30:11 | dsnrk: | I assume it's in the miners best interests otherwise we would see people like ghash.io only acceptin very high fee transactions |
| 02:30:24 | shesek: | with fidelity bonds, if you assume that miners would stop using pools that are shown to behave badly, you can also have some financial punishment for them |
| 02:30:36 | petertodd: | indeed, and that's a *bad* thing, because it makes more centralized hashing power potentially more valuable than more decentralized hashing power - you really don't want pools to be able to offer guaranteed tx mining services |
| 02:31:20 | dsnrk: | surprised ghash.io hasn't thought of that already. submit your TX here for only 0.01BTC and have a 40% chance of it being in the next block! |
| 02:31:40 | dsnrk: | is it a double spend? who cares we do that ourselves anyway. |
| 02:31:56 | shesek: | dsnrk, why not simply "attach an 0.01 BTC to your tx and have a 40% chance"? |
| 02:32:38 | dsnrk: | was more making a comment on them double spending than an actual situation they might enforce. |
| 02:33:41 | petertodd: | you know, one of the thing replace-by-fee does for miners is gives attackers less reason to hack into their pools to do double-spends... not that much less, but somewhat less |
| 02:33:49 | shesek: | shouldn't it be possible to make that p2pool-style intermediary blockchain directly related to the block reward? |
| 02:33:57 | petertodd: | shesek: absolutely |
| 02:34:08 | petertodd: | shesek: heck, we could soft-fork mandatory p2pool |
| 02:34:27 | dsnrk: | * dsnrk would like that |
| 02:34:46 | shesek: | this seems like a great solution to me |
| 02:36:10 | shesek: | if something like that was implemented, do you think it would make sense to display some "transaction confidence" metric to users prior to the first confirmation? |
| 02:36:11 | petertodd: | I'm not so convinced :) p2pool probably has a lot of attack vectors that we don't realize - at the very least it reduces block intervals for sure |
| 02:36:44 | petertodd: | shesek: again, you don't want to make it easy to attack a *single* user, because then it becomes affordable to rent hashing power to do that |
| 02:38:40 | dsnrk: | shesek: well, you can see why I'm fond of it. I would very much like to see an altcoin with this just to see how it might run. it's something an altcoin could actually use. testnet3 style of course, wouldn't want people testing it with their own money. |
| 02:38:51 | shesek: | the ones who are most likely to be attacked are brick and mortar stores and services that reacts immediately to unconfirmed transactions in a way that can cost them money (e.g. betting websites) |
| 02:39:35 | shesek: | in other words, you don't have a lot to gain by attacking "regular" users |
| 02:40:09 | shesek: | and merchants/gambling websites operators can usually protect themselves against sybil attacks |
| 02:40:15 | petertodd: | shesek: I think you need to decide what a "regular" user actually is - maybe it is brick and mortar stores and gambling sites? |
| 02:40:27 | dsnrk: | the main issue with intermediary blocks is that it increases the affect of latency. I don't know if this would force centralisation or not. |
| 02:40:40 | dsnrk: | from what I've heard ghash.io would *hate* it :) |
| 02:41:14 | dsnrk: | (the seem to have problems with their hardware being very latent, so their free mining pool is designed to offset their high orphan rate.. or something) |
| 02:41:14 | petertodd: | making latency important can easily force centralization, quite literally, physical centralization due to speed of light issues |
| 02:41:43 | petertodd: | pools actually do find that where you are geographically located affects profitability even with 10min block intervals |
| 02:42:28 | dsnrk: | p2pool seems to handle 30 second blocks fine |
| 02:43:09 | dsnrk: | even one minute intermediaries would reduce that further. |
| 02:43:58 | petertodd: | dsnrk: well, define "fine" - you can certainly get an unfair advantage in p2pool by having lower latency than others |
| 02:47:05 | dsnrk: | petertodd: not ideal, certainly. might drive some optimisations or just make everybody rent racks next to each other. I don't know how that would work out. |
| 03:09:57 | jgarzik: | sub-second blocks are doable, under an interesting system that lets stronger PoWs reorg longer chains of blocks |
| 03:10:28 | jgarzik: | potentially fun for MMORPGs |
| 04:02:50 | wallet42: | wallet42 is now known as Guest56957 |
| 04:02:50 | wallet421: | wallet421 is now known as wallet42 |
| 05:00:32 | Supa: | Supa has left #bitcoin-wizards |
| 06:05:21 | andrew: | andrew is now known as justanotheruser |
| 06:07:53 | andrew: | andrew is now known as justanotheruser |
| 09:08:53 | adam3us: | petertodd: i dont think the weak confirmations is smaller than normal. its just shorter time and correspondingly weaker, so net even. consider for current difficulty approx 65-bit is full. a 64-bit comes expected 5mins, a 63-bit 2.5mins etc. |
| 09:15:16 | adam3us: | what-if: shares above a certain threshold (eg 9.375 sec interval at 6-bits below target 59-bits vs 65-bits) are broadcast. the absence of double spends in them indicates provably that no double spend attacks are going on. if there are double spends the 0-conf delay is increased. adapt under attack. now people could not publish their shares |
| 09:15:46 | adam3us: | but if they dont publish their shares, this is detectable as a discrepancy between share hashrate and full-solution hashrate. |
| 09:16:30 | adam3us: | it doesnt have progress because its a unanimous attack detection model. |
| 09:18:01 | adam3us: | to the extent that most ecosystem players actually WANT the ecosytem to work, and their profitability depends on it, this then cryptographically reflects what was already the model (ie just strengthens the status quo) in the sense that currently 0-conf are just protected by the meta-game theory idea that people with hash rate would not be trying to sabotage the ecosystem's utility or it |
| 09:18:19 | adam3us: | decreases the value of their large and already high risk mining investment |
| 09:20:02 | adam3us: | (this is actually what i assumed broadcast shares was about). also the idea to broadcast the first conflict marked as such helps. similar arguments. if you wait 10 seconds and there is no conflict flagged you are mostly good for low value items to the extent that most hashrate doesnt want to self-sabotage the ecosystem it relies on. |
| 11:16:17 | dansmith_btc: | dansmith_btc is now known as dansmith_away |
| 11:29:11 | anddam: | "This channel is not about Bitcoin today" set on Mar, 18 - is that still actual? |
| 11:30:22 | adam3us: | anddam: it means its about bitcoin in the far future. ie discussion questions about how bitcoin works today should happen eg on #bitcoin or implementation related questions on #bitcoin-dev |
| 11:31:23 | sipa: | sipa has changed the topic to: This channel is not about short-term Bitcoin development | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 11:39:13 | anddam: | oh lol, I got that as "Today the channel is not about Bitcoin" |
| 11:39:27 | anddam: | that's pretty clear now |
| 14:35:02 | fanquake: | fanquake has left #bitcoin-wizards |
| 17:02:16 | dsnrk: | "This is nonsense. Gavin, Andrew Miller, etc., are not even familiar with how proof-of-stake works. ... At worst, bitcoin core devs (well actually just gmaxwell) are aware, but have intentionally spread misinformation. " - http://www.reddit.com/r/peercoin/comments/1sokg2/proof_of_stake_and_peercoins_historic_significance/ce17qci |
| 17:05:46 | tacotime: | I wish cunicula was still around, he was a pretty fun dude. |
| 17:07:18 | tacotime: | Not that proof of stake isn't a technical nightmare (as most of my work is in PoW/PoS hybrid systems), and I don't totally agree with all of his points. |
| 17:07:20 | amiller: | ugh, thanks |
| 17:07:42 | tacotime: | amiller, I wouldn't take it personally |
| 17:08:26 | _ingsoc: | amiller: I would. You know what to do. |
| 17:08:30 | tacotime: | :P |
| 17:08:35 | amiller: | :p |
| 17:37:33 | adam3us: | so he says when nodes see a peercoin stakeholder produce a dup signature they punish the node. however i dont see why a nothing at stake abusing miner would publish their failed dups. isnt the point that nothing at stake is also undetectable (something like selfish mining… you publish the wins not the loses) |
| 17:59:30 | tacotime: | adam3us: I think he makes the assumption that people publishing the blocks will act in the best interest of the network and not themselves, which is probably incorrect. |
| 18:51:06 | anddam: | anddam has left #bitcoin-wizards |
| 20:50:36 | dansmith_away: | dansmith_away is now known as dansmith_btc |
| 20:59:13 | Kawhi_desu_: | Kawhi_desu_ is now known as Kawhi_desu |
| 21:05:39 | iddo_: | iddo_ is now known as iddo |
| 21:22:24 | Vitalik_: | Vitalik_ is now known as Vitalik |
| 21:22:48 | Vitalik: | Vitalik is now known as Vitalik__ |
| 22:18:53 | HobGoblin: | HobGoblin is now known as Guest26820 |
| 22:40:27 | Guest26820: | Guest26820 is now known as UukGoblin |
| 22:43:32 | tempnick1371713: | tempnick1371713 is now known as bitz |