00:41:05	wallet421:	wallet421 is now known as wallet42
01:14:35	just[dead]:	just[dead] is now known as justanotheruser
01:45:56	justanotheruser:	justanotheruser is now known as just[dead]
02:53:15	just[dead]:	just[dead] is now known as justanotheruser
03:05:42	justanotheruser:	justanotheruser is now known as just[dead]
03:22:36	just[dead]:	just[dead] is now known as justanotheruser
04:45:41	EasyAt:	EasyAt is now known as EasyAt|Sofa
04:54:10	justanotheruser:	justanotheruser is now known as just[dead]
05:12:16	just[dead]:	just[dead] is now known as justanotheruser
05:30:18	Luke-Jr:	andytoshi: should I try to get you a ticket⁇
05:31:07	maaku:	maaku is now known as Guest63600
06:44:36	justanotheruser:	justanotheruser is now known as just[dead]
08:10:36	ebfull:	i'm wondering if this idea has been explored at all with developers
08:11:01	ebfull:	right now PoW is used to identify the block which is committed at a particular time (and the transactions it's committing at that moment)
08:11:25	ebfull:	but it has the disadvantage of leaving all of the transactions that occur before the 'next block' unconfirmed, and in limbo (could be double-spent)
08:12:01	ebfull:	what if PoW was used to identify a node which had the 'permission' from the network to begin streaming which transactions they are committing to the UTXO
08:12:04	gmaxwell:	you propose to equipt people with time machines so they can know about the future? blocks are found instantly...
08:12:28	ebfull:	mmmm let me explain it
08:12:38	gmaxwell:	ebfull: then then that node could give out multiple feeds of this history in order to make you think that transactions had been confirmed which hadn't.
08:13:17	gmaxwell:	and could do so indefantly into the future, e.g. years later replacing the content of transactions to a node pulling the chain, with what you've described so far.
08:13:59	ebfull:	ok what i'm saying is, you mine a block which contains your public key, if you're lucky to mine it it's relayed to everybody very fast
08:14:18	ebfull:	now nodes listen for signed messages that the miner uses to demonstrate it has committed a transaction (hash) to the UTXO
08:14:23	ebfull:	but it includes maybe like a sequence number in it
08:14:44	ebfull:	you could prove if the miner is trying to feed multiple accounts of UTXO state to the network at a given time
08:15:09	ebfull:	if he is, then the entire block is discarded and the miner loses their reward naturally
08:15:41	ebfull:	this way, as soon as the miner mines the block, and until the next miner mines a block, transactions are being 'confirmed' (with some degree)
08:15:57	gmaxwell:	I don't see what you think you've accomplished here.
08:16:23	gmaxwell:	Transactions already flow through the network and you can't tell for sure if they'll stay in the commitment or not until later.
08:17:07	gmaxwell:	and you still haven't suggested how the process stops such that the miner can't keep adding transactions forever (thus invalidating future miners signatures)
08:17:31	ebfull:	the block contains a reference to the last transaction the miner saw the previous miner submit to the network
08:17:57	ebfull:	nodes ignore the 'committment' signatures the previous miner propagated right after this reference
08:18:05	gmaxwell:	which could just be the first one, meaning the next miner can happily remove all the transactions and replace them.
08:19:20	gmaxwell:	Perhaps you should think it through completely and address these details and post it up, rather than leaving me to discuss guesses at what it might do. :) I don't think this is an especially promising area since everything I've heard that sounded like it turned out to be broken, but I've been wrong many times before.
08:19:36	ebfull:	no i've thought of that already lol
08:20:15	ebfull:	witness miners could be involved in asserting which transaction they saw last propagated by the miner
08:20:16	jcorgan:	if the blocks don't contain any transactions, how does a node later on join the network and catch up with what the network consensus of the history is?
08:20:31	gmaxwell:	And please be clear on what you hope to gain over the current process and demonstrate that you know that mining is effectively instantanious and doesn't involve any fixed delay.
08:22:15	ebfull:	too many points being raised before i can even fully write the idea down and explain the purpose
08:22:19	gmaxwell:	ebfull: "witness miners" ? so some(?) parties that decided I left out too many transactions from the prior block? How do you decide this? another nested blockchain? :)
08:23:56	ebfull:	not a nested blockchain, perhaps in the sense that every 10th block contains the public key of the next miner, and in between are blocks which checkpoint the miner's signed committments that they've witnessed
08:24:18	ebfull:	or perhaps just blocks in between which meet a lower target
08:24:22	ebfull:	not every 10th block
08:24:34	ebfull:	sorry higher target*
08:24:50	ebfull:	basically the point of what i'm doing isn't to prevent double-spends
08:25:05	ebfull:	it's so that point of sale transactions can be 'cleared' quickly with some merit
08:25:27	ebfull:	right now you can't say with any confidence how much of the hashrate is actually preparing to commit a transaction until you see the block
08:25:37	gmaxwell:	... then why the complexity ... p2pool already solves this
08:26:11	gmaxwell:	(or, rather, currently gives you a nice public gauge of hashrate— it could also bind consensus but it doesn't already)
08:26:52	gmaxwell:	ebfull: though the merit for 'fast' clearance will never be especially good, because you cannot guarentee global communications instantly.
08:26:53	ebfull:	lol
08:26:56	ebfull:	that's true
08:26:59	gmaxwell:	(not in an anonymous system)
08:28:05	ebfull:	yeah i guess if most miners were using p2pool or it was baked into the protocol it would allow us to determine confidence in a transaction's commitment
08:28:42	gmaxwell:	you don't even have to change them to use p2pool so much as just have them publish similar data in a similar way... if you do just want a measurement.
08:29:05	gmaxwell:	and it's also nicely compatible with the existing system.
08:29:09	ebfull:	yeah
08:29:17	ebfull:	what inspired the idea i posted moments ago was an even worse idea
08:29:45	ebfull:	that is, making miners publicly commit to include a transaction in the next block
08:29:58	ebfull:	within a merge mined chain with smaller difficulty than main chain
08:30:26	gmaxwell:	though I'd like to see you write up your streaming stuff some more. I'm not sure the construction is analyzable... maybe you get something interesting out of the ability to invalidate their subsidy if they conflict.
08:31:03	ebfull:	they could redeem the 'stales' to increase the target of the next block they are trying to mine
08:31:22	ebfull:	and if they lie and don't include transaction, proof of that lie can be used by any node
08:31:53	ebfull:	but this just adds so much overhead and messes with difficulty adjustment in ways i can't imagine so i tried thinking of other ways to make commitment faster
08:32:40	gmaxwell:	you're vastly overcomplicating that.
08:32:41	ebfull:	basically my streaming idea was just letting the miner say "seq 1 tx " "seq 2 tx " ... until the next block is discovered and a new miner begins streaming the commitment
08:32:45	ebfull:	yeah i know
08:33:45	ebfull:	i don't know what you mean by
08:33:50	ebfull:	maybe you get something interesting out of the ability to invalidate their subsidy if they conflict.
08:36:13	ebfull:	sigh yet another pipe dream demolished by gmaxwell :P
08:36:17	ebfull:	thx for walking me through it
11:40:53	hno:	Is it normal that the network have periods of this bad luck? Two times today with about one hour to next block (ca 70 and 50 min)
11:43:25	airbreather_1:	airbreather_1 is now known as airbreather
11:44:47	sipa:	#bitcoin-dev please
11:44:56	sipa:	this channel is about post-bitcoin development
13:37:01	andytoshi:	Luke-Jr: yeah, i'll be around, that'd be cool
14:53:54	maaku:	maaku is now known as Guest24413
16:44:46	WOODMAN:	morning
16:45:54	WOODMAN:	any jobs exist in the world of bitcoin?
16:46:09	pigeons:	try #bitcoin-hosting
16:46:13	WOODMAN:	research/media/?
16:46:17	WOODMAN:	thanks pigeons
16:46:47	WOODMAN:	im interested in new business development and promotions
16:46:56	WOODMAN:	done cooperative advertisement programs
16:47:07	WOODMAN:	would rather take on the status quo
16:47:12	WOODMAN:	than work for the corporation
16:47:17	WOODMAN:	ill check it out
16:47:51	pigeons:	yeah this isnt the channel
16:49:18	WOODMAN:	wha tis the "research" going down here?
16:49:37	pigeons:	take a look at the topic for starters.
16:49:47	WOODMAN:	ideas for the future
16:49:54	maaku:	maaku is now known as Guest82279
16:49:57	WOODMAN:	that could entail number of things
16:50:03	WOODMAN:	including new business development and media
16:50:07	WOODMAN:	andd prommotions
16:50:10	pigeons:	no this is technical
16:50:39	WOODMAN:	technical doesnt help gain momentum
16:50:48	WOODMAN:	look at the flaws at litecoin for example
16:51:00	pigeons:	there is a place for everything, and this place is for technical research
16:51:09	WOODMAN:	theyd just assume cover it up so mainstream gets screwed
16:51:29	WOODMAN:	this is your job you do for a career?
16:52:34	michagogo|cloud:	WOODMAN: If you want an idea of what this channel is, see http://download.wpsoftware.net/bitcoin/wizards/
17:56:14	jtimon:	andytoshi reading this http://download.wpsoftware.net/bitcoin/alts.pdf very well written, tell me when is finished so I can tweet about it (I hope Freicoin doesn't appear as a an example but maybe based on another macroeconomic school or something ;) )
17:56:41	jtimon:	s/example/example of economic stupidity
17:59:15	gmaxwell:	jtimon: I've always thought that freicoin was one of the more justified alts (along with namecoin), in that it's trying to achieve something different... even if the differences turn out to be bad.
18:02:08	jtimon:	gmaxwell thank you (of course I think the differences turn out to be good), anything that changes the hasing impeding merged mining already looks suspicious to me, so yeah, I would also say nmc and frc are the "good ones"
18:05:08	sipa:	i agree; i personally don't find economic changes that interesting (independent of godd/bad, just my personal interest), but at least freicoin isn't "stupid"
18:10:30	gmaxwell:	I'm sure if I went digging through frecoin I'd find some more conventional altcoiny changes that I'd have an issue with, but I think that anything who's main point of depature justifies their existance is allowed to make their own mistakes in the details.
18:16:19	iddo:	sipa: gmaxwell: i bumped an old thread on txn malleability, please respond there when you can, i'm curious:) https://bitcointalk.org/index.php?topic=405200.0
18:17:28	sipa:	iddo: you may want to read https://gist.github.com/sipa/8907691
18:17:55	iddo:	ok looking...
18:18:08	pigeons:	the main altcoiny change in freicoin that i also think gmaxell might not like is the difficulty adjustment filter, but it was designed and tested for what friecoin needed and seems to do a good job
18:18:57	gmaxwell:	iddo: that proposal is severely broken and would require a really deep redesign with a lot of difficult to reason about compromises.
18:19:47	gmaxwell:	pigeons: I think their choise of filter is bad, just from a DSP perspective... I worry about its overshoot creating problems, but since its working in practice I don't see too much reason to whine about it.
18:20:27	gmaxwell:	the multiprecision integer stuff in it looked scarry to me.
18:20:37	gmaxwell:	But I'm not sure how much that impacts the consensus code.
18:21:05	iddo:	gmaxwell: ok but i'm trying to understand why exactly it's broken, are there more severe problems than the scenario i described in thread (assuming that we were designing a new cryptocurrency from scratch) ? maybe reply in thread when you have time, so other can see the reasons
18:21:52	sipa:	gmaxwell: what problems do you see with it?
18:22:05	sipa:	for a from-scratch designed altcoin, i would certainly consider it
18:22:18	gmaxwell:	sipa: has the problem of not being able to selectively conflict.
18:22:35	iddo:	btw that paper is also bad for unrelated reasons, the protocol in figure 3 doesn't enforce the ZK proof to be inside the MPC, so a corrupt party can just switch his share, i.e. their description is sloppy..
18:22:51	gmaxwell:	e.g. say you have 10 1btc txouts with a common scriptpubkey.
18:23:24	iddo:	hmm
18:24:06	Guest82279:	Guest82279 is now known as maaku
18:24:37	gmaxwell:	You use 5 of them to pay alice, and 4 of them to pay bob. Then alice complains "hey, this txn isn't confirming, please add fee and reissue, otherwise I'm going to have to take back the icecream I just sold you" ... so you do.. and oops. alice gets paid twice and bob not at all.
18:25:13	maaku:	gmaxwell: at some point I would like to pick your brain about difficulty adjustment filters
18:25:19	maaku:	we're not locked into the one we're currently using
18:25:21	phantomcircuit:	gmaxwell, as of today you cant really conflict at all since they wont be relayed
18:25:26	phantomcircuit:	unless you have a special deal
18:25:47	sipa:	maaku: my general feeling about them is "simpler is better" (and more formally: more linear == better)
18:26:26	sipa:	gmaxwell: the individual input coins still have unique identifiers
18:26:34	sipa:	gmaxwell: they just don't depend on signatures
18:26:50	gmaxwell:	sipa: ah if you're only talking about the signatures then the _only_ issue that remains is that not all signatures are equal.
18:26:59	gmaxwell:	(that I'm aware of)
18:27:25	sipa:	it sort of makes signatures "attachments" to transactions that aren't committed to
18:27:49	gmaxwell:	I'd certantly make the signature an attachment the question is commiting to it.
18:27:51	sipa:	so seeing a transaction with an invalid signature means it's not necessarily an invalid transaction - someone could just have replaced the signature
18:28:19	sipa:	but apart from that, i don't see any problems with it
18:29:03	andytoshi:	jtimon: don't worry, i agree with gmaxwell's assessment of freicoin (and i sometimes wonder if it's really good for economic analysis because coins do not have indeterminate states, i.e. there are no ancient massive utxos threatening to shock the system)
18:29:03	gmaxwell:	e.g. I mentioned this on #bitcoin-dev? two weeks ago. e.g. say that a coin can be redeemed in one of two ways— those ways may be legally or technically pretty distinct. e.g. was the coin released by the president or was it released by the board of an org. Did the signature reveal a challenge string or did it not?
18:29:40	andytoshi:	jtimon: also you and maaku are completely NOT incompetent charlatons ;)
18:29:57	maaku:	also the multi-precision math stuff had me worried as well, but deterministic floating point calculations is somewhat a requirement for demurrage calculations...
18:30:29	sipa:	maaku: it's certainly better than using ieee 754 floating point :)
18:30:55	gmaxwell:	actual IEEE-754 is fine. :P too bad it's impossible to reliably gain access to on common platforms. :P
18:30:58	maaku:	i decided it was better to add dependencies on MPFR and GMP (which are cross-platform, deterministic by design), even though those are some big added dependencies...
18:31:07	maaku:	i'd rather not take the risk of consensus mistakes
18:31:17	gmaxwell:	maaku: yea, has some risk of the issues we've had with openssl however.
18:31:19	sipa:	maaku: libsecp256k1 will add GMP too, to bitcoin
18:31:41	gmaxwell:	e.g. that its authors don't guarentee quite the level of determinism we need. Hard to analyize.
18:32:22	gmaxwell:	e.g. internal represenation is not determinstic, and maybe something there gets exposed— a behavior difference when the size of the object is different.
18:32:50	gmaxwell:	...
18:32:50	gmaxwell:	10:32 < vocodork> lnovy: though afaik scrypt and sha256 start from the same elliptic curve math
18:33:24	maaku:	gmaxwell: yeah, at some point I want to pull out the handful of functions we actually use and do those as a separate library w/o platform specific optimizations
18:33:27	sipa:	gmaxwell: ?
18:33:32	michagogo|cloud:	gmaxwell: huh>
18:33:36	michagogo|cloud:	s/>/?/
18:33:41	Luke-Jr:	[18:22:51] e.g. say you have 10 1btc txouts with a common scriptpubkey. <-- I don't think it's a problem if this breaks
18:33:44	jtimon:	re: filters, if you have a deterministic way of evaluating filters, I would be happy to evolve a neural network to maximize the "reward" on that creiterion
18:34:19	iddo:	i'm not sure that i understand the first problem that you were discussing, about signature "attachments"
18:34:39	gmaxwell:	iddo: Sounds like I was confusing the proposal with a broader one people make.
18:35:29	gmaxwell:	iddo: Some people suggest leaving out the input txid entirely. It sounds like that this was only proposing leaving the signatures out... in which case my concern is exactly the same as yours.
18:35:51	maaku:	jtimon: isn't that basically what we did in selecting parameters for our current filter?
18:35:58	gmaxwell:	I don't think it's such an issue though, since you could just have two IDs. The ID with everything and the ID without the signature.
18:36:06	gmaxwell:	and use the ID with everything where thats applicable.
18:36:09	maaku:	we manually did a hill-climbing beam search of parameter space
18:36:10	iddo:	gmaxwell: ok... but sipa and you did mention signature "attachments" that i didn't udnerstand...
18:36:14	gmaxwell:	However, this doesn't really solve malleability at all.
18:36:36	gmaxwell:	iddo: sipa means leaving the signature outside of the transaction itself, just a bit of data that proves the transaction valid that you carry along with it.
18:36:40	maaku:	jtimon: the larger issue I think is seeing if we should have selected an entirely different category of filters
18:36:56	iddo:	ahh
18:37:21	gmaxwell:	However, this doesn't really solve malleability at all.
18:37:35	jtimon:	maaku there's an equivalent neural network for any filter of any category you can think of
18:37:38	gmaxwell:	Because we intentionally want to permit varrious kinds of malleability.
18:37:52	gmaxwell:	jtimon: doesn't mean you'll ever find it.
18:37:53	gmaxwell:	:P
18:38:14	iddo:	hmm
18:38:19	gmaxwell:	linear filters all have nice closed form least squares optimizations if you can actually name the properties you want.
18:38:22	jtimon:	gmaxwell: if you have a criterion, I'll find it ;p
18:38:30	tacotime:	tacotime is now known as tt_texas
18:39:00	gmaxwell:	iddo: e.g. as soon as you author an ANYONECANPAY transaction all that behavior tidying goes out the window.
18:39:35	gmaxwell:	sipa: could make commiting to the signature just a flag in the transaction.
18:39:44	iddo:	gmaxwell: what kinds of malleability are good to permit?
18:40:06	jtimon:	you really just need to extend this interface https://github.com/jtimon/preann/blob/master/src/genetic/task.h
18:40:06	jtimon:	here's an example for generic classification taks https://github.com/jtimon/preann/blob/master/src/tasks/classificationTask.h
18:40:47	gmaxwell:	iddo: all kinds are good when you want them. An obvious case is when you want to allow people (e.g. the reciver of a transaction) to later add fees. This can be important for a locked transaction left in storage for a long time.
18:41:07	iddo:	ahh
18:41:38	gmaxwell:	(and I think if I were to build a new bitcoin I'd add _more_ of those mechenisms... as the existing ones are a bit blunt)
18:42:16	gmaxwell:	including, perhaps, just having the signature itself fully decide what its checking in the transaction.
18:42:23	jtimon:	well, this function is probably more useful to undesrtand whet I mean by a deterministic creterion https://github.com/jtimon/preann/blob/master/src/tasks/classificationTask.cpp#L30
18:42:50	gmaxwell:	e.g. "I sign this coin to be spent in any transaction which pays at least 1 BTC to 1apple or 1dog"
18:43:17	gmaxwell:	jtimon: I think we're all familar with machine optimization. :)
18:43:46	jtimon:	gmaxwell ok sorry
18:48:18	jtimon:	my point is, I have no idea what kind of filter is best, but it's a certainty that there's an equivalent nn which is imo easier to find, you don't have to analize each filter category separatedly
18:49:29	gmaxwell:	jtimon: having spent basically 15 years working with machine learning regularly in my work, I don't share your enthusiasm.
18:49:49	gmaxwell:	Its fine as a last resort or when you don't know at all what you even need to start with.
18:50:47	jtimon:	gmaxwell and it's not fine when...? because...?
18:51:32	gmaxwell:	but the training in all of these things is at best a local optimization, e.g. if you try to find filter coefficients with back propagation you'd never find one that doesn't ring— even if the objective loves that, where as adopting a slightly different filter structure eliminates 90% of the dimensions and promises that every filter won't ring.
18:51:47	jgarzik:	Humans continues to be surprised cheap, for complex tasks ;p
18:51:52	jgarzik:	[*continue
18:52:03	jtimon:	gmaxwell I'm not using back propagation but genetic algorithms
18:52:22	jtimon:	no local minimum problems
18:52:43	gmaxwell:	jtimon: there is only no local minimum problem if your dimensionality is very small.
18:53:49	gmaxwell:	with hundreds of dimensions it never is. Maybe you find a good solution, maybe you don't. Reducing the dimensionality in advance via knoweldge of the structure of the problem usually makes things hugely more effective.
18:54:03	jtimon:	gmaxwell you can create random individuals at each step apart from using mutations and cross-over on the existing ones
18:54:39	gmaxwell:	yes so? go use your genetic optimization to go find my ECC private key. :)
18:54:54	jtimon:	maybe it takes too much time to get the absolute optimal solution but it's not about the algo getting stuck
18:55:42	jtimon:	good point (hmm, maybe I actually try... ;) )
18:56:26	gmaxwell:	jtimon: e.g. say that the good solutions are all laying in the hyperplain when 1/4 of the dimensions are exactly 0 and another 1/4 are exactly 1. and there are only bad solutions surrounding the good ones. It is very very unlikely— like guessing my private key— unlikely to ever probe the good space.
18:56:41	andytoshi:	;;later tell nsh here is a short writeup about satoshi-chain based timelock encryption being impossible in real life but easy in CRS: http://wpsoftware.net/andrew/blog/?post=impossible-crs
18:56:41	gribble:	The operation succeeded.
18:56:54	gmaxwell:	And at least in my expirence this crops up all the time once you get beyond probablems with 6 or so dimensions.
18:57:15	gmaxwell:	problems*
18:57:43	gmaxwell:	so I think that optimization techniques are seldom a replacement for trying to reduce the problem structurally.
18:57:45	jtimon:	gmaxwell yeah I got your point with your ECC example, at that point you're practically doing a random search with the completely new individuals
18:58:19	gmaxwell:	jtimon: right its an extreme example because the space is completely non-differentiable.
18:58:59	gmaxwell:	filters in particular seem to be hard to search for, at least in z-space or in direct taps because they're quite numerically sensitive.
18:59:49	gmaxwell:	maaku: the fact that the filtering isn't on regular uniformly sampled time series data throws out a lot of my expirence and intution.
18:59:52	jtimon:	still I think nn + ga has lots of unexplored potential, one day I'll find time to train my go player that beats human pros with it ;)
19:02:19	jtimon:	I tend to assume "time tends to infinitive" very often, which is not realistic in too many cases
19:02:49	jtimon:	s/inifinitive/infinite
19:04:41	midnightmagic_:	midnightmagic_ is now known as midnightmagic
19:06:35	adam3us:	so there's no particular unknown around malleability now right? ie plug all of the tolerant decoder issues from openSSL, define a single canonicalized valid encoding. the remaining crypto question is if ecdsa is non-malleable now that negative s is declared invalid. people assume so but no proof i guess.
19:07:03	gmaxwell:	adam3us: andytoshi was trying for a proof but hasn't found one. he does appear to have one for schnorr.
19:08:05	adam3us:	my define the problem away solution to avoid dealing with that question was to hash the public key not the signature. maybe that creates problems? there is no 1:1 commitment between block hash, tx, and txid then.
19:08:07	gmaxwell:	adam3us: but it depends on what you mean by unknown. All thats stuff just solves the known issues for regular sighash_all transactions with common pubkeys. Do something unusual and it's either unknown again or provably 'unsolvable'.
19:09:30	adam3us:	gmaxwell: hm what is that a complexity argument? to complex to be categorically sure? we need hard non-malleability for dependent transactions to be secure for smart contracts.
19:11:11	andytoshi:	how do you hash the pubkey but not the sig? then the txid algo needs to know the semantics of the input scripts no?
19:11:12	gmaxwell:	adam3us: you can intentionally write transactions which are _inherently_ malleable. It's a feature, not a bug.
19:13:42	adam3us:	andytoshi: i mean if the addresses are one use, and people writing dependent transactions for smart contracts could reasonably enforce that. then a txid hash replacing the sig for the addr that made it seems equally unique, non-malleable and not to assume the crypto level sig is non malleable
19:15:32	adam3us:	gmaxwell: ok and your example was increasing fees later if something gets stuck. so rather that the tx author can choose up front whether a tx is malleable or not by design. seems slighty conflicted.. for a dependent tx you have to prevent that, and then dependent tx can get stuck because it cant be malleated to add extra fees? or can extra fees be defined as not changing the txid?
19:16:22	EasyAt|Sofa:	EasyAt|Sofa is now known as EasyAt|Stool
19:16:47	andytoshi:	so you are suggesting referencing utxos by their hash rather than txid:index?
19:17:27	gmaxwell:	adam3us: they can decide.
19:17:37	gmaxwell:	But that doesn't eliminate malleability as a concern.
19:18:13	gmaxwell:	andytoshi: you can't do that for the conflict-control reasons I mentioned previously.
19:19:30	adam3us:	andytoshi: no just changing the serialization the txid is computed over to be the address, not the signature. ie its a way of saying for serialization purposes any signature from this key is viewed as valid and equivalent. ie precisely what we want: that the siganture is just defined to be non-malleable not by crypto properties but by serialization definition
19:20:34	andytoshi:	adam3us: oh, gotcha, i thought you were suggesting parsing the signature to skip only the ecdsa part
19:21:40	adam3us:	andytoshi: to replace the ecdsa part of Q,r,s with an unambiguous serialization of "a sig by Q"
19:22:14	andytoshi:	ok, but right now the only thing that even indicates that you have a Q,r,s pair is the presense of OP_CHECKSIG
19:22:43	andytoshi:	so it seems like in doing this, your txid calculation can become intricate because it has to evaluate the script
19:24:11	adam3us:	andytoshi: well Q,r,s go into block and the txid now. i am saying Q,r,s go into the block and an (unverified and unverifiable) assertion that there was an r,s made by Q but not the actual r,s bits goes into the txid. if someone wants to vrify the sig, they go do that from the serialization of the tx in the block. the txid then doesnt even change if someone swapped s for -s is the point.
19:24:25	andytoshi:	as far khth
19:24:50	andytoshi:	(ssh connection dropped, sorry)
19:25:32	adam3us:	gmaxwell: "but that doesnt eliminate malleability" i am not understanding.. are you saying there is something inherently hard? or that it has to remain possible for the tx originator to chose malleable vs non-malleable on a per tx basis depending on the use case
19:25:48	pigeons:	pigeons is now known as Guest38203
19:26:20	gmaxwell:	The latter at a minimum.
19:28:10	andytoshi:	adam3us: ok, understood. i am just hung up on the fact that right now txid is a property of the serialization, with this change txid actually depends on the meaning of the data (eg if i OP_PUSH 70 bytes in an input script, but it's not an (r,s) pair, how is the txid calculation supposed to know this). but i guess that is an implementation detail
19:30:56	gmaxwell:	adam3us: Right and thats all well and find but it doesn't address two issues: the author of the transaction can (for good reason) not put parts of the transaction under the signature, and not all signatures are necessarily equal.
19:31:16	phantomcircuit:	gmaxwell, i demand signature equality!
19:31:33	gmaxwell:	For example, of a transaction can be satisfied with one key or another this may have huge significance to an external system.
19:32:42	Guest38203:	Guest38203 is now known as pigeons
19:35:01	adam3us:	gmaxwell: so you are exploring further the multisig case and that if the encoding is at the level of serializing "valid 1 of 3, multisig from keys Q1,Q2,Q3" and maybe someone cares that the sig from Q1 vs Q3. i was not really thinking of that level. but in that case would it not be an encoding of the actual sig slots present? eg serialization of "valid sig fom Q1" and "valid sig from Q2" however that gets encoded - a
19:35:09	ageis_:	ageis_ is now known as ageis
19:36:31	adam3us:	gmaxwell: at least that convention would result in a different txid depending on which keys were used, but within that malleated crypto-sig level are ignored
19:39:01	gmaxwell:	adam3us: it doesn't have to be key releated. The scriptpubkey could require you to provide a hash preimage for example.
19:39:51	gmaxwell:	if you're thinking about ECDSA you're thinking at the wrong layer I think— bitcoin transactions are not signed with ecdsa, they're signed with bitcoin script (that includes ECDSA)
19:39:53	adam3us:	gmaxwell: yes i am proposing something quite narrow tho. to replace the serialization of the bits of crypto-sig from Q,r,s to Q
19:40:27	andytoshi:	so you would have something like OP_PUSHSIG which the txid calc treats differently (because it is expecting an (r,s) pair instead of just raw data)?
19:40:31	adam3us:	gmaxwell: and analogous for each other crypto-sig type (schnorr etc) if the script doesnt involve a crypt-sig then this serialization is not used
19:40:46	gmaxwell:	yuck.
19:41:40	gmaxwell:	I'm yucky because its a bad layering violation.
19:41:42	gmaxwell:	it's also pointless, since conventional means can remove the malleability completely when you opt out of it without changing anything.
19:41:43	adam3us:	gmaxwell: i suppose the controversial thing would be tht there is a different serialization for txid hash purposes than for tx serialization
19:42:07	andytoshi:	suppose you had OP_PUSH_BUT_DONT_HASH, then you could push (r,s) without affecting the txid then push Q and have that affect the txid. would that get what adam wants?
19:42:14	gmaxwell:	adam3us: you couldn't even compute the hash without having a script execution engine.
19:42:37	gmaxwell:	andytoshi: no, because I just replace those with regular pushes.
19:43:02	adam3us:	gmaxwell: well. that was my point seemingly there is no proof of non-malleabiliy at the crypto level for dsa. we removed the s,-s one. but we dont know if there are others
19:43:32	adam3us:	gmaxwell: i dont mean to execute, just to serialize the script
19:43:41	andytoshi:	gmaxwell: if OP_CHECKSIG would ignore regular pushes for (r,s) then that might work without any layering violations
19:43:41	gmaxwell:	adam3us: but if you're talking about messy break everything incompatible hardforks: you just use schnorr and we have a proof.
19:44:02	adam3us:	gmaxwell: there being a serialize, deserialize and a txid-hash-serialize
19:44:09	adam3us:	gmaxwell: yeah there is that
19:44:33	adam3us:	gmaxwell: but that also is a layering violation: now its only proven safe for some sigs :)
19:44:33	gmaxwell:	adam3us: but your txid-hash-seralize has to do non-trivial parsing of the script, e.g. to figure out which values are r,s.
19:45:20	adam3us:	gmaxwell: yes. i suppose there are extremely light bits of code that try to understand as little as possible - enough to verify a tx id i guess.
19:45:45	EasyAt|Stool:	EasyAt|Stool is now known as EasyAt
19:46:48	adam3us:	so i guess what i am saying is some complexity, but it means you no longer have to care or think about a novel signature property (sig non malleability) that people dont consider as part of signature crypto proofs in other uses.
19:47:28	adam3us:	so from that point of view its more generic. no pointy bits sticking up from a lower layer that you have to be aware of.
19:47:40	gmaxwell:	adam3us: I can suggest something which is less of a mess there, which is to just drop _all_ the scriptsigs out of the hash if a bit is set that indicate that they aren't in the hash— they'd still get committed to in the block.
19:48:27	gmaxwell:	so applications which care which sig was used can still check it against the block.. and if the whole scriptsig is dropped out the hashing behavior is much better.
19:48:43	adam3us:	gmaxwell: that'd do it.
19:49:21	andytoshi:	fwiw then you do lose the commitment to the specific key used
19:49:43	gmaxwell:	andytoshi: it would be in the block.
19:50:13	gmaxwell:	(and I did suggest it as optional in the transaction, though I'm not sure if thats worth the complexity.)
19:50:15	adam3us:	andytoshi: yes. in dependent smart contracts sense you would be saying you dont care. and actually that *is* what the smart contract says
19:50:38	andytoshi:	adam3us: right, that's what i'm saying. but maybe there are contracts where you do care, it'd be nice to support that
19:51:00	gmaxwell:	it's in general a direction I've wanted these systems to go— being able to eliminate all signatures from the historic chain is interesting.
19:51:17	andytoshi:	for repudiability?
19:51:22	gmaxwell:	no, scaling.
19:51:27	gmaxwell:	though I'd only though of it in the sense of leaving a commitment and taking away the data.
19:51:36	gmaxwell:	most of a transaction size is the signature(s).
19:51:50	andytoshi:	adam3us: but i don't see how to support both cases (caring and not caring) without a bunch of complexity, so i guess if you want to support one or the other go with the simpler one
19:51:55	gmaxwell:	but for verification of the long ago the signatures are completely disinteresting.
19:52:30	gmaxwell:	andytoshi: well, caring can still be implemented via a block commitment, and I suspect thats enough for most caring applications.
19:52:42	andytoshi:	yeah, that's a good point
19:52:49	gmaxwell:	e.g. a seperate tree of signatures in the block.
19:53:30	gmaxwell:	(doing things like tearing out the signatures starts to seem even more appealing once you imagine using hash based signatures or SNARKS with moderately large proofs, or things like the 2 way peg which had long proofs)
19:53:35	adam3us:	gmaxwell: i was musing a week or so back (might have said something on here briefly) that you could hypothetically define an spv only system intentionally. eg you discard everything after some block height. (Or only the winning miners even see the data) and just trust the state.
19:54:04	gmaxwell:	adam3us: thats one of the things on my altcoin page. (also it's something I tried to get namecoin to do)
19:54:18	gmaxwell:	I have mixed feelings about it generally, certantly it has some applicablity.
19:55:43	adam3us:	gmaxwell: yes its a curious thing. because we defined some new ultimate level of assurance (broadcast and hashrate based sybil resistant assertions), we remain attached to using that ultimate assurance everywhere, even tho its costly and high assurance than any competing system in several ways (eg the sheer number of all full nodes fully verifying at significant cost)
19:56:28	gmaxwell:	yea... the fact that I'm aware that there is a tradeoff is why I'd ever think it worth bothering thinking about.
19:56:56	adam3us:	gmaxwell: maybe a symptom of the generic threat model observation (unrelated to bitcoin) that if your threat is undefined you protect against anything you could at any cost. where a specific threat you may feel more able to make tradeoffs and optimizations
19:57:51	gmaxwell:	the nature of bitcoin really encourages a very broad set of threat assumptions.
19:59:30	adam3us:	gmaxwell: my what-if spv-only variant was relating to committed transactions: what if you only disclosed transactions to winning miners, and everyone else relies on their spv assertion. then you could have privacy, and yet rely on the spv security (except that full nodes cant check, unless they win the hash race so its weaker)
20:01:41	gmaxwell:	sounds very trusty. E.g. "oh no, all these coins? they were really ours. see here the majority of the moment says so, trust us."
20:02:05	gmaxwell:	doesn't achieve much privacy either, unless mining is very centeralized. (and if it is, it still doesn't achieve much privacy)
20:02:07	adam3us:	a new what-if. so gmaxwell came up with 2-way pegs between chains. what-if you did a 2-way peg against a private-chain (open transactions like server) which is sort of semi-trusted to declare transaction ordering, but time-stamps its assertions (eg in the blockchain via a time-stamp merkle root) and is audited. a quieting period for returning pegged coins to the main chain, would give auditors time to provide proof o
20:03:00	gmaxwell:	adam3us: I mean, thats the whole point of my coinwitness thread anti-replay oracle stuff. But it's assuming that the rule for checking the transcripts on return is implemented as a ZK-SNARK proof.
20:03:01	adam3us:	gmaxwell: yeah it was a hokey idea. just a curiosity. poking around the edges because its disappointing that you seemingly cant get long term privacy from committed tx
20:03:21	adam3us:	gmaxwell: yes. committted tx + snark is the other direction.
20:03:27	gmaxwell:	adam3us: I think you can, if you just have a ZK proof of knoweldge .. yea.
20:06:17	adam3us:	so more on the 2-way-peg to private chain: whats the failure mode. i think the failure is someone completely DoSes all auditors for the duration of the quieting period. and presuming the number of auditors is less than the number of miners. is that worse than bitcoin vulnerability? maybe so because in bitcoin (via router hacker or DoS) people notice and react to hash-rate dips
20:10:15	gmaxwell:	*(in theory)
20:10:50	gmaxwell:	I don't think people really do react to hashrate dips today. ... but that can be just some software updates away from being true.
20:11:21	gmaxwell:	adam3us: you can reshape that, you just have it fail so the coins get stuck if the auditors are down.
20:11:30	gmaxwell:	e.g. by requiring an affirmitive action by the auditers.
20:11:48	gmaxwell:	and then you have the classic multisig-chaum-bank offchain model.
20:15:47	adam3us:	gmaxwell: yeah i thought of that but who are the auditors. it should be p2p and anyone-can audit.
20:16:27	gmaxwell:	well if you want privacy (without fancy zkp stuff) you can't have that. :)
20:16:29	adam3us:	gmaxwell: i guess you could have a mix of affirmative (i verified and see nothing wrong to this timestamp) and anonymous negative auditors
20:16:49	gmaxwell:	yes, if there is a queting period you could do that.
20:18:10	adam3us:	gmaxwell: so how do u feel that compares to a side-chain for zero-trust security. the open-tx server feels like a difficulty 0, single miner chain as an analogy (it has a monopoly authority to signing things rather than hashing them)
20:19:22	gmaxwell:	Well, I think that {too low}-diff pow and 'trusted signers' are very different kinds of insecurity that fail in different ways.
20:19:58	adam3us:	the security difference is less than i was thinking. the known trusted, must answer for tx to clear auditors feel like ripple gws: a group of static known entities k of n of which must reply for tx to clear feels bad/weak. central known things can be DoSed. also the block chain coming from the open-tx server is more easily DoSable as its in a known location / IP address etc
20:20:08	gmaxwell:	Too low diff pow is so vulerable to disruption that I'm not sure if it would be useful at any wide scale. vs a couple trusted signers scales to any size... it's just fairly brittle.
20:20:42	adam3us:	gmaxwell: yah i dont mean literally, just thta you could think loosely of a signature as a 0-diff hash with only one miner allowed (eg it has a secret key that prevents anyone else mining)
20:21:32	adam3us:	gmaxwell: (just as a mental statement to reason about open-tx server model vs block chain model)
20:21:33	gmaxwell:	adam3us: right though assuming you have two miners there are better (faster!) consensus mechenisms when you can enumerate the participants.
20:26:18	adam3us:	gmaxwell: you can think the main observation of open-tx is that its trivial for one node to scalably order tx; and reasonably easy for third parties to audit the non-double spent status (reordering) relative to an independent timestamp server (which could use bitcion hash rate to commit to its periodic merkleroot)
20:27:58	adam3us:	gmaxwell: however i think so far they envisaged escrowing btc and issuing btc ious at best via a "voting pool". being able to 2-way peg btc to an open-tx server that can be audited is a new variant with slightly better properties - there does not exist an escrow server nor a k of n pool of escrow server that could take all the btc
20:31:04	gmaxwell:	hm. I may not be following what you're proposing there then.
20:31:29	gmaxwell:	If it doesn't involve a K of N pool, how do you avoid pushing gigantic full transcripts into the blockchain?
20:36:24	HM:	oO
20:36:36	gmaxwell:	andytoshi: someone who needs your paper https://bitcointalk.org/index.php?topic=492969.0
20:38:53	andytoshi:	o.O i'll post it at him and spend a few hours working on it today..
20:40:06	adam3us:	gmaxwell: well ownership transfer of coins happens as usual (owner has to sign), blocks of tx are constructed. blocks are signed to indicate an assertion by the tx server that all the tx are valid. so in an even lighter spv sense you can just trust the assertion of the open-tx server. there are auditors who download all the blocks, validate them and shout loudly if the server ever misbehaves. now to move a pegged co
20:41:09	gmaxwell:	adam3us: to me that sounds like k of n pool but perhaps with a very active verifyable consensus thing going on in the pool?
20:41:11	adam3us:	gmaxwell: move pegged coin back to block chain, you provide a signed move tx to the block chain. during the quieting period anyone can step forward to prove something wrong about that. the proof could be a double spend (merkle path for two conflicting values) or something bigger and more basic like it doesnt add up
20:41:33	gmaxwell:	Okay thats interesting.
20:41:35	adam3us:	gmaxwell: well the k of n pool idea is that the pool actually controls the private keys of the escrowed bitcoins.
20:42:08	gmaxwell:	Have I shown you the interactive verifyable computation paper that shows that you can get verifyable computation which is secure if at least one server is honest?
20:42:12	adam3us:	gmaxwell: here the bitcoins are still owned by the user. so its still zero trust. your only way to get hacked is to suppress all dissent for the period of the cooling period.
20:43:40	gmaxwell:	Simple notion: Ask multiple servers to execute your x86 program or whatever and compute a hashtree over every instruction and state transition. They return you your answer and your hashroot. If all of the servers agree you're done.
20:43:47	adam3us:	gmaxwell: i think i may have read your description of it here. but i am more saying trust no one, than trust 1 of n
20:44:00	gmaxwell:	If the servers disagree you can use log2() probing to find out who is lying.
20:44:15	gmaxwell:	adam3us: well I think actually you're not.. you're saying these k of n servers are building a transcript.
20:44:27	adam3us:	gmaxwell: i see so it has some similarity with open-tx audit model
20:44:46	gmaxwell:	and you can then redeem coins on the blockchain.. and if your redeem is invalid you can go start showing parts of the transcript to the block chain to convince it that its invalid.
20:45:35	gmaxwell:	which actually sounds a lot like that kind of transcript model to me. two people have compeating claims about what the transcript permits... they can't both have followed the rules, so eventually with enough queries you can show that one is lying.
20:45:36	adam3us:	gmaxwell: well i'm saying there is a single open-tx server, that is semi-trusted to do the right thing, but heavily audited, and anyone can provide proof of misbehavior. if proof of misbehaviour happens, all coins are moved back to the block chain rebuilding up to the point before the double-spend happened. and a new server is chosen
20:46:33	gmaxwell:	okay, I see. thats interesting, but one problem there is that what happens if you attack by bloating the history so that they can't be moved back? (e.g. there is now 500 gbytes of history)
20:48:03	adam3us:	gmaxwell: well u dont need the history, only for no one to have proof of valid object objection a candidate allocation
20:49:41	adam3us:	gmaxwell: i am thinking eg the auditor validation is relatively real time, and so if the open-tx server gets hacked or goes rogue they'll notice within minutes, broadcast their proof, and begin moving back . they just transmit the last indisputable utxo to the block chain
20:50:48	adam3us:	gmaxwell: if utxo is small enough to make that possible, they can thereby transact at higher rate on the open-tx server for the duration of time between server hack/server going rogue. so as the server doesnt gain anything by going rogue its not so useful to hack it.
22:29:36	HM:	HM is now known as HM2
22:32:39	gmaxwell:	after grepping my logs some apparently flexcoin was a ponzi-looking operation: http://bitcoin.stackexchange.com/a/1430
22:33:54	HM2:	weren't they going to pay interest or something
22:34:10	gmaxwell:	thats why I'm saying "ponzi looking"
22:35:30	HM2:	not if they were lending
22:35:54	andytoshi:	HM2: the interest came out of transaction fees rather than profit on loans, it was a bit of a silly model
22:36:15	andytoshi:	last i looked at it, when it first started.. maybe they changed since then
22:37:42	HM2:	not really a bank then was it
22:37:56	andytoshi:	nope
22:39:44	gmaxwell:	basically they charged fees on outbound tx, and putting funds in/out of a 'cold wallet'. And then paid those fees to people without funds in the cold wallet.
23:33:08	realazthat:	there is an exchange that gives 15% of their profits as "interest" of sorts
23:33:23	realazthat:	I think that is bad practice, since it encourages people to keep their coins with them
23:52:32	andytoshi:	gmaxwell: https://bitcointalk.org/index.php?topic=492969.0 my document is false and i don't represent the community, i'm afraid
23:53:18	gmaxwell:	lol
23:56:47	andytoshi:	i think i've had enough of that board, the stupidity is just too much and every single one of my posts has been met with "your bct post count is too low so i don't believe you"
23:57:47	zooko:	andytoshi: "that board" = bitcointalk.org ?
23:58:05	sipa:	protip: ignore bitcointalk
23:58:07	andytoshi:	zooko: yeah, i guess i mean "that entire site"
23:58:19	andytoshi:	sipa: thx, i'm still learning to be pro :P
23:59:47	gmaxwell:	andytoshi: keep in mind that I asked you specifically to respond to that guy because he was a fool.