| 00:43:56 | tdryja: | tdryja has left #bitcoin-wizards |
| 01:47:54 | ahmed__: | ahmed__ is now known as ahmed__zzz |
| 02:46:48 | petertodd: | phantomcircuit: "you can actually build a pos consensus system.... but history isn't permanent" <- and now you understand why pos needs checkpoints... |
| 02:47:42 | phantomcircuit: | petertodd, the checkpoints make the pos part irrelevant though |
| 02:48:50 | phantomcircuit: | i suspect you could make pos work if the thing as stake wasn't the unit in the system |
| 02:49:11 | phantomcircuit: | but probably that ends up looking like merged mining |
| 04:40:49 | phantomcircuit: | phantomcircuit: if someone tried to double-spend the consensus would destroy the coins? |
| 04:40:53 | phantomcircuit: | or whatever the rule was |
| 04:41:03 | phantomcircuit: | (that was the only one i could think of that made sense) |
| 04:41:10 | phantomcircuit: | (for limited values of "sense") |
| 06:25:52 | LarsLarsen: | LarsLarsen has left #bitcoin-wizards |
| 06:52:10 | tdryja: | Hi - I have a question for wizards if anyone's around |
| 06:52:39 | tdryja: | say you have 3 outputs, A, B, C |
| 06:52:49 | tdryja: | and 2 transactions, say tx1 and tx2 |
| 06:53:12 | tdryja: | tx1 is A -> B |
| 06:53:18 | tdryja: | tx2 is B -> C |
| 06:54:05 | tdryja: | assume output A is from a transaction a while ago and in a block |
| 06:54:41 | tdryja: | I know that tx1 and tx2 can appear in the same block; that is, tx1 does not need to be confirmed for its outputs to be spent |
| 06:55:09 | Taek: | this is probably a question for #bitcoin or #bitcoin-dev |
| 06:55:14 | tdryja: | my question is, does tx1 need to appear before tx2 within the same block for the block to be valid |
| 06:55:16 | fluffypony: | They can be chained, yes |
| 06:55:52 | tdryja: | hm, OK maybe I'll take it to bitcoin dev, sorry! |
| 06:57:31 | fluffypony: | tdryja: transaction order within a block is irrelevant, all transactions are assumed to have happened at the same time |
| 06:57:40 | fluffypony: | But yes, better suited to -dev |
| 06:57:56 | tdryja: | thanks |
| 06:59:06 | fluffypony: | (Although the fact that verifying tx2 requires verification of tx1 means they'll naturally be in order anyway) |
| 08:05:18 | barjavel.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 |
| 08:05:18 | barjavel.freenode.net: | Users on #bitcoin-wizards: andy-logbot lclc SDCDev xerox_ Emcy_ spinza moa jeremyrubin hktud0 waxwing alferz justanotheruser fanquake Logicwax RoboTeddy thrasher` harrow` b_lumenkraft TheSeven Crowley2k toffoo huseby samson_ p15_ Pan0ram1x cluckj Dr-G2 molec coiner jgarzik GreenIsMyPepper dgenr8 SubCreative forrestv Adlai shesek lmacken adam3us JustAnotherVogon GAit mkarrer prodatalab HM p15x luny amincd ryanxcharles dc17523be3 Starduster_ DougieBot5000 grandmaster |
| 08:05:18 | barjavel.freenode.net: | Users on #bitcoin-wizards: Xzibit17 hguux__ michagogo yrashk mariorz x98gvyn jaekwon melvster2 crowleyman gribble yoleaux deepcore go1111111 ebfull Luke-Jr PaulCapestany ajweiss pollux-bts espes__ melvster devrandom JonTitor null bedeho kyletorpey andytoshi amiller sl01 Transisto LeMiner binaryatrocity antgreen dignork Cory airbreather gavinandresen cornus_ammonis kefkius maaku sneak SwedFTP aakselrod EasyAt larraboj gmaxwell midnightmagic lnovy Iriez nsh bosma face |
| 08:05:19 | barjavel.freenode.net: | Users on #bitcoin-wizards: jonasschnelli berndj gabridome s1w PRab Apocalyptic DoctorBTC AdrianG roasbeef jcorgan Tiraspol tromp_ [d__d] kyuupichan NikolaiToryzin ahmed__zzz zz_betarigs_admi Visheate phedny yorick petertodd kanzure catcow Muis cfields Zouppen coryfields_ cryptowest_ kinlo crescendo wizkid057 otoburb wumpus phantomcircuit BlueMatt jaromil gwillen dasource fenn tromp eordano nickler Alanius BananaLotus guruvan ryan-c sdaftuar helo Hunger- runeks |
| 08:05:19 | barjavel.freenode.net: | Users on #bitcoin-wizards: null_radix epscy nanotube bliljerk101 starsoccer comboy Taek BrainOverfl0w so MRL-Relay azariah btc___ throughnothing @ChanServ brand0 davout NeatBasis mr_burdell d9b4bef9 a5m0 Anduck CryptOprah leakypat TD-Linux K1773R indolering warptangent veox Eliel Graet jessepollak lechuga_ warren gnusha heath wiz jbenet mappum eric catlasshrugged Keefe Oizopower platinuum Krellan kumavis artifexd smooth isis dardasaba Fistful_of_Coins morcos |
| 08:05:19 | barjavel.freenode.net: | Users on #bitcoin-wizards: dansmith_btc cursive Meeh fluffypony optimator livegnik |
| 08:26:21 | xerox_: | xerox_ is now known as xerox |
| 10:43:32 | ahmed__zzz: | ahmed__zzz is now known as ahmed__ |
| 10:54:50 | fanquake_: | fanquake_ is now known as fanquake |
| 15:19:54 | dEBRUYNE_: | dEBRUYNE_ is now known as dEBRUYNE |
| 16:20:03 | Anduck: | about the k-value thing we talked about earlier. could it be less fragile if the k-value deriving included block height or something? a bit like gauth |
| 16:27:13 | sipa: | using k = hash(msg + privkey) should be perfrctly safe, unless the hash function is (very) broken |
| 16:27:50 | sipa: | and is standardized in rfc 6979 |
| 16:30:29 | gmaxwell: | sipa: you're missing context. |
| 16:30:48 | sipa: | ok |
| 16:30:58 | sipa: | ignore me, in that case |
| 16:31:00 | gmaxwell: | :) |
| 16:32:57 | gmaxwell: | Anduck: no that cannot work. No amount of non-secret inputs can reduce the brittleness. |
| 16:33:19 | gmaxwell: | Anduck: You are ignoring the other point that I made; that having a one show signature does not actually do much useful; which doesn't go away even if the brittleness concerns were solved. |
| 16:33:49 | gmaxwell: | sipa: Anduck made some suggestion which basically reduces to "why not use a single show signature to deal with double spending" |
| 16:39:10 | Anduck: | can you elaborate this a little? gmaxwell| In terms of discouraging double spending the attacker will just arrange things so that the loss of the private key is no big deal. (e.g. by ripping off lots of people at once). |
| 16:41:03 | Anduck: | wouldn't the miner then be able to spend the coins anyway so trying double spending will always lose the coins to miner of the next block |
| 16:45:45 | gmaxwell: | Anduck: no, because the miner themselves can be the attacker, and because the second spend need not be widely distributed. The reciever is still totally screwed, so long as the attacker still got their good they're at least just as well off as if they hadn't double spent. Also, they can use the same coins to concurrently double spend against many parties. |
| 16:46:15 | gmaxwell: | E.g. they take 1 BTC, spend it 15 times, miner takes the coins, they get 4 BTC worth of goods from the three successful double spends. |
| 16:47:26 | Anduck: | ok. thanks |
| 16:47:46 | gmaxwell: | So the improvement is mitigated by (1) concurrent theft, (2) miner theft, (3) if the success rate is high, it still doesn't hurt to try and just hope that the winning miner didn't hera both. So this bounds the benefits pretty substantially; and then on the downsides you have the extreme fragility where you can't reissue a stuck spend, or you're screwed if someone accidentally sends twice to the |
| 16:47:52 | gmaxwell: | same address. :) |
| 18:23:27 | tdryja: | tdryja has left #bitcoin-wizards |
| 19:14:02 | dEBRUYNE_: | dEBRUYNE_ is now known as dEBRUYNE |
| 21:41:59 | execut3: | execut3 is now known as shesek |
| 21:52:21 | fluffypony: | gribble: seen op_mul ? |
| 21:52:33 | fluffypony: | that's not it |
| 21:52:42 | fluffypony: | !seen op_mul |
| 21:52:42 | gribble: | op_mul was last seen in #bitcoin-wizards 5 weeks, 1 day, 13 hours, 54 minutes, and 35 seconds ago: you can't beat the one that's in obfsucated javascript though. |
| 21:52:47 | fluffypony: | O.o |
| 21:59:23 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
| 22:15:11 | maaku: | op_mul has been disabled |
| 22:19:16 | fluffypony: | maaku: lol |
| 23:43:56 | arubi_: | arubi_ is now known as arubi |