00:07:03	op_mul:	isn't secp256k1 generally regarded as a good choice, if a little strange at the time?
00:08:16	nsh:	* nsh nods
00:17:26	gmaxwell:	op_mul: I think right now virtually anyone would regard it as retrospectively the best choice that could have been made at the time.
00:18:45	op_mul:	right. so this guy is saying, you dodged the bullet, quick go run back in front of it so you can get blown to bits. fabulous.
00:23:52	gmaxwell:	I can only imagine based on his prior output that he'll take any technical characteristic of bitcoin that he can understand and criticize it... if we'd used the NIST 256r I expect he'd criticize that too (in which case, I'd agree with him).
00:29:15	therealnanotube:	therealnanotube is now known as nanotube
00:58:06	op_mul:	gmaxwell: you fools, why are you adding more DSA, where's the lamport signatures??
01:51:58	omni:	omni is now known as Guest52835
04:25:55	maaku:	tacotime / Aquent: I don't think it's fair to call the fed-peg 'a centralized sidechain'
04:26:27	maaku:	it has a non-dynamic membership set signature (say 5-of-8 multisig) covering the movement of bitcoin _only_.
04:26:56	maaku:	a hypothetical asset issued on the sidechain, and what you do with the bitcoin on the sidechain is still 100% decentralized-like-bitcoin
04:31:42	maaku:	*movement of bitcoin between chains
04:58:54	Luke-Jr:	maaku: well, if the functionaries conspire and decide to be more than a functionary and make value judgements on what you do with bitcoin on the sidechain, it's *possible* that could change.
04:58:59	Luke-Jr:	but that's a lot of "if"s
05:01:37	maaku:	right, but the sidechain still isn't centralized
05:01:46	maaku:	just the process of moving btc on or off of it
05:15:16	artifexd_:	artifexd_ is now known as artifexd
05:37:51	petertodd:	gmaxwell: I met that guy two weeks ago; strikes me as an unrealistic and unwordly academic
05:40:41	gmaxwell:	amusingly most of the academics I know, and I know more than a few don't strike me as unrealistic or unduely unworldly at all (though sometimes there are some obvious expirence holes. "oh, you don't know why they do that? llleeemmmee tell you a story...")
05:43:23	omni:	omni is now known as Guest97870
05:46:18	phantomcircuit:	gmaxwell, is... is he serious about secp256r1 over secp256k1???
05:46:36	Luke-Jr:	maaku: my point was that "the sidechain" is "determined" by its "best block", but from a bitcoin-the-unit focused perspective, that "best block" is now decided by the functionaries rather than its real consensus mechanism - therefore (from that perspective), it can be argued to be centralised
05:46:59	gmaxwell:	well go look at his other stuff, a lot of it is wtf. That one is just nice because you don't need to know anything about bitcoin to know that it's an attack for the sake of attacking.
05:47:24	maaku:	Luke-Jr: the best block of the sidechain is not determined by the functionaries.
05:47:35	Luke-Jr:	maaku: it is from the perspective of someone who only cares about bitcoin-the-unit
05:47:37	maaku:	It's chosen by the miners.
05:48:01	maaku:	That's a warped perspective, which is my point.
05:48:09	Luke-Jr:	yes, but it is a perspective, nonetheless
05:48:44	phantomcircuit:	maaku, in theory miners can check the functionaries work, in practice probably not in a useful way
05:49:22	Luke-Jr:	phantomcircuit: well, it'd be the same as a reorg
05:49:26	phantomcircuit:	do you as a bitcoin miner really decide to not extend a block because you think the functionaries made a mistake in it?
05:49:34	gmaxwell:	phantomcircuit: in important point though is there isn't any ambigiuity about what they've agreed and promised to do.
05:49:49	maaku:	phantomcircuit: the point is that there are applications in the asset issuance space where bitcoin is kinda a side issue
05:50:57	phantomcircuit:	gmaxwell, can you expand on the pronouns there
05:51:08	maaku:	if what one cares about is the assets that are issued on the sidechain, and bitcoin is just a way of moving external currency in and out
05:51:31	maaku:	but a user really cares about the issued assets, then it is a bit disengenous to say that the sidechain is 'centralized' because moving bitcoin on or off it requries agreement from a gruop
05:51:52	phantomcircuit:	maaku, oh.. yeah that's accurate
05:52:37	gmaxwell:	phantomcircuit: ah, federation. It's clear what protocol the federation has agreed to follow, which makes them somewhat (legally, if not trustlessly) distinct from freeform signers.
05:53:00	phantomcircuit:	right
05:53:41	phantomcircuit:	i assume maaku was saying that bitcoin miners would reject blocks in which the functionaries violated that protocol
05:54:07	phantomcircuit:	that seems fairly unlikely without direct incentives to do so (and even then probably has scaling issues)
05:54:32	gmaxwell:	oh no. that isn't something I've ever seen anyone suggest as a thing before. It's technically possible.
05:54:49	phantomcircuit:	so practically as the federated peg exists today the bitcoin part of it is ... federated
05:55:16	gmaxwell:	we discuss in the sidechains paper a 'risk of softfork' where bitcoin miners reject 2wp transfers that are fradulent (which they can tell because they're also sidechain nodes); which is morally equivilent, I suppose.
05:55:17	Luke-Jr:	hm, it makes sense for miners who are interested in the sidechain to do that
05:55:19	maaku:	yeah, not what I meant to imply
05:55:45	gmaxwell:	Though it's posed as a risk since it compromises the intended isolation. (though it does have an advantage, security wise)
05:55:58	phantomcircuit:	maaku, good to know
05:56:44	Luke-Jr:	gmaxwell: it doesn't, though - as long as the blocks are valid, it's perfectly fine if miners reject tranactions like that
05:57:16	phantomcircuit:	Luke-Jr, this probably wasn't clear, but i meant rejecting blocks which have already been mined
05:57:20	phantomcircuit:	ie a softfork
05:57:34	Luke-Jr:	it may be ineffective when a miner who isn't doing it gets involved - but it gives the real sidechain an opportunity to do a double-spend of it
05:57:42	phantomcircuit:	which i think is what gmaxwell was referencing being in the paper
05:58:01	Luke-Jr:	so maybe the miner should not only reject the rule violation, but also get other functionaries to sign off on something double spending it
05:58:16	Luke-Jr:	although that requires M to be <= N/2
05:58:34	phantomcircuit:	hmm
05:59:13	phantomcircuit:	i guess you could have a separate threshold which did something like required all the functionaries to sign off as a panic button
05:59:22	gmaxwell:	phantomcircuit: yea, its in the paper with respect to the 2wp. Technically it could also be done with the plain functionary use; but I don't think of that as especially interesting; esp since it propagates instability.
05:59:32	phantomcircuit:	fraud proof gets published and a small number of the functionaries can hit the panic button
05:59:37	phantomcircuit:	but that could end poorly
06:00:33	Luke-Jr:	if the panic button is some kind of "wait for SPV/SNARK peg softfork", it might be okay - but that really complicates it IMO
06:01:15	phantomcircuit:	well and possibly screws with the incentives a bit much
06:01:29	phantomcircuit:	since a small number of functionaries can basically freeze the coins in such a scenario
06:02:24	gmaxwell:	well a cute thing you could do is have scriptpubys that look like N of N OR (timelock AND M OF N).
06:04:28	Luke-Jr:	it may be good to pick functionaries who explicitly are not organizational miners, so that colluding is necessary to break the setup
06:05:26	gmaxwell:	Luke-Jr: I don't like that just because everyone in Bitcoin-business should be mining.
06:05:29	gmaxwell:	(at least to some extent)
06:05:53	Luke-Jr:	gmaxwell: fair
06:06:35	Luke-Jr:	maybe require some policy where the entities managing the functionary don't also manage the miners
06:06:40	Luke-Jr:	?
06:07:50	gmaxwell:	it's not a concern so long as mining is reasonably well decenteralized (oops)
06:09:18	Luke-Jr:	gmaxwell: if the functionaries go rogue, it would help slightly if they were unable to get their fraud transaction mined
06:10:12	gmaxwell:	Luke-Jr: this is assuming that miners have taken it on themselves to IsStandard (or even softfork check) the validity. The former seems at least somewhat unlikely, and the latter is undesirable.
06:10:47	Luke-Jr:	well, aside from development time to implement it, the former seems ideal
06:10:58	Luke-Jr:	for miners who are already validating the sidechain
06:12:51	phantomcircuit:	gmaxwell, that's what i was originally thinking, but does the timelock stuff actually work now?
06:13:17	maaku:	gmaxwell: I like the timelock construction
06:13:19	phantomcircuit:	i thought petertodds patch was to make the an op you could do in the script system
06:13:19	gmaxwell:	phantomcircuit: whats needed for that is CLTV.
06:13:24	phantomcircuit:	yeah
06:13:34	gmaxwell:	But we'll have that fairly soon.
06:14:01	petertodd:	phantomcircuit: https://github.com/bitcoin/bitcoin/pull/5496
06:15:24	Luke-Jr:	not sure how timelock is this particular case
06:15:43	Luke-Jr:	seems more of a use for "ohnoes too many functionaries lost their keys in the same week"
06:17:16	phantomcircuit:	Luke-Jr, you hit the panic button, which sends them to potentially a different set of functionaries
06:17:43	Luke-Jr:	phantomcircuit: how does timelock help with that?
06:17:46	Luke-Jr:	panics can't wait
06:17:59	phantomcircuit:	the timelock is for the new functionaries to spend the funds
06:18:15	phantomcircuit:	oh i read what gmaxwell wrote wrong
06:18:16	phantomcircuit:	nvm
06:18:31	gmaxwell:	well they could be different keys, I suppose.
06:18:50	gmaxwell:	the notion there was to require unanimity normally, but if keys are destroyed you're not stuck forever.
06:18:56	Luke-Jr:	gmaxwell: but you need a way to trigger it immediately for this
06:19:01	gmaxwell:	But if some keys are lost, the unanimous group can sweep the funds.
06:19:01	Luke-Jr:	right, it works for that
06:19:20	phantomcircuit:	i dont think you can do what i was thinking, which is allow for n-1/m to send the funds to a new script which was itself timelocked
06:19:31	gmaxwell:	phantomcircuit: no, you can't currently.
06:19:36	phantomcircuit:	the idea being that hitting the panic button gives people some time to figure out what happened
06:19:43	phantomcircuit:	yeah i didn't think so
06:19:54	Luke-Jr:	for that, I think we'd really want ultimate-p2sh
06:20:05	Luke-Jr:	but by then, no need for functionaries
06:22:13	phantomcircuit:	you could have functionaries sign transactions in advance which move the funds to the panic p2sh address and simply have various functionaries not sign the transaction
06:22:34	phantomcircuit:	yeah i... think that would get the intended behavior if you had CLTV
06:22:48	Luke-Jr:	phantomcircuit: +1
06:23:33	phantomcircuit:	there's uh "details" about that which i haven't thought through
06:23:48	phantomcircuit:	such as whether you could do that without accidentally giving someone a full set
06:24:24	phantomcircuit:	oh you could put the functionaries address in part of the tx that gets signed
06:24:52	phantomcircuit:	neat
06:26:09	maaku:	phantomcircuit: you don't really need that in script. the functionaries could be keeping unbroadcast transactions which send all outputs to cold storage
06:28:36	maaku:	(using SIGHASH_SINGLE signatures so it's easy to rework as peg transactions come in)
06:33:54	phantomcircuit:	maaku, yeah but then any 1 functionary can do it
06:34:05	phantomcircuit:	you really want to have n/m where n is < the normal n
06:34:20	phantomcircuit:	but yeah if n is 1 then you can just do that
06:34:21	maaku:	that's what you want right?
06:34:48	maaku:	meh, the point of the panic button is to be easy to do
06:34:52	phantomcircuit:	maaku, not really since you might have lots of functionaries and only kind of trust them
06:35:07	phantomcircuit:	so allowing any one of them to hit the panic button might just be super annoying
06:35:10	maaku:	in the time it takes for N>1 functionaries to coordinate, the funds could be stolen
06:35:25	maaku:	there are out of band mechanisms to mitigate that
06:35:32	maaku:	the functionaries are going to be executing legal agreements
06:35:36	maaku:	there could be fees, etc.
06:36:42	maaku:	the point of the fed-peg is that you don't have to get this all sorted out on chain ;)
06:37:12	maaku:	while we work on a more DMMS, less trusted solution
06:37:12	phantomcircuit:	maaku, well i was thinking you'd convince miners to prioritize the panic button tx's
06:37:22	phantomcircuit:	it's a race either way though
06:40:53	omni:	omni is now known as Guest34222
07:53:49	Pan0ram1x:	Pan0ram1x is now known as Guest98671
09:05:16	orwell.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	orwell.freenode.net:	Users on #bitcoin-wizards: andy-logbot gribble Guyver2 paveljanik adam3us1 Guest98671 Luke-Jr aburan28 bosma prodatalab op_mul kumavis_ shesek Shiftos TheSeven maaku Dr-G2 d1ggy__ hashtag_ SubCreative RoboTeddy waxwing_ Greed bit2017 Adlai Aquent Graftec v3Rve Guest2104 nsh coryfields bsm117532 ahmed_ isis jgarzik BigBitz_ coutts BlueMatt cfields Anduck wallet42 GAit berndj Graet jaromil Guest29370 Eliel gavinandresen nanotube sl01_ PaulCapestany lclc hguux_ spinza
09:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: _Iriez artifexd bobke_ luny AdrianG_ Muis kanzure jbenet mappum lnovy prepost michagogo wizkid057 OneFixt koshii_ GibsonA digitalmagus gwillen kobud Quanttek Grishnakh samson_ kyletorpey CryptOprah dgenr8 btc__ Rynomster copumpkin ryanxcharles DougieBot5000 hashtagg Starduster wumpus [\\\] MRL-Relay Dyaheon- phantomcircuit MoALTz stonecoldpat morcos pi07r c0rw1n eric dansmith_btc tacotime NikolaiToryzin mkarrer ompik [d__d] Emcy toddf heath
09:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: go1111111 Transisto bbrittain husebyAFK DoctorBTC BananaLotus Apocalyptic EasyAt tromp espes___ null_radix hollandais midnightmagic starsoccer danneu catcow TD-Linux ryan-c roasbeef amiller smooth optimator_ mmozeiko Alanius epscy JonTitor fluffypony warren Krellan fenn LarsLarsen jchp nsh_ asoltys_ K1773R nickler_ a5m0 @ChanServ Meeh comboy btcdrak eordano Nightwolf gmaxwell pigeons andytoshi lechuga_ warptangent Fistful_of_Coins HM2 paperbot
09:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: Guest38445 iddo kinlo azariah yoleaux Logicwax s1w sneak harrigan sipa livegnik burcin tromp_ poggy Taek throughnothing petertodd crescendo so helo Keefe phedny BrainOverfl0w harrow
09:07:32	omni:	omni is now known as Guest88952
11:35:17	wumpus:	moxie, moxie, moxie, why you don't have a multiply instruction with 64-bit result, sec256k1 is horribly inefficient with all the calls to __muldi3
11:45:30	sipa:	wumpus: ow, yweah, expected...
11:49:08	wumpus:	also gcc generates code with conditional jumps in it for e.g. secp256k1_fe_mul_inner, for some reason, even though it should have no control flow. But gcc generating bad code for an experimental arch would be excusable, the lack of that instruction is worse :/
11:52:25	nsh:	wumpus, what code are you referring to?
11:53:01	wumpus:	field_20x13_impl.h ;-)
11:53:11	nsh:	ty
11:53:38	wumpus:	no just kidding, I'm referring to the code that moxie-moxiebox-gcc makes of secp256k1
11:53:45	nsh:	ah
11:54:30	nsh:	can conditional jumps in ECC multiplication lead to side channel weaknesses?
11:55:01	nsh:	(timing attacks)
11:55:08	wumpus:	yes, hence all the work put into making operations constant time
11:55:15	nsh:	* nsh nods
11:56:04	nsh:	presumably moxie processor is still up for revision
11:56:51	nsh:	but dunno how you'd do that. split the result over two registers?
11:57:08	sipa:	that's what happens on x86
11:57:25	nsh:	k
11:58:56	wumpus:	maybe Anthony would be open to the suggestion, on the other hand by now there are even hardware implementations, so the ship may have sailed. It is meant as a minimal architecture and multiply is expensive to implement.
11:59:48	nsh:	* nsh nods
12:00:15	maaku:	never heard of a processor that didn't offer a double-width result multiply
12:00:21	maaku:	does it have a divmod?
12:00:57	wumpus:	no, just separate div and mod IIRC
12:01:03	maaku:	yuck
12:12:20	wumpus:	powerpc has no double-width result multiply either, but at least separate mullw and mulhwu instructions
12:23:24	wumpus:	mips does have double-width result for multiplication, its multiply result goes into special low/hi registers, loaded by mflo/mfhi
12:25:06	wumpus:	sparc on the other hand didn't use to have a multiply instruction at all, but it specific lower-level instructions to implement multiply
12:28:00	wumpus:	the end result would be 64 bit, though
12:28:08	wumpus:	so yes, moxie is the odd duck out here
13:22:11	nsh:	any recommended books on distributed systems?
13:22:36	nsh:	(with strong theory, preferably)
13:25:38	wumpus:	* wumpus ponders a woxie architecture with secp256k1_ecdsa_verify instruction
13:30:37	nsh:	"woxie"++
13:31:19	nsh:	how are moxie instructions implemented/described?
13:31:49	nsh:	in some formal gate logic model or something higher?
13:38:33	nsh:	or is this the closest to a formal definition? https://chromium.googlesource.com/chromiumos/third_party/gcc/+/toolchain-minor-verified/gcc/config/moxie/moxie.c
13:38:50	nsh:	(nope)
13:39:58	sipa:	wumpus: ha
13:44:40	Eliel:	nsh: just out of interest, have you ever looked at reduceron?
13:44:52	nsh:	nope
13:44:58	nsh:	* nsh checks out
13:45:20	nsh:	oh, haskell on FPGA
13:45:39	Eliel:	basically, yes. Although, I suspect there are other languages it'd be a good fit for too.
13:46:10	nsh:	* nsh nods
13:46:51	nsh:	you'd think google would have done a bit of work on von Neumann widening architectures for all their mapreduce stuff
13:46:51	sipa:	wumpus: just ec mult instructions would probably be more flexible
13:47:09	wumpus:	nsh: there are some FPGA implementations, https://github.com/atgreen/moxie-cores
13:47:13	nsh:	ty
13:47:44	wumpus:	nsh: I'm sure they have, all of the large SV companies are busy with Intel and custom silicon, but what they're doing is probably a secret
13:48:10	nsh:	* nsh nods
13:48:24	wumpus:	sipa: that sounds like a good idea, a ec coprocessor
13:49:20	Eliel:	ah, looks like the development is ongoing :) https://github.com/tommythorn/Reduceron
13:50:51	wumpus:	whoa! Anthony replied, the lack of double-width multiplication result is an oversight and he's considering ways to add it to future a future revision
13:53:47	nsh:	oh, cool
13:55:17	wallet42:	wallet42 is now known as Guest35318
13:55:17	wallet421:	wallet421 is now known as wallet42
14:32:00	kanzure:	https://github.com/Tribler/dispersy "The elastic database system. A database designed for P2P-like scenarios, where potentially millions of computers send database updates around."
14:36:29	nsh:	kanzure, any (noncode) description?
14:37:45	kanzure:	no
14:37:59	kanzure:	i am still reading code
14:38:11	nsh:	some jibberjabber here: https://github.com/Tribler/tribler/wiki
14:38:37	kanzure:	they do not like docstrings
14:38:42	nsh:	* nsh smiles
14:39:03	kanzure:	ah they have some docstrings. just not everywhere. hrm.
14:40:21	kanzure:	"and reputation-management. All these features are implemented in a completely distributed manner, not relying on any centralized component..." hm.. wasn't reputation one of those things that doesn't work without centralization.
14:41:19	kanzure:	here are some papers they claim describes their reputation mechanism:
14:41:20	kanzure:	http://www.asci.tudelft.nl/media/proceedings_asci_conference_2010/asci2010_submission_14.pdf
14:41:23	kanzure:	http://www.pds.twi.tudelft.nl/~pouwelse/A_network_science_perspective_of_a_distributed_reputation_mechanism.pdf
14:42:20	kanzure:	er.... "Finally, a non-random structure means that the network is vulnerable to targeted strategic attacks on highly connected nodes. If an attacker provides the highly connected nodes with a contaminated content, then the content is spread very fast in the network. This is a concern that should be taken into account in future designs."
14:44:01	moa:	kanzure: distributed reputation is interesting proposition ... socially we already recognise such a concept, aka popularity, digitally it comes back to 'who' is voting
14:44:23	nsh:	(a well-resourced attacker can always use partitioning to create heavy hub nodes, which makes this worse)
14:44:36	kanzure:	popularity is actually a corruption of that
14:45:18	moa:	well popularity can be corrupted by centralised manipulation, misinformation, etc too ...
14:45:52	moa:	re-centralised
14:48:19	moa:	sometimes the majority can be dishonest, misinformed, have incentive structure perverted, etc
18:26:16	Eliel:	* Eliel wonders if it'd work that when there are two or more transactions spending the same input(s), The transactions are mined in a special doublespend transaction that takes only the inputs that have been double spent and to spend that transaction, you need to be able to satisfy every txout script in all txouts that either transaction had.
18:28:45	Luke-Jr:	Eliel: interesting
18:32:19	Eliel:	ah no, you can defeat that by deliberately making an infinitesimal input to doublespend. You'd need to include all inputs.
18:32:25	Eliel:	and that sounds risky.
18:40:49	Luke-Jr:	?
18:42:00	Luke-Jr:	Eliel: I don't see the risk
18:43:20	Eliel:	well, consider for example coinjoin transaction.
18:44:22	Eliel:	one participant wants to DoS the coinjoin process and does a double spend the moment it's being done.
18:45:11	Eliel:	everyone suddenly needs to jump through hoops to get their coins and it won't work if the cause of the problem won't cooperate
18:45:58	Luke-Jr:	ah, right :/
18:46:18	dgenr8:	Eliel: but either of the original txes is still valid by itself
18:47:11	Eliel:	umm, no, each of them has at least one of their inputs already spent.
18:47:31	Luke-Jr:	dgenr8: no, Eliel was suggesting a rule that if you can prove TxA and TxB are double spends, you can claim all of their inputs in a new UTXO which can only be spent by a transaction producing all the outputs of TxA and TxB
18:48:07	Luke-Jr:	so the original UTXOs would be destroyed, and the new UTXO would have a covenant
18:49:18	Luke-Jr:	Eliel: this could also screw up incentives, since now you can combine UTXOs without a fee potentially XD
18:53:07	dgenr8:	...can only be spend by satisfying all the outputs of TxA and TxB. As Eliel said, all the inputs would need to be included.
18:54:28	dgenr8:	this new thing itself would be in a race against the original spends
18:54:55	lclc:	lclc is now known as lclc_bnc
19:08:38	Eliel:	dgenr8: in a way, yes. However, any node with either of the original spends would move to mining this when they see the other spend. So it would have quite the advantage.
19:08:55	Eliel:	it'd drastically reduce the chance that a double spend succeeds.
19:10:13	Eliel:	The only point would be to make it unprofitable to even attempt to double spend.
19:10:23	dgenr8:	if miners behaved that way, double-spends after a few seconds would not succeed today
19:12:33	Luke-Jr:	Eliel: it doesn't make it unprofitable, though
19:12:47	Luke-Jr:	Eliel: worst case you pay who you paid. which was always a probability
19:15:21	Eliel:	Luke-Jr: well, the logical course of action for any merchant in this situation is to take the loss unless the double spender agrees to pay them a little extra for the trouble.
19:15:47	Luke-Jr:	Eliel: ?
19:16:18	Eliel:	a merchant should be financially able to take a loss of a single order but someone who needs to double spend is most likely not too rich.
19:17:06	Eliel:	end result -> double spends not profitable -> very few double spends.
19:17:23	Luke-Jr:	Eliel: petertodd's scortched earth thing does that too
19:17:33	petertodd:	Luke-Jr: lol, I was just about to say...
19:17:46	Eliel:	I might have missed that one :)
19:17:51	petertodd:	Luke-Jr: though credit goes to jdillon, not me
19:18:01	Luke-Jr:	Eliel: use CPFP to take your own transaction and respend 100% of it as fees
19:18:19	Luke-Jr:	Eliel: miners then prefer your version with the huge fee they can claim
19:18:40	petertodd:	or this version without CPFP: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05211.html
19:18:51	dgenr8:	even if the proof tx resulted in everything being burned, payment is only one side of the tx. double-spender's goal is to get something valuable in the real world
19:19:58	Luke-Jr:	dgenr8: double-spender's goal is to get something valuable in the real world *at no cost*
19:20:05	Luke-Jr:	dgenr8: in this case, he has to pay the full price
19:20:20	Luke-Jr:	no different than if he had made the purchase legitimately
19:20:29	dgenr8:	yeah, that's right
19:20:39	petertodd:	Luke-Jr: and with the k-overpaying version, you can make them pay more than full price if they double-spend: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05211.html
19:20:44	Eliel:	well, in a sane court, the attempt to double spend should be regarded as intent to defraud. Having to do more attempts to get any benefit will reduce the total profit a single scammer can make before getting caught
19:22:52	dgenr8:	petertodd: your prediction about nlocktime use shaking out the bugs system-wide seems to have been accurate
19:23:15	petertodd:	dgenr8: sigh, unfortunately...
19:23:19	Luke-Jr:	I was surprised by that. I'm pretty sure I've purchased via Coinbase before
19:23:32	Luke-Jr:	(and I've been using petertodd's patch there for years)
19:23:54	petertodd:	Luke-Jr: they seem to have re-broke; also if the tx is lucky enough to get mined you don't see the problem
19:23:55	Luke-Jr:	buuuuut… I may have poked Coinbase staff to get it through
19:23:58	Luke-Jr:	I forget
19:24:02	petertodd:	ahh, well there you go
19:24:09	gmaxwell:	Luke-Jr: the earlier version of the page was inoperable.
19:24:21	Luke-Jr:	gmaxwell: ?
19:24:36	gmaxwell:	Luke-Jr: there was an earlier version of the patch for a while that didn't set the seq number.
19:24:45	Luke-Jr:	oh, lol
19:25:06	petertodd:	seems coblee is of the opinion that reimplementing Bitcoin Core in production is a good idea too :(
19:26:15	petertodd:	gmaxwell: hahaha, oh I'd forgotten I'd fucked up that, stupid
19:27:40	op_mul:	petertodd: do we have a bitcoin company that doesn't test in production?
19:28:58	petertodd:	op_mul: heh, quoting coblee: "I wasn't at Coinbase when the decision was made to implement Bitcoin Ruby, so I can't comment on why we did that. This whole Bitcoin thing is an experimentation."
19:29:53	op_mul:	petertodd: seems what they really wanted is a bitcoin node that is powered by burning VC money.
19:30:11	op_mul:	not confirming fast enough! shovel in more hundreds!
19:30:27	petertodd:	op_mul: ...and they weren't willing to use the tried and true method of a steam engine
19:31:38	gmaxwell:	"N reasons why the spooks love Tribler" https://lists.torproject.org/pipermail/tor-dev/2014-December/007999.html fun examples of fractally broken cryptography outside of bitcoin.
19:32:22	petertodd:	you know, when you consider the probabilities, it takes either good luck or effort to write crypto that broken
19:32:36	petertodd:	the obvious thing these days is to use one of the easy libraries with sane defaults...
19:33:23	op_mul:	ECB mode ;-;
19:34:23	petertodd:	you literally can figure out that's a bad idea by skimming the wikipedia page...
19:34:56	petertodd:	there's like, pretty picturs and everything :/
19:35:08	op_mul:	they've hit on all the big ones
19:35:21	op_mul:	wrong AES mode, bad random, static IV
19:35:55	petertodd:	nah, they did miss one: they didn't call it TxOut
19:36:18	petertodd:	(ok, so that joke'd be funnier if they were a bitcoin wallet...)
19:37:27	op_mul:	I do like that they called it StrongRandom, very similar to SecureRandom that has plagued Bitcoin.
19:37:35	Eliel:	petertodd: by the way, you can always require a certain minimum of total inputs if you want to accomplish the total k effect in what I proposed. It also doesn't suffer from the problem that the payee could decide to burn your coins even without a double spend.
19:38:44	petertodd:	Eliel: well, once you start assuming scripting language changes the sky's the limit...
19:40:01	Eliel:	well, true, this is a hard fork change.
19:40:22	petertodd:	Eliel: no, soft-fork change, it's just something you'd have to opt-into at the wallet level, IMO a much better idea than changing everything
19:40:53	Profreid_:	Profreid_ is now known as Profreid
19:41:05	op_mul:	might as well add in OP_CORN (this node dispenses hot melted butter)
19:41:49	petertodd:	op_mul: with respect to the consensus provability of OP_CORN, we already have that, it's called OP_NOP1, 2, 3, ...
19:43:04	gmaxwell:	Eliel: double spending is not always intent to defraud. For example, you might have just been a doofus with multiple copies of the same wallet.
19:43:39	op_mul:	petertodd: maybe we need to find a way to have proof of lipid. I quite like the mental image of system admins rushing to stem the flood of butter pouring out of their server racks every time somebody uses it in a transaction.
19:43:43	Eliel:	gmaxwell: yes, that defense works... as long as you don't repeat it.
19:43:55	dgenr8:	in these proof txes, outputs would appear to sum to greater than inputs, even aside from fees. if they are spendable that has a downstream impact
19:45:43	op_mul:	petertodd: you can go further too, OP_TIMISM might be fun.
19:45:55	petertodd:	op_mul: OP_TIMISM?
19:46:42	petertodd:	gmaxwell: perfect example: http://respends.thinlink.com/ <- most of the double spends have zero or trivial fee increases
19:47:07	op_mul:	petertodd: you'll get it eventually.
19:52:19	dgenr8:	op_mul: maybe he finds it opprobrious
19:53:05	op_mul:	dgenr8: when really it's the OP_POSITE
19:57:13	petertodd:	...that took me way too long...
19:58:29	btcdrak:	stahp! with the opcode joke!! >.<
19:59:33	petertodd:	OP_ACITY, OP_AL, OP_AQUE, OP_CODE, OP_EN, OP_ENNESS, OP_ERAND, OP_ERATE...
19:59:44	petertodd:	...OP_US
20:00:01	op_mul:	petertodd: now you get it!
20:02:02	btcdrak:	definitely too much OP_IATES
20:04:48	bitjedi_:	bitjedi_ is now known as bitjedi
20:27:21	kanzure:	.title https://news.ycombinator.com/item?id=8780313
20:27:22	yoleaux:	Tribler "decentralized BitTorrent" software's crypto is completely broken | Hacker News
20:27:44	kanzure:	ah... this explains their weirdo handwaving about security in their "consensus" protocol.
20:28:33	petertodd:	the great thing about the Tor consensus protocol is you can meet it at conferences in person
20:29:21	kanzure:	""Take that book Applied Cryptography that's on your bookshelf and burn it. Do that as a commitment to really learning crypto. But absolutely don't read it. If you don't read it, you have nothing to unlearn, so you're much better off.""
20:29:34	kanzure:	petertodd: i'm not familiar with what tor consensus is
20:29:55	petertodd:	kanzure: it's a majority of ~10 or something trusted people basically
20:29:59	kanzure:	what is there to agree about?
20:30:06	faraka:	how does ripple consensus work?
20:30:09	kanzure:	it doesn't
20:30:12	petertodd:	kanzure: what are and are not valid Tor routers that you should use
20:30:21	kanzure:	petertodd: thanks
20:30:36	faraka:	coultn't ripple have implemented proof of stake as a way to mint tokens?
20:31:05	petertodd:	kanzure: Tor is *not* a decentralized system, it's a highly centralized distributed system carefully designed to minimize legal and operational risks and ensure no one person can compromise you
20:31:48	kanzure:	petertodd: i have been reading tor source code lately, wanting something like python-bitcoinlib for tor, or some other way to split out non-tor-specific things, etc.
20:31:59	kanzure:	(just in the interest of curiosity, primarily)
20:32:10	petertodd:	kanzure: yeah, IIRC there is a python Tor library
20:32:13	petertodd:	isis: ^
20:32:24	kanzure:	the tor developers mentioned a disinterest in every having anything approximating a shared library or any library with an api
20:32:49	petertodd:	yeah, I dunno the politics behind that (or even if that's true)
20:32:56	petertodd:	there is a java library among other things
20:32:57	kanzure:	hmm i don't have the link, so let's assume it's not true for the moment
20:33:25	kanzure:	ah maybe https://trac.torproject.org/projects/tor/ticket/1967#comment:2 but i am still reading
20:33:49	petertodd:	haha, I've heard stories about "bee"
20:33:52	kanzure:	"You're not the first and you won't be the last to suggest it - You're simply the most annoying"
20:33:55	petertodd:	or I should say "bee!!!!"
20:35:40	petertodd:	kanzure: the explanation of "encourage people to use the socks mechanism" doesn't surprise me much
20:36:13	kanzure:	faraka: ripple could have just avoided implementing a consensus protocol like that and used a signing system to publish their ledger
20:36:34	faraka:	would a signing system be equally fast?
20:36:47	faraka:	do you mean multisignatures?
20:37:05	petertodd:	kanzure: I thought ripple basically *was* a signing system, but with a bunch of hand-waving and misdirection?
20:37:14	kanzure:	petertodd: yes, but faraka doesn't know that
20:37:29	kanzure:	petertodd: apparently faraka also doesn't know what a centralized solution looks like
20:37:52	faraka:	you are right kanzure
20:38:01	kanzure:	petertodd: so here's one guess... maybe people just genuinely aren't aware of the possibility of centralized implementations, and so they fixate on the marketing they have been exposed to regarding decentralized consensus. maybe we just need to make centralized concepts more obvious?
20:38:33	kanzure:	(insert various explanations here like "well it's just a blackbox to most users")
20:38:38	petertodd:	kanzure: shitty marketting - e.g. "federated" sidechains :)
20:39:27	petertodd:	kanzure: would certainly help to have some best-of-breed implementation of that stuff... I'm working on one myself
20:39:36	kanzure:	someone is going to crack this problem and then suddenly people are going to be really excited about central limit order books at paypal or something :)
20:39:47	kanzure:	just because they didn't know about it previously
20:40:51	gmaxwell:	petertodd: well, I thought it was just a lack of awareness. But in talking to more people, at least the people building stuff they certantly see what they're doing as a (perhaps cargo-cult-grade) regulatory dodge. Makes convincing them to be frank much harder.
20:41:39	petertodd:	gmaxwell: of course, can you blame them? ethereum likes to call ether "paying for computer services"...
20:41:55	gmaxwell:	Unfortunately many of the same people have also been having private mettings with regulator people, and so they have all this 'secret' knoweldge, and so anything anyone else says is worthless.
20:42:14	adam3us:	petertodd: fuel or gas or something? etherfuel!
20:42:19	gmaxwell:	So you can't even have a conversation to feel out the boundaries and determine if there is a more frank presentation that still ticks the boxes.
20:42:53	petertodd:	gmaxwell: which has me in a funny position, having *also* talked to those regulators/bankers, and not giving a damn how I describe it
20:43:11	kanzure:	hmm, how much do you think it's them attempting a regulatory dodge versus people (especially users) just being genuinely unaware of centralized ledgers being possible?
20:43:39	gmaxwell:	kanzure: I think the users don't know its possible. Or in particular don't know that middleground security is possible.
20:43:54	petertodd:	kanzure: you realise, even *within banking* there's a certain amount of desire to deny that secure centralized ledgers are possible
20:44:03	kanzure:	is it wrong of me to suggest people should be going for that middleground when they have a broken consensus attempt
20:44:13	gmaxwell:	e.g. middleground = more secure than TRUST MAGICAL TUX TO BEHAVE PERFECTLY CORRECT AND HONESTLY WITH NO ABILITY TO REVIEW
20:44:25	petertodd:	gmaxwell: so, what's the extreme of that position?
20:44:52	kanzure:	sure i certainly realize there are incentives to avoid centralized ledgers
20:45:18	petertodd:	kanzure: see, I'm saying that there are incentives to make centralized ledgers *insecure* even within conventional finance
20:45:37	kanzure:	users don't know that either way
20:46:01	gmaxwell:	yea conventional finance demands capabilities which are basically incompatible with security. The whole regulatory and security framework of conventional finance basically demands unbounded reversability.
20:46:32	petertodd:	yeah, and the smartest regulators get that security lets you bypass the need for identity
20:46:55	petertodd:	gmaxwell: also, note that "unbounded reversability" is also coupled with a desire to make it possible for that reversibility to be *secret*
20:47:16	gmaxwell:	It doesn't help that while it's very very clear that middleground security is technically possible but the legal enviroment around it is less clear than the technology. Of course, there are plenty of parties who are happy to make fully centeralized non-secure systems, and ignore or manage the legal risks, but thats where they're focusing their spend: on the politics, and not on making the tech f
20:47:18	petertodd:	gmaxwell: if it was just unbounded reversability that could be accomodated
20:47:22	gmaxwell:	undimentally more sound.
20:47:35	kanzure:	wouldn't you just publish blocks from your central ledger and therefore make reversals more obvious?
20:48:05	petertodd:	kanzure: that's the thing: banking ledgers are nearly always 100% not secured by any form of cryptography at all
20:48:37	moa:	but laws and guns
20:48:37	petertodd:	kanzure: I mean, hell, I was being told about a financial institution maintaining hundreds of millions of dollars worth of accounts literally on an excel spreadsheet - that was the master record
20:48:38	kanzure:	well, i certainly don't mean to say that existing bank ledgers should just be dumped on the interwebs
20:48:50	kanzure:	ther'es probably lots of "dirty laundry" on those ledgers (just from stupid implementation quirks)
20:49:19	kanzure:	i would count a spreadsheet as an "implementation quirk" hehe
20:49:29	nsh:	remember that stupid implementation quirk in 2008... good times....
20:49:52	kanzure:	yes nsh discovere that the federal reserve kept its ledger in drupal
20:49:55	kanzure:	nsh++
20:50:08	petertodd:	kanzure: pen and paper would seriously make me feel better
20:50:21	nsh:	(my semiserious point is that if you try to apply any infrastructure, no matter how advised, that makes it more difficult to magic wealth out of the system, you'd going to run into resistance)
20:50:29	nsh:	*how well-advised
20:50:35	nsh:	*you're
20:51:02	nsh:	(and magicking wealth here is commensurate with distributing risk for the purposes of maximising leverage)
20:51:07	petertodd:	nsh: it's not that level of conspiracy stuff - you literally have to be able to accomodate courts ordering you to remove things off your ledgers in secret, among many other crazy requirements
20:51:14	nsh:	heh
20:51:20	nsh:	good point
20:51:25	kanzure:	seems to me like users that recognize that (which, by the way, i doubt they do), should be banding together around "allowing good implementations of centralized ledgers to exist" or "making lots of good centralized ledgers with fallbacks" instead of "trying to corrupt bitcoin with broken consensus implementations"
20:51:55	petertodd:	kanzure: fact is, this stuff works well enough 99% of the time...
20:52:06	kanzure:	so, here's a thought
20:52:12	kanzure:	okay so they are using it as a regulatory dodge, fine
20:52:16	kanzure:	let's say there's even a demand for that
20:52:22	moa:	nsh it was actually aug 07 2007 that the credit markets initially seized up ... it took a year of denial that the ledgers had stopped function before it made it into mainstream
20:52:42	kanzure:	if their protocols are bsaically just centralized anyway and broken and such,
20:52:53	kanzure:	why not just make random crappy code generators that don't involve "consensus theories"
20:53:01	kanzure:	and then they can make up whatever broken web of lies they please?
20:53:03	nsh:	moa++
20:53:15	petertodd:	++moa
20:53:44	petertodd:	kanzure: heh, you mean excel spreadsheets?
20:53:47	kanzure:	er, ledgers can continue to function even during times of market downturns, especially when your assets stop paying interest
20:53:53	kanzure:	petertodd: hehe sure
20:54:08	kanzure:	petertodd: "decentralized proof of stake... in a spreadsheet"
20:54:20	moa:	kind of a 'fork' happened in their protocol, once branch was using mark-to-market the other mark-to-model
20:56:35	dgenr8:	* dgenr8 notes that bitcoin pays more interest than the swiss franc at -.25%
20:56:51	kanzure:	petertodd: the point being (of that idea) to just redirect all of that regulatory-dodging away from producing things marketed that end up wasting your time (claims about security, consensus, etc.)
20:57:31	gmaxwell:	petertodd: it's a bit circular there, in that courts are going to demand you do whatever you can do. It doesn't follow that if you couldn't courts would still demand it, and we have a rich tradition of taking actions specifically to tie our hands for integrity reasons. (E.g it's a reason companies have data retention policies that make them not retain data they're not required to retain past so
20:57:37	gmaxwell:	me threshold... limits the costs created by discovery)
21:22:44	siraj:	i like the idea of stellar but not the implementation - has anyone envisioned a more trustless version of stellar?
21:23:49	adam3us:	siraj: yeah its called bitcoin
21:24:27	adam3us:	siraj: maybe a better question what is it you like about it better than bitcoin?
21:24:54	petertodd:	gmaxwell: well, the impression I get talking to these people is that it's not at all clear courts won't demand the impossible with regard to finance
21:25:20	petertodd:	gmaxwell: which basically means "it's not impossible to change your systems"
21:25:51	adam3us:	petertodd: maybe you heard there is or was a law somewhere that said pi = 3
21:26:16	petertodd:	adam3us: this is worse than that, because going from a secure ledger to an insecure one isn't exactly unthinkable
21:26:25	siraj:	adam3us: I'm working on an escrow service and want as many customers as possible. As such, I want to accept as many different currencies as possible. I want to have one balance that all currencies can be sent to. Stellar appeals to my need by promising that. Without it, I'd have to have multiple balances.
21:27:17	kanzure:	you are only accepting the stellar currency, in that context
21:28:17	petertodd:	siraj: and since you want to accept multiple currencies, you're going to involve third party trust anyway so... ever thought of using paypal?
21:28:53	adam3us:	siraj: maybe people dont want to be exposed to stellar exchange risk
21:29:31	kanzure:	anyway, this seems off-topic, you should consider asking #bitcoin
21:29:35	siraj:	kanzure: the stellar currency and the accompanying 'gateway' system that acts as a decentralized exchange between all currencies. Bitcoin needs a system of decentralized exchange.
21:29:51	kanzure:	that's not decentralized. they just call it decentralized.
21:30:06	siraj:	kanzure: true
23:32:24	BigBitz_:	BigBitz_ is now known as BigBitz
23:40:50	austinhill:	austinhill has left #bitcoin-wizards
23:59:38	beamlaser:	what's the word on factom?