01:10:19jgarzik:I want a smart contract/agent programming language
01:11:08jgarzik:a HLL that permits description of a multi-step system involving multiple parties, generating helper+validation code for each party
01:13:11maaku:maaku is now known as Guest36070
01:13:50Guest36070:Guest36070 is now known as maaku
01:22:00petertodd: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:44petertodd:(although I'll admit, doing zeroconf double-spends on a physical atm machine is slightly gutsy...)
01:26:28jgarzik: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:35jgarzik: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:35petertodd:jgarzik: indeed, and at the same time, double-spend attacks do appear to be highly succesful even without replace-by-fee
01:28:14jgarzik: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:23jgarzik:*network race
01:29:31jgarzik: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:17petertodd: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:29jgarzik: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:30petertodd:e.g. my usual analogy of resturant bills
01:30:38petertodd:and yes, I use that one too
01:31:25petertodd: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:10petertodd:like I keep saying, wallets should have an "attempt undo" button
01:53:26andrew:andrew is now known as justanotheruser
01:56:29dsnrk:petertodd: even if the button wasn't connected to anything, it would push the idea that 0conf is totally unsafe.
01:57:31dsnrk: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:19petertodd:dsnrk: indeed, and without miner support tx propagation is sufficiently unreliable that undos even minutes later succeed a small % of the time
01:59:51jgarzik: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:21dsnrk:certainly, I was more talking non-service
02:01:54petertodd: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:29dsnrk:I know. I winced when I saw that "feature".
02:03:08petertodd:yeah, I'm glad my reddit post showing how easy it was to double spend got the visibility it did
02:03:32dsnrk:you seem to get some flak for your reddit posts I've noticed
02:04:48petertodd: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:34petertodd: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:29dsnrk:it's like replacing the airbags in your car with lead bricks. it works really well until it doesn't.
02:08:17dsnrk:bitcoin is absolutely terrible for in person things, I've always thought it weird that people would assume it can do that
02:08:45petertodd:I suspect people aren't always entirely clear on what exactly bitcoin *is* good for
02:11:31shesek: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:19shesek: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:46petertodd:shesek: well, interestingly since the recent mutability issue lots of wallets had double-spend issues fixed as a side effect
02:13:36dsnrk: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:38petertodd: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:11petertodd: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:20shesek:petertodd, how did handling mutability effect the handling of double spends?
02:15:17shesek:petertodd, attack the bitcoin system in what why?
02:15:32petertodd:shesek: mutability from a wallet's perspective is just another type of double-spend
02:16:01petertodd: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:15dsnrk: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:25petertodd: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:43petertodd:dsnrk: absolutely, and detection is a really weak defense anyway
02:17:20dsnrk: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:12shesek: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:23petertodd: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:56petertodd: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:58shesek:and what's "weak confirmations"?
02:19:50petertodd: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:26dsnrk: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:29shesek:ah, its what dsnrk just mentioned, isn't it?
02:20:45shesek:Do you have a link for that? Google doesn't seem to bring anything up for "weak confirmations"
02:20:58petertodd:shesek: it's been discussed here I'm sure
02:22:13shesek: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:30shesek:but the miner doesn't actually have to include that transaction if he doesn't want to?
02:22:41shesek:so basically, you would get a proof that he cheated
02:23:05shesek:and possibly some system for punishing them when they do?
02:23:11dsnrk:well they would be working to solve a block with their proofs
02:23:59dsnrk: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:02shesek:so, this intermediary blockchain is completely separate to the real one? would they get anything at all for working on it?
02:26:48petertodd:shesek: that's one of the problems with the idea!
02:27:17shesek:yeah, they're wasting hashing power on a PoW that gives them nothing
02:27:18petertodd: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:34petertodd:shesek: it'd be merge mined, so the hashing power isn't directly wasted
02:28:12shesek:ah, I see
02:28:47shesek:well, it could make sense for pools to participate in something like that - they'd get some more confidence from their users
02:29:07shesek:assuming that users (mostly miners) would care about that
02:30:11dsnrk: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:24shesek: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:36petertodd: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:20dsnrk: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:40dsnrk:is it a double spend? who cares we do that ourselves anyway.
02:31:56shesek:dsnrk, why not simply "attach an 0.01 BTC to your tx and have a 40% chance"?
02:32:38dsnrk:was more making a comment on them double spending than an actual situation they might enforce.
02:33:41petertodd: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:49shesek:shouldn't it be possible to make that p2pool-style intermediary blockchain directly related to the block reward?
02:33:57petertodd:shesek: absolutely
02:34:08petertodd:shesek: heck, we could soft-fork mandatory p2pool
02:34:27dsnrk:* dsnrk would like that
02:34:46shesek:this seems like a great solution to me
02:36:10shesek: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:11petertodd: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:44petertodd: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:40dsnrk: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:51shesek: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:35shesek:in other words, you don't have a lot to gain by attacking "regular" users
02:40:09shesek:and merchants/gambling websites operators can usually protect themselves against sybil attacks
02:40:15petertodd: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:27dsnrk: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:40dsnrk:from what I've heard ghash.io would *hate* it :)
02:41:14dsnrk:(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:14petertodd:making latency important can easily force centralization, quite literally, physical centralization due to speed of light issues
02:41:43petertodd:pools actually do find that where you are geographically located affects profitability even with 10min block intervals
02:42:28dsnrk:p2pool seems to handle 30 second blocks fine
02:43:09dsnrk:even one minute intermediaries would reduce that further.
02:43:58petertodd:dsnrk: well, define "fine" - you can certainly get an unfair advantage in p2pool by having lower latency than others
02:47:05dsnrk: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:57jgarzik:sub-second blocks are doable, under an interesting system that lets stronger PoWs reorg longer chains of blocks
03:10:28jgarzik:potentially fun for MMORPGs
04:02:50wallet42:wallet42 is now known as Guest56957
04:02:50wallet421:wallet421 is now known as wallet42
05:00:32Supa:Supa has left #bitcoin-wizards
06:05:21andrew:andrew is now known as justanotheruser
06:07:53andrew:andrew is now known as justanotheruser
09:08:53adam3us: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:16adam3us: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:46adam3us:but if they dont publish their shares, this is detectable as a discrepancy between share hashrate and full-solution hashrate.
09:16:30adam3us:it doesnt have progress because its a unanimous attack detection model.
09:18:01adam3us: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:19adam3us:decreases the value of their large and already high risk mining investment
09:20:02adam3us:(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:17dansmith_btc:dansmith_btc is now known as dansmith_away
11:29:11anddam:"This channel is not about Bitcoin today" set on Mar, 18 - is that still actual?
11:30:22adam3us: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:23sipa: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:13anddam:oh lol, I got that as "Today the channel is not about Bitcoin"
11:39:27anddam:that's pretty clear now
14:35:02fanquake:fanquake has left #bitcoin-wizards
17:02:16dsnrk:"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:46tacotime:I wish cunicula was still around, he was a pretty fun dude.
17:07:18tacotime: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:20amiller:ugh, thanks
17:07:42tacotime:amiller, I wouldn't take it personally
17:08:26_ingsoc:amiller: I would. You know what to do.
17:37:33adam3us: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:30tacotime: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:06anddam:anddam has left #bitcoin-wizards
20:50:36dansmith_away:dansmith_away is now known as dansmith_btc
20:59:13Kawhi_desu_:Kawhi_desu_ is now known as Kawhi_desu
21:05:39iddo_:iddo_ is now known as iddo
21:22:24Vitalik_:Vitalik_ is now known as Vitalik
21:22:48Vitalik:Vitalik is now known as Vitalik__
22:18:53HobGoblin:HobGoblin is now known as Guest26820
22:40:27Guest26820:Guest26820 is now known as UukGoblin
22:43:32tempnick1371713:tempnick1371713 is now known as bitz