sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
belcher has quit [Read error: Connection reset by peer]
GAit has quit [Quit: Leaving.]
belcher has joined #bitcoin-wizards
<stevenroose>
I have to go in a sec, but I'm wondering about this: Is it possible to create a transaction that spends an input you own, specifies an output for only a part of the money and allows whoever you pass the transaction to to add another output and broadcast it?
<stevenroose>
something like sighash_nooutput
AaronvanW has quit [Ping timeout: 250 seconds]
veleiro has joined #bitcoin-wizards
<maaku>
stevenroose: in a limited way with SIGHASH_SINGLE
Newyorkadam has joined #bitcoin-wizards
<maaku>
stevenroose: better ways to accomplish the same would be to have a generalized signing mode where you explicitly indicate which outputs and inputs are being included
<maaku>
or more wizardly, something like one-way aggregate signatures
Jeremy_Rand_2 has quit [Ping timeout: 260 seconds]
<stevenroose>
Wiki says about sighash single "Think of this as "sign one of the outputs-- I don't care where the other outputs go".
<stevenroose>
"
<stevenroose>
Seems like the trick? However it seems to become more complicated when multiple inputs are used
<maaku>
stevenroose: sighash_single means your signature covers *only* the output at the same corresponding index
<maaku>
strictly speaking that is exactly what you asked for
<maaku>
(this is what lighthouse uses)
<maaku>
but in real life you often care about 2+ outputs
<CodeShark>
It's so ugly to select output by position...would be a lot nicer to have a way of specifying the set over which you're signing and use a canonical sorting for inputs/outputs :)
DougieBot5000 has joined #bitcoin-wizards
<maaku>
i'm not sure the canonical ordering is required...
<CodeShark>
not required but still nice
<CodeShark>
removes a symmetry
<CodeShark>
Allows more compact representation and improves privacy
<CodeShark>
and makes the representation unique
<stevenroose>
The reason I was thinking about this was for outsourcing tx broadcasting for timelocked contracts for lightning
<stevenroose>
I imagine some kind of sub-network where users can broadcast timelocked transactions by leaving a small part of the output open for the broadcaster to spend
<stevenroose>
So that they can safely go offline
<stevenroose>
So yes, a more generic way should be nice, since there will probably be more inputs and outputs involved
<wasi>
a fix sorting mechanism for inputs and outputs is required anyway in order to eliminate transaction malleability, or not?
Jeremy_Rand_2 has joined #bitcoin-wizards
Peter00 has quit [Quit: Peter00]
ThomasV has quit [Ping timeout: 272 seconds]
ThomasV has joined #bitcoin-wizards
ieephm has joined #bitcoin-wizards
dEBRUYNE_ has quit [Quit: Leaving]
ieephmm has quit [Ping timeout: 256 seconds]
voxelot has quit [Remote host closed the connection]
ThomasV has quit [Ping timeout: 250 seconds]
murch has quit [Quit: Leaving.]
jcluck has joined #bitcoin-wizards
cluckj has quit [Ping timeout: 256 seconds]
<Taek>
bsm117532, bsm1175321: When the host announces themselves, they include an IP address and a public key, and burn some coins (burning not implemented yet). Then, when you connect to them, they assert it's them by signing a challenge (also not implemented yet).
<Taek>
The file contract specifies addresses that recieve the payment if the proof is valid.
<Taek>
So, it doesn't matter who submits the proof, the same person gets paid
roconnor has joined #bitcoin-wizards
Jeremy_Rand_2 has quit [Ping timeout: 240 seconds]
Newyorkadam has quit [Quit: Newyorkadam]
tromp_ has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
Jeremy_Rand_2 has joined #bitcoin-wizards
tromp_ has quit [Remote host closed the connection]
bityogi has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
priidu has quit [Ping timeout: 240 seconds]
HostFat has quit [Quit: Leaving]
Ylbam has quit [Quit: Connection closed for inactivity]
<bsm1175321>
CodeShark: I'm wandering toward the idea that providing proof that a UTXO is unspent is an incentivize-able action, and therefore storing (some of) the blockchain/UTXO set is incentivize-able.
<bsm1175321>
I'm currently stuck on the fact that the proof is a Merkle path, and can be signed to indicate compensation, but any intermediary or the receiver can strip off my signature and replace his own. How do I provide a proof that simultaneously cannot repudiate the fact that I created it?
jcluck is now known as cluckj
Howdy__ has joined #bitcoin-wizards
<bsm1175321>
CodeShark: thus I'm heading toward an incentive model that directly incentivizes (a) fast transmission of blocks -- by measurement of siblings using braids and (b) storage of pieces of the blockchain, and (c) PoW in the usual way...
<bsm1175321>
maaku: Still processing iSHAKE128 but from my reading it may not provide any advantage over a Merkle path. Thus much of the logic can be worked out using a Merkle path as an example. (It might be faster, and I would like an explicit guarantee of collision resistance as the output set grows -- by allowing the proof size to grow)
<bsm1175321>
Per my conjecture earlier, I think the proof size probably must grow as log(n) -- which I would like to prove or otherwise convince myself of...
tromp_ has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
<bsm1175321>
Taek: So you're not using any kind of PoW there, it's kind of a PoS hybrid... This problem seems harder than I first imagined.
chris___ has joined #bitcoin-wizards
Jeremy_Rand_2 has quit [Ping timeout: 260 seconds]
chris___ is now known as glitch003
<bsm1175321>
Taek: FWIW that puts you in the camp of counting nodes, and therefore, Byzantine Fault Tolerance, for which no more than 1/3 of nodes can be faulty/fraudulent.
Newyorkadam has quit [Quit: Newyorkadam]
adnn_ has joined #bitcoin-wizards
adnn has quit [Ping timeout: 252 seconds]
belcher has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
conner_ has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 256 seconds]
bildramer has joined #bitcoin-wizards
espes__ has joined #bitcoin-wizards
Jeremy_Rand_2 has joined #bitcoin-wizards
<Taek>
bsm1175321: no, the consensus is driven by POW. The file contract is a type of transaction, and is not used to secure consensus
wallet42 has joined #bitcoin-wizards
<Taek>
storage hosts don't play a role in mining
<bsm1175321>
Taek: There's a separate problem to be solved here: In PoW, miners commit to their own coinbase in such a way that makes it impractical for anyone else to replace their coinbase with a payout to themselves. But if storage providers get paid for storage, how do they make a similar cryptographic commitment to the results of queries? The description you provide above is effectively a PoS algorithm (in proving stora
<Taek>
I'm not seeing how it's a PoS algorithm? It's a system with identity. Hosts have identity and reputation, and you choose between hosts based on your own view of how likely they are to keep your data vs. how much they are charging
<Taek>
though, reputation is measured by each client individually. You don't trust any information others tell you about a host, you only trust what you observe
<Taek>
PoS to me implies that somehow people are voting on which hosts should get data, which is not the case. Each client fully controls which hosts they upload to
<bsm1175321>
Ok, strike PoS. But you are in the class of literature for Byzantine Fault Tolerance.
voxelot has joined #bitcoin-wizards
Jeremy_Rand_2_ has joined #bitcoin-wizards
<Taek>
Depends on what definition you are using. To recover data, you do require that at least some fraction of hosts are still storing the data you gave them, and are willing to upload it to you upon request
<Taek>
But it's not limited to 1/3 - it's related to the redundancy scheme that you use
<bsm1175321>
Taek the 1/3 is related to the notion that nodes can lie.
<bsm1175321>
It's not a redundancy factor.
<Taek>
what are the nodes able to lie about? There's no part of the protocol that relies on trusting messages from other nodes
<bsm1175321>
Though I think the classic Byzantine results do not include the possibility that validity of results could be proved.
justanotheruser has quit [Read error: Connection reset by peer]
Jeremy_Rand_2 has quit [Ping timeout: 276 seconds]
justanotheruser has joined #bitcoin-wizards
<bsm1175321>
exactly...do you know of any literature which deals with that case? It's a particular restriction on the BFT case. (FWIW I'm categorizing BFT = counting nodes)
<Taek>
I do think that MitM is a risk, but only if the communications aren't established correctly. But, it does seem complicated/mistake-prone
<Taek>
Sia doesn't count nodes?
arowser has quit [Quit: No Ping reply in 180 seconds.]
<bsm1175321>
Then how do you know you have the whole dataset?
<Taek>
it collects a set of nodes, weights them by desirability, and then chooses the most desirable
arowser has joined #bitcoin-wizards
hazirafel has quit [Ping timeout: 245 seconds]
<Taek>
you give the data to some set of nodes of your choice, then you request data from them. In the very simple case, you give each node a full copy of the data. Then, if any of the nodes is willing to upload your data to you, you can get the data back
<Taek>
in that case, you only need 1/N nodes to be honest, for any size N. But as N increases so does the overhead
<bsm1175321>
So Sia is not a guaranteed data storage mechanism?
<Taek>
no, it relies on at least some subset of nodes being willing to upload your data to you - but they are incentivized to do so
<bsm1175321>
So IOW you need one node to be honest, and you can validate his result?
<Taek>
(because you pay them to retrieve your data)
<Taek>
yeah
<bsm1175321>
Ok
<bsm1175321>
Hmmm.
<Taek>
for Sia, we use M/N Reed-Solomon coding, so you actually need N nodes to be honest
<Taek>
*M nodes
<Taek>
but I do think that's a reasonable requirement
<Taek>
*as long as the incentives are set up correctly
<bsm1175321>
Can you validate individual nodes, including the coding, or can you only validate after decoding (including possibly false participants and decoding failure)?
<Taek>
you can validate the nodes indiviually, including the coding. You keep the Merkle hashes of each piece
<bsm1175321>
Ok
glitch00_ has joined #bitcoin-wizards
glitch003 has quit [Read error: Connection reset by peer]
<bsm1175321>
FWIW in case you weren't following the previous conversation, I'm looking for a way to prove storage of (part of) a large UTXO set, including a signature of some kind that includes how someone should be compensated. So I guess your proof is of the "bonded validator" type. Can a recipient of data strip off the headers from a downstream storage node and claim a reward for himself? Why or why not?
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
bityogi has joined #bitcoin-wizards
conner_ has quit [Remote host closed the connection]
sparetire has quit [Quit: sparetire]
frankenmint has quit [Remote host closed the connection]
frankenmint has joined #bitcoin-wizards
glitch00_ has quit []
midnightmagic has quit [Ping timeout: 240 seconds]
frankenmint has quit [Remote host closed the connection]
midnightmagic has joined #bitcoin-wizards
<phantomcircuit>
bsm1175321, why?
<Taek>
I don't know how to safely manage compensation if it's not direct. We manage compensation by saying 'if anybody proves that they have X, Alice gets paid'. Only Alice cares, therefore Alice is probably (but not necessarily) the one writing the proof. I'm not sure if there's a good way to manage compensation otherwise.
<phantomcircuit>
Taek, what's he talking about?
<bsm1175321>
phantomcircuit: can you ask a more specific question? ;-) -- Sharding the blockchain.
<phantomcircuit>
bsm1175321, that can mean one of two things, sharding storage of blocks or sharding the utxo set in some way
<phantomcircuit>
which do you mean?
<bsm1175321>
phantomcircuit: sharding utxo set.
<bsm1175321>
Well, both really.
<bsm1175321>
But at the moment I'm thinking about transaction validation in the case where I don't have the whole utxo set, and ignoring questions of reorgs.
<phantomcircuit>
bsm1175321, ok so you're either talking about a system with spv security, or a system with fraud proofs
<bsm1175321>
phantomcircuit: suggestions for clear terminology welcome.
<phantomcircuit>
neither of which is as strong as a full node
<bsm1175321>
phantomcircuit: fraud proofs. But I'm not using them for proof-of-fraud.
<Taek>
or a system using bft-style consensus, which is vulnerable to Sybil attacks and is usually permissioned
Jeremy_Rand_2_ has quit [Ping timeout: 250 seconds]
bityogi has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<phantomcircuit>
Taek, im just going to ignore systems that are trivial sybil vulnerable since well duh :)
<bsm1175321>
Well -- walking the dog I was thinking of keeping two Merkle trees -- one of the UTXO set and another of validators/storage, indicating the range they are storing and a payout address. PoW then commits to both.
<phantomcircuit>
bsm1175321, why do you want to pay people for fraud proofs?
<bsm1175321>
phantomcircuit: I'm trying to find a way to provide to you a Merkle path (indicating proof of a UTXO in the last block) and get paid for providing it. e.g. proof of storage of a fraction of the UTXO set.
<bsm1175321>
phantomcircuit: To incentivize people to hold the UTXO set, once it is much larger than it is now.
Jeremy_Rand_2_ has joined #bitcoin-wizards
<bsm1175321>
Also as a means to divide it up in such a way that no one entity is required to hold it all.
<bsm1175321>
phantomcircuit: So, imagine attaching to a txn a proof that each of its inputs is unspent at a specific block height...
<phantomcircuit>
bsm1175321, i cant see how you could reasonably calculate fraud proofs for some of the aggregate functions without having the entire utxo
<phantomcircuit>
one of those being the inflation rules
<phantomcircuit>
but then literally there would be no nodes will full security...
<bsm1175321>
phantomcircuit: correct. But the system would be FAR more scalable and every node can validate correct state transitions independently.
<bsm1175321>
Because the "fraud proof" gives enough info to rebalance the Merkle tree and calculate the new Merkle root after applying it.
<bsm1175321>
(That's the Merkle root of all UTXO's -- bramc's Merkle Set commitment)
<bsm1175321>
or something similar
<phantomcircuit>
bsm1175321, i guess a single individual that operated enough of the sharding servers to cover the entire range would have equivalent of fraud proof security in theory
<bsm1175321>
phantomcircuit: Yes, it's quite likely that many entities would choose to cover the entire UTXO set space across multiple servers.
<bsm1175321>
But depending on that is THE major factor preventing scaling of bitcoin.
<phantomcircuit>
in practice though how do you think real users of the system will handle it if the miner doesn't provide a portion of a block to anybody except for the spv client they intend to attack?
<phantomcircuit>
or even worse
<bsm1175321>
phantomcircuit: You'll have to elaborate for me. What do miners have to do with this?
<phantomcircuit>
what if the miner creates an invalid block on purpose and then uses that to reorg the NEXT block
<phantomcircuit>
bsm1175321, i assume you're not thinking about a system without PoW?
<bsm1175321>
phantomcircuit: Say for the sake of argument a "block" is a single transaction, including its "fraud proofs"/"UTXO set inclusion proofs". Everyone can validate that. How can a miner create an invalid block?
<bsm1175321>
phantomcircuit: all PoW all the way baby.
<phantomcircuit>
bsm1175321, ok now lets say a miner constructs a block at height 1 which contains a double spend
<phantomcircuit>
however it only provides partial block fragments to the various parts of the network
<bsm1175321>
That is to say, the "fraud proof" is a Merkle path from the (known) root at height N, and using said proofs I can calculate the new root at height N+1.
<phantomcircuit>
then it sends someone a bunch of coins which get included in block height 2
<phantomcircuit>
and then the miner reveals that block 1 was invalid
<phantomcircuit>
well now you're screwed
<bsm1175321>
phantomcircuit: A txn must include ALL fraud proofs to be valid.
<bsm1175321>
Can you define "partial block fragments"?
<phantomcircuit>
bsm1175321, the system you're describing is one in which nobody ever sees the full block except for the miner
<phantomcircuit>
correct?
veleiro has quit [Read error: Connection reset by peer]
<bsm1175321>
No one is *required* to see the full block except the miner, correct.
<phantomcircuit>
there's a bunch of these sharding servers which only need to see some of the transactions
<phantomcircuit>
hmm actually i dont think that's right
<phantomcircuit>
no it is
<bsm1175321>
Imagine a division between sharding/storage servers and PoW miners, both of which get paid for their services.
<phantomcircuit>
they only need to see transactions where an input is in its shard or the transactions outputs would be in its shard
<bsm1175321>
If a miner sees a txn with only partial fraud proofs, it queries servers it knows cover the relevant range of the UTXO set to obtain a fraud proof, and then mines it.
<bsm1175321>
phantomcircuit: Correct, I would never see txn's that involve UTXO's outside my shard.
<phantomcircuit>
that means a miner can construct a block which appears valid to all users of the system until they later reveal it to be invalid
<phantomcircuit>
that seems like a very bad idea
<bsm1175321>
How?
<bsm1175321>
I'm assuming all shards/miners see the root hash, so can validate a Merkle path involving that root hash.
<bsm1175321>
So, you can't construct an invalid txn or fraud proof.
<phantomcircuit>
bsm1175321, explain how such a system deals with a miner including two transactions in the same block and simply refusing to provide the second transaction to anybody
<phantomcircuit>
the fraud proof generators cannot prove to anybody else that the miner refused to produce the transaction
<bsm1175321>
For the sake of simplicity I'm assuming transactions are mined individually.
<phantomcircuit>
all they can do is claim to not have it
<phantomcircuit>
bsm1175321, im thinking that's an assumption that makes the system less than practical :P
<bsm1175321>
In a block, the set of transactoins, with their fraud proofs, represent a set of transitions on the root hash. One cannot compute this transition without the fraud proofs.
<bsm1175321>
So, a block excluding fraud proofs would have to be invalid.
<bsm1175321>
One step at a time... ;-)
<phantomcircuit>
bsm1175321, would have to include the fraud proofs?
<phantomcircuit>
wait what
<bsm1175321>
Yes blocks would include fraud proofs.
<phantomcircuit>
the fundamental issue here is that you cannot prove fraud without all of the data
<phantomcircuit>
bsm1175321, that's less a fraud proof and more a proof of non-fraud
<bsm1175321>
exactly, which is why I eschewed use of the term "fraud proof". It's outsourced validation, really...
conner_ has joined #bitcoin-wizards
<bsm1175321>
Turning the idea on its head...
<phantomcircuit>
bsm1175321, i dont think anybody has actually constructed a system in which you can prove non-fraud completely
<bsm1175321>
No, I don't think they have. But rewinding the conversation a bit, it can be done (a) by providing Merkle paths in such a way that the "path" enables a receiver of the "path" to recompute the root after removing the leaf or (b) by use of incremental hash functions (some refs I posted earlier today) which allow the same thing.
<bsm1175321>
The required proof is proof of existence in a set, *and* the ability to compute the new Merkle root for that (sorted) set after removing that element.
<bsm1175321>
A Merkle path is sufficient for the first, the second I'm still a bit concerned about, in the event the tree requires a large amount of rearrangement.
<phantomcircuit>
bsm1175321, proof of inclusion in the utxo set is necessary but not sufficient
<phantomcircuit>
to prove that a transaction is valid you must prove inclusion in the utxo set and prove that all blocks from that point onwards are valid
<phantomcircuit>
the reason for this is the attack i described above
<phantomcircuit>
a miner can simply refuse to produce part of a block and then reverse many many blocks without direct loss
<phantomcircuit>
since nominally they would sell the coins from the reward long before revealing that the block is in fact invalid
<phantomcircuit>
and worse still conducting such an attack would require only a tiny amount of hashing power
<bsm1175321>
phantomcircuit: I don't fully understand your proposed attack. But...
<phantomcircuit>
so little that the arguments around miners not "sabotaging their business" are even more ridiculous than they are today
<phantomcircuit>
bsm1175321, you cannot prove that a block is valid without having the entire blocks contents, it's simply impossible on it's face
<bsm1175321>
phantomcircuit: My perspective on that is that one need not prove "all blocks from that point onward". Rather, one can create a valid block some time in the past, and it defines a fork in the usual way, and one must evaluate whether it has more work than the chain tip, in the usual way.
<bsm1175321>
phantomcircuit: I'm assuming I have the entire block, including all its fraud proofs.
<phantomcircuit>
and im not aware of anyway for a block to be moved from a valid to partially valid state without serious repercussions to the incentives structure
<phantomcircuit>
bsm1175321, if you're assuming you have the entire block then why bother with sharding? the primary cost is bandwidth and will likely remain that way for years to come
<phantomcircuit>
:P
NewLiberty_ has joined #bitcoin-wizards
<bsm1175321>
phantomcircuit: Let's take a step back and simplify. I'm trying to noodle out a very hypothetical currency in which: (a) the UTXO set is held by many parties, fractionally. (b) Those parties provide proofs of inclusion in the UTXO set, and therefore proof of validity of a transaction. (c) transactions are appended with proofs of inclusion at a specific height. (d) Miners then mine individual transactions includ
<bsm1175321>
I do see this as a path to sharding bitcoin, but one step at a time.
<phantomcircuit>
bsm1175321, i mean, that might work but wouldn't be very useful
<bsm1175321>
phantomcircuit: why?
<phantomcircuit>
well first off the 1:1 block:transaction ratio would be pretty aweful pretty quickly under a scenario that has high enough volume to warrant utxo sharding
<bsm1175321>
Not if you bring the target difficulty down to match.
<phantomcircuit>
but more so the system requires that virtually everybody sees all of the historic blocks, but then they dont attempt any serious validation
<bsm1175321>
But the validation is in the txn itself!
<phantomcircuit>
i suspect that validating the proofs of inclusion would actually be more expensive the maintaining a local utxo database in virtually all instances
<bsm1175321>
Hrm? Validating proof of inclusion is just: (root) -> branch -> branch -> ... (txid) and validating that the set of Merkle pairwise hashes results in the root (which you already knew)
<bsm1175321>
s/txid/utxo/
Jeremy_Rand_2_ has quit [Ping timeout: 250 seconds]
<bsm1175321>
Let's assume leaf nodes are hash(txid, vout).
<phantomcircuit>
bsm1175321, utxo set inclusion check can be made to be O(1) (if we ignore realities of hard ware)
<phantomcircuit>
all you need is enough disk space to build a hash table
<bsm1175321>
And what if you can't hold the whole hash table in RAM?
r0ach has joined #bitcoin-wizards
<bsm1175321>
Can it still be done in O(1)?
wallet42 has quit [Quit: Leaving.]
<phantomcircuit>
bsm1175321, O(1) doesn't mean it's fast
<phantomcircuit>
just that it's constant time
<bsm1175321>
Hehehee
<phantomcircuit>
and the answer is yes
<phantomcircuit>
it would still be O(1) average case
<phantomcircuit>
i mean a hash table in memory and on disk
<phantomcircuit>
hell you'd even just mmap the file
<phantomcircuit>
i think libbitcoin does this actually
<bsm1175321>
So what happens when the set size is larger than a single physical disk?
<bsm1175321>
And I have to reach across shards?
<phantomcircuit>
raid?
<bsm1175321>
We're trying to build a p2p currency here, not a Google datacenter. :-P
<phantomcircuit>
but in all seriousness that would be like ludicrously huge
jtimon has quit [Ping timeout: 250 seconds]
<phantomcircuit>
a single utxo entry should be like 32 + 4 + 32 bytes long (assuming optimized p2sh)
<phantomcircuit>
could even reduce it to a single 32 byte entry
<bsm1175321>
Let's just hash the shit and call it 32 bytes.
<phantomcircuit>
(i've been kind of tempted to do this in bitcoin except it would require a separate database mapping txid + index to scriptPubKey
<bsm1175321>
phantomcircuit: I'd be very happy to hear of an algorithm that can be O(1) across shards. The description above is log(n) in space...and I'm beginning to think that O(1) is impossible.
<phantomcircuit>
but then the main utxo db would be much much smaller which could give a pretty nice performance improvement
<phantomcircuit>
bsm1175321, sure just implement the UTXO DB as a hash table
<bsm1175321>
Yes, if the UTXO set was a (32 byte):(64 bit) hash map...
<phantomcircuit>
tada
<bsm1175321>
How do you shard a hash table?
<phantomcircuit>
bsm1175321, no no i mean literally just 32 byte entries in a "hash table set"
<bsm1175321>
and provide proof of inclusion?
<bsm1175321>
The proofs are hard. Most hash tables use non-cryptographic hash functions for speed, so finding collisions is trivial.
<phantomcircuit>
bsm1175321, you cant build a compat proof of inclusion without a merkle tree
<bsm1175321>
This may force one to worst case, which is probably log(n)
<phantomcircuit>
well i mean zk-SNARKS but like
<phantomcircuit>
lol
<bsm1175321>
zooko would disagree, and I wish him the best of luck, but I'm looking for zk-FASTER.
brg444 has quit [Ping timeout: 252 seconds]
frankenmint has joined #bitcoin-wizards
<phantomcircuit>
bsm1175321, zk-SNARKS for things we cannot do otherwise seems like a not-bad idea
<bsm1175321>
phantomcircuit: I'm willing to accept log(n) in the meantime, and plan on soft-forking in an O(1) zk-SNARK. ;-)
frankenmint has quit [Ping timeout: 240 seconds]
<amiller>
hooray
<bsm1175321>
You think log(n) is big. Go build a zk-SNARK and come back to me...
<phantomcircuit>
amiller, hello
<amiller>
hi phantomcircuit
<bsm1175321>
amiller I have a serious problem with you. I appreciate your contributions here but I have an ex-girlfriend whose father has the same first initial and last name. AND IT'S ALL YOUR FAULT.
<bsm1175321>
Clearly it's nearly midnight where I am and I'm getting loopy.
<petertodd>
bsm1175321: ACK
<amiller>
terrifying
* bsm1175321
has no idea why petertodd acked him. He has an ex- too?
<petertodd>
bsm1175321: "Clearly it's nearly midnight where I am and I'm getting loopy." <- ACK
<bsm1175321>
The gin has NOTHING to do with it.
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #bitcoin-wizards
<bsm1175321>
Anyway, I hope you all will be interested in discussing sharding/proof of inclusion/fraud proofs/incremental hash functions in the morning. Thanks especially maaku, Taek, phantomcircuit, I do think this direction is interesting and leads somewhere...It's been an interesting day.
* bsm1175321
marvels at being able to talk to such interesting and knowledgeable people on IRC. The 21st century is awesome... Also, IRC is very, very old.
roconnor has quit [Quit: Konversation terminated!]
Emcy has quit [Ping timeout: 276 seconds]
frankenmint has joined #bitcoin-wizards
sCOGSBY has joined #bitcoin-wizards
nubbins` has quit [Quit: Quit]
nubbins` has joined #bitcoin-wizards
Jeremy_Rand_2_ has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
nuke1989 has quit [Remote host closed the connection]
tromp_ has quit [Remote host closed the connection]
roidster has quit [Ping timeout: 276 seconds]
Giszmo has quit [Quit: Leaving.]
nubbins` has quit [Quit: Quit]
nubbins` has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
tromp_ has quit [Ping timeout: 252 seconds]
<Luke-Jr>
bsm1175321: lolwut
Ylbam has joined #bitcoin-wizards
<phantomcircuit>
Luke-Jr, he's marveling at being able to talk to me, dont be jealous
* phantomcircuit
runs away
<bsm1175321>
Thank goodness you weren't here Luke-Jr.
<Luke-Jr>
I'm pretty sure you don't have an ex-girlfriend whose father was a Dashjr
<aj>
Luke-Jr: but maybe he has an ex-girlfriend whose ex-boyfriend was Dashing? that's pretty close, right?
<Luke-Jr>
no
ThomasV has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
AusteritySucks has quit [Ping timeout: 248 seconds]
Alopex has joined #bitcoin-wizards
voxelot has quit [Ping timeout: 252 seconds]
AusteritySucks has joined #bitcoin-wizards
melvster has quit [Ping timeout: 272 seconds]
AusteritySucks has quit [Ping timeout: 250 seconds]
Alopex has quit [Remote host closed the connection]