00:49:36justanotheruser:justanotheruser is now known as Kermit70
00:49:47Kermit70:Kermit70 is now known as justanotheruser
01:04:43Guest73126:Guest73126 is now known as starsoccer
01:08:52Luke-Jr:amincd: merged mining is the appropriate solution. something like Factom (but not poorly designed) to make it easier does make sense to bring the best of both together.
01:17:33phantomcircuit:like Factom (but not poorly designed)
01:17:35phantomcircuit:lolin
04:04:50AlexeiTodorov:AlexeiTodorov is now known as NikolaiToryzin
05:18:37fanquake_:fanquake_ is now known as fanquake
08:03:43orik_:orik_ is now known as orik
09:05:16rajaniemi.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:16rajaniemi.freenode.net:Users on #bitcoin-wizards: andy-logbot Rynomster soundx SDCDev cbeams koshii Mably wiz thrasher` orik kgk btcdrak paveljanik coiner cletus11 aburan28 Graftec fanquake TheSeven PaulCapestany eslbaer_ jgarzik d1ggy Dr-G2 nubbins` devrandom kobud justanotheruser tromp_ moa MoALTz_ RoboTeddy Hunger- platinuum mappum use_zfs_yo Oizopower jbenet e1782d11df4c9914 jcluck Tjopper jaekwon espes__ qwopqwop huseby lclc ebfull indolering spinza midnightmagic gavinandresen
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: Guest72520 mortale adlai prodatalab alawson Xzibit17 nuke1989 kinlo Starduster_ michagogo waxwing hollandais otoburb hguux__ ahmed_ p15 PRab yrashk luny Cory Emcy nsh Luke-Jr kyletorpey shesek dgenr8 delll bosma copumpkin HaltingState amincd Meeh SubCreative binaryatrocity wizkid057 so HM2 berndj Krellan brand0 epscy_ phedny [d__d] stonecoldpat TD-Linux warptangent maaku andytoshi roasbeef OneFixt gwillen grandmaster2 dansmith_btc CodeShark
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: isis ryanxcharles BrainOverfl0w sdaftuar burcin_ BlueMatt wumpus Dyaheon- MRL-Relay nickler Alanius harrow Iriez Logicwax a5m0 phantomcircuit gnusha sl01 yoleaux catcow brad_ earlz davout btc___ PFate nick1234abcd__ gmaxwell Anduck bobke_ comboy_ null_radix NikolaiToryzin poggy dasource tromp hashtag LarsLarsen amiller artifexd deego fluffypony cryptowest sipa rw_8197 dardasaba veox warren gribble K1773R CryptOprah Muis kumavis coryfields
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: optimator weex jcorgan Fistful_of_Coins EasyAt jaromil mr_burdell sneak lnovy d9b4bef9 crescendo Taek azariah eric livegnik asoltys_ pigeons catlasshrugged kanzure heath JonTitor fenn Adrian_G throughnothing helo Graet lechuga_ ajweiss ryan-c @ChanServ smooth DoctorBTC BananaLotus tripleslash petertodd bbrittain Keefe s1w nanotube morcos Eliel_ cfields forrestv
10:04:05fluffypony:now we just need loggy-bot to be andying
10:48:02stonecoldpat:amincd: in regards to proposal to have a normal / prunable merkle tree - miners would then have to power to dictate if your transaction is 'forgotten' about in the future - your trusting them to make the correct decision to place the transaction in the correct sub-tree. Unless there is strict validation, i.e. your transaction must have an anchor/special OP_CODE to be stored in the
10:48:02stonecoldpat:prunable merkle tree, then it's open to abuse. (if I have understood your idea correctly, of course).
10:50:13amincd:stonecoldpat: The prunable transactions would have a special OP_CODE, yes. The only trickly part is mining fees. If these are temporary transactions, how would you assign fees to them? Without permanent storage, there'd be no way to validate that the fees the miner earned was valid
10:50:44amincd:*the only tricky part from what I can - it's entirely possible I'm missing some major flaw in the design
10:53:09Eliel_:amincd: it could be possible to create a ZKP that in itself takes less space than the transactions it proves were done according to the rules.
10:54:01stonecoldpat:amincd: another assumption is that the block would not have got validated if it was incorrect - so the fact that its survived 100 chains may be enough?
10:54:04Eliel_:although, if a usable ZKP for this purpose appears, you might as well forget about prunable and nonprunable and just use it for the whole history.
10:54:51amincd:Eliel_: yes ZKP look like magic to me. If they can work, we would live in a magical world
10:56:03Eliel_:well, it certainly is a pretty arcane process :D
10:58:03stonecoldpat:amincd: i think it depends if you want future validation, or just limited-future validation (probably not the best words), future validation in this sense is that i can always verify the block is correct no matter how much time has pasted, limited-future validation is that i can only verify the block is correct for a limited period of time (pre-defined by the protocol) unless I keep
10:58:03stonecoldpat:a record of the additional information required, and if you assume that the merkle tree is prunable after 100 blocks, that may well be enough - in the sense that the network would not have included that block in the chain if it were not correct.
10:59:39stonecoldpat:but your transactions would need to literally only spend a fee, and not send bitcoins to anyone, which is not very practical
10:59:50stonecoldpat:so a single OP_RETURN output, and the fee is collected by miner
11:07:06amincd:stonecoldpat: considering the root hash of the prunable merkle tree would be permanently stored in the blockchain, you could always validate a proof that a pruned hash appeared in a block
11:08:06stonecoldpat:amincd: exactly, i just ment that the network would still send you the information required to validate the proof. after 100 blocks all nodes can safely delete it - apart from those who still have to maintain that validation
11:08:17amincd:stonecoldpat: yes exactly
11:08:55stonecoldpat:the fact that the block was in the blockchain for such a long time (with the additional information being sent out) may be enough to prove that the fee's sent to the miner is okay
11:09:23stonecoldpat:so your problem, isn't really a problem in that sense, you just need to make sure the pruned transactions do not have any spendable outputs
11:09:54amincd:stonecoldpat: yeah that makes sense but for some reason it seems dangerous to allow that
11:10:14stonecoldpat:amincd: it doesnt make me feel easy either, but its a good thought experiament
11:10:24Eliel_:you could probably incentivize full archival nodes by having another PoW function that actually requires you to have the whole transaction data to run.
11:10:58Eliel_:and have some kind of a reward that is only available for miners running that algo
11:12:02Eliel_:It's my understanding that there are usable such functions already designed, although I haven't heard of any coin that actually uses one.
11:12:55amincd:Eliel_: apparently PoW functions dependent on real-world transaction data are not very practical
11:13:14stonecoldpat:Eliel_: do you mean a pow such that full and semi-nodes can verify, or just full-nodes? (so solve this pow a smaller reward, but the entire network can verify, or solve this full archival pow for a larger reward, but only full archival nodes can verify)?
11:13:19amincd:Eliel_: IIRC, Vitalik Buterin did some research on this for Ethereum
11:13:19Eliel_:amincd: in what sense?
11:13:57Eliel_:do you have a link? Are they not practical to be used as the only PoW or just not practical at all?
11:14:06amincd:Eliel_: it's hard to programmatically determine how much work it requires
11:14:35Eliel_:amincd: oh ok, so not very reliable as a proof of work. So having it be a secondary PoW is not a problem then.
11:14:58Eliel_:and will incentivize archival nodes
11:15:06amincd:Eliel_: don't have a link on hand, I can look for it later.
11:15:29Eliel_:although, probably makes sense to call it PoA, in this case :)
11:16:11amincd:Anyway, my interest is in finding a way to introduce data in Bitcoin that can be totally pruned, while preventing a root timestamp hash, and without breaking Bitcoin. I think this could have potential uses
11:16:27amincd:s/while preventing/while preserving/
12:06:20amincd:stonecoldpat: so regarding paying fees for getting txs included in the prunable merkle sub-tree, I was thinking this might be how it could be done: The user creates a normal fee-paying transaction, and indicates which non-prunable transaction that fee is intended to pay for, by including those transactions' hashes. The mining network would only consider those blocks valid that contain prunable transactions that the block gen
12:07:12amincd:The downside to this is that obviously this would reduce the space-saving effect of having a prunable sub-tree, because all of the transaction hashes of the 'prunable' transactions would be permanently stored in the non-prunable sub-tree.
12:08:50amincd:However it still preserves one of the design goals of this concept: only verified hashes would be permanently stored
12:09:21amincd:s/verified hashes/data verified to be a hash/
12:20:03stonecoldpat:if the prunable transactions were able to store more than 20 bytes (so 80 bytes) then you have a good trade-off, but txid are vulnerable to malleability so its not that great, i think something better could be done, e.g. OP_PRUNE and then the pruneanble tree would contain the data/pre-image to the hash. All clients can verify that the pre-image 'd' is inside the pruneable
12:20:03stonecoldpat:merkle-tree and that this pre-image 'd' matches the inside the fee paying transaction, such that = H(D)
12:20:49stonecoldpat:the data eventually gets deleted (after 100 blocks), but the commitment to that data still exists
12:21:13stonecoldpat:but it depends if u want to store hashes or the pre-image of a hash in the pruneable tree
12:21:52stonecoldpat:i think ideally the hash and pre-image (or either), so a fee paying trnasaction doesnt bloat the chain
12:22:40Pasha:Pasha is now known as Cory
12:26:36amincd:stonecoldpat: yes that's exactly what I was proposing. My description may have been unclear
12:29:32stonecoldpat:amincd: ah sorry my fault then, although i dont think the pruneable trees need to be transactions, just signed messages (that are ideally not malleable)
12:30:08stonecoldpat:perhaps given as part of a different channel and not the network itself (so miner only includes once he is given a match)
12:31:25op_mul:amiller: if you're going to quote someone talking about proof of work, vitalik is literally one of the worst you could try. he's failed utterly and completely at making his own "asic proof" one before.
12:31:36op_mul:amincd, rather.
12:32:23amincd:stonecoldpat: ah good point. I was using 'prunable transaction' interchangeably with 'pre-image data', which is not correct.
12:32:56amincd:I gotta for now. I look forward to discussing this further if you have any further thoughts
12:33:00amincd:*gotta go
12:33:04op_mul:amincd: "useful" proof of work is nonsense none the less. they're always going to be centralised, introduce incentives to do things outside of bitcoin which might not allign with the network's, and generally don't produce anything useful.
12:33:06stonecoldpat:good luck, ill give it a think
12:34:54amincd:op_mul: the goal was not to make 'useful' proof of work. It was to make proof of work that requires having the blockchain in memory, in order to increase the number of miners that are full nodes
12:35:06amincd:op_mul: in any case, it turned out to be a dead-end
12:35:18op_mul:Eliel_: there's been some altcoins attempt a UTXO querying proof of working, but as always they tend to fail extremely hard at it. one allowed n nonces before requerying, so all that happened was people made stratum servers giving out 30MB mining work.
12:36:31op_mul:amincd: eh, sorry, failed juxtaposed conversations and mixed the responses. sorry.
12:37:04op_mul:amincd: there's a couple of real-world examples of altcoins that do that to varying degrees, have you taken a look at them?
12:50:16priynag:Heya! We're building an IRC client with built-in logging called scrollback.io - do you mind if we log #bitcoin-wizards?
12:50:24priynag:we're already logging a bunch of freenode channels including #node.js - scrollback.io/nodejs
12:51:00nubbins`:o.O
12:51:15nubbins`:if someone minded, you'd stop?
12:52:13nubbins`:also, is the client you're building called "chatzilla"? :P
12:52:43priynag:@nubbins` - If people have issues, we won't
12:52:51priynag:No...its called scrollback.io
12:53:14priynag:You can check rooms like scrollback.io/nodejs or scrollback.io/mozilla-india
12:53:15nubbins`:just wondering because you're currently using chatzilla
12:53:32nubbins`:also wondering why you'd stop logging on someone's request
12:53:45nubbins`:it's a public channel, there are probably a hundred people logging it already
12:54:01priynag:We don't want to log rooms, if channel ops or most users are against it
12:54:22nubbins`:you seem a bit confused
12:55:07priynag:Okies...I will tell you a little more about how Scrollback.io works. We log IRC channels only if they are approved. We don't do it otherwise
12:55:19priynag:Thats the reason I stopped by to take permission here
12:57:42op_mul:priynag: do you know that's against freenode rules right?
12:58:52op_mul:well. I suppose if you're asking. it's not as bad.
12:59:06nubbins`:logging or the public posting of logs?
12:59:08priynag:We are already logging a few freenode channels like node.js...again, it permission from channel oop
12:59:32op_mul:nubbins`: public logging. if a channel has public logs it's in the topic. if it's not, there shouldn't be any logs.
12:59:48op_mul:private logging is of course a totally different matter.
12:59:48nubbins`:well til!
13:00:55priynag:op_mul: So, do you think its okay if we log this channel?
13:01:16op_mul:priynag: I'm not a chanop, it's not my choice.
13:02:01priynag:op_mul: Sure.
13:02:10op_mul:priynag: you are logging #bitcoin which you most certainly shouldn't be doing though.
13:05:12priynag:op_mul: No...I just checked
13:05:17priynag:We currently are not
13:22:54op_mul:priynag: https://scrollback.io/bitcoin
13:27:16priynag:op_mul: I think thats because the channel op had accepted to do so
13:27:35priynag:We generally don't link Scrollback to any IRC channel, without permission
13:35:20lclc:lclc is now known as lclc_bnc
14:00:34Eliel_:* Eliel_ wonders if it'd make sense to implement a system that prunes the utxo set throwing out transactions that haven't been proven to be spendable.
14:01:01Eliel_:Would that be too costly?
14:01:38Eliel_:err, make that txouts that haven't been proven to be spendable.
14:03:12Eliel_:as for the proof, well, you need to prove the private key exists. So, a signature would do.
14:04:19Eliel_:perhaps make the system such that without a proof, the utxo set will keep the txout for a year or two.
14:04:37Eliel_:and then assume unspendable and prune it.
14:04:38wumpus:that's the same idea as expiring utxos
14:05:30Eliel_:yes, but with the addition of a way to prevent it without needing an active online system to do it.
14:05:33wumpus:so to maintain a balance, you have to involve it in a transaction every N blocks
14:06:10wumpus:there have been better (or at least more subtle) proposals, in which old utxos are expired from the 'fast' store, but you can still spend them given a full proof
14:07:19Eliel_:ah, yes, if you provide the input transaction plus the merkle tree branch.
14:08:10Eliel_:come to think of it, wouldn't this allow a kind of utxo pruning without actually making anything unspendable?
14:08:44wumpus:I think so
14:09:18stonecoldpat:i dont know if an input transaction + merkle tree branch is enough as it could have been spent in a previous transaction whose output has also been "pruned"
14:10:59Eliel_:oh right, you'd need to keep a record of all spend txouts somehow for this to work.
14:11:06Eliel_:*spent
14:12:05siraj:couldn't you achieve decentralized consensus on anything by creating an app that stores data in its own bitorrent mainline DHT and uses ricardian contracts? No need for a blockchain
14:12:12wumpus:it's non-trivial, but if it can work it is much more realistic to be integrated into bitcoin than truly expiring utxos. I expect there to be too much resistance to that.
14:14:19wumpus:uh oh, someone said the DH.. word *braces for impact*
14:14:41op_mul:* op_mul braces for brammc
14:18:58priynag:priynag has left #bitcoin-wizards
14:19:38siraj:Let's hear it. Openbazaar seems to have opted for it instead of a blockchain. Plus, no computationally expensive proof of work or huge blockchain download necessary.
14:22:07wumpus:siraj: but more seriously: how you store the transactions is not really important, what matters is how to verify that inputs to an transaction are not already spent, that's where the block chain and its running state the utxo set come in
14:25:19kanzure:why would you have to tell sipa that?
14:25:33wumpus:who is saying anything to sipa?
14:25:39kanzure:oh interesting
14:25:43kanzure:right
14:26:16op_mul:op_mul is now known as siqa
14:27:29stonecoldpat:siraj: from what I can see, its still using the blockchain to commit to the transactions - DHT listings are used to match buyers/sellers before making any transactions (this is based on 10 minutes reading the github - so I may be wrong)
14:32:05fluffypony:siqa: "how do you make the backwards p?"
14:32:08fluffypony::-P
14:32:46siraj:wumpus good point. stonecoldpat hmm you might be right. noob question - what do you mean 'using the blockchain to commit to the transaction'? its a btc tx that uses btc's blockchain. what does commiting to a transaction signify?
14:32:49siqa:fluffypony: doesn't matter how it's made, the end result is a thousand angry irssi users.
14:33:32siqa:siqa is now known as op_mul
14:33:58stonecoldpat:siraq: just to finalise the payment, i'm not the greatest person with words
14:46:34Eliel_:siraj: the blockchain is used to prove that something existed at some point in the past. In this case, it'd be the contract between the buyer and seller.
14:47:05Eliel_:this means that it's not possible to change the contract and try to claim that the changed version was what was agreed on
14:47:20siraj:Thanks Eliel
14:47:21Eliel_:because only the correct version has been registered in the blockchain.
14:52:54jcluck:jcluck is now known as cluckj
15:19:02starsoccer:starsoccer is now known as Guest64296
15:31:47lclc_bnc:lclc_bnc is now known as lclc
15:54:41AlexStraunoff:AlexStraunoff is now known as NikolaiToryzin
16:52:56DoctorBTC_:DoctorBTC_ is now known as DoctorBTC
17:37:50cletus11:cletus11 has left #bitcoin-wizards
18:39:43andytosh1:andytosh1 is now known as andytoshi
19:58:15gavinandresen:Hey math wizards: what’s the formula for: What are the chances that I’ll see X or more blocks in S seconds, assuming average block time of 600 seconds and constant hash rate?
20:03:47ryan-c|web:gavinandresen: you want to compute a poisson distribution using the probability of finding a block in any given second
20:04:05ryan-c|web:https://en.wikipedia.org/wiki/Poisson_distribution
20:04:35gavinandresen:ryan-c|web: right, but I don’t know nuthin about combining statistical distributions
20:04:54gavinandresen:If I had infinite time I’d take a few statistics classes.....
20:05:13nubbins`:don't do it, they're a trap
20:05:21nubbins`:+1 for poisson, it's been too long tho
20:05:42ryan-c|web:gavinandresen: It should just be one distribution, you want the cumulative distribution function.
20:05:54ryan-c|web:one sec, translating it
20:08:22gavinandresen:ryan-c|web: thanks! That’s the FPoisson(k;lambda)… on the wikipedia page? yeah, I have no idea what semicolons in that function definition mean.
20:10:05ryan-c|web:gavinandresen: k is the minimum number of events, it looks like lambda is the "expected" number of events in the time period - so odds of finding a block in one second at current hash rate and difficulty times "S", the number of seconds you're looking at.
20:10:51gavinandresen:ryan-c|web: so the odds of finding, say, eleven blocks in one hour would be…
20:11:11tromp__:P(>=blocks in S seconds) = e^{-S/600} sum_{k>=X} (S/600)^k / k!
20:12:24ryan-c|web:gavinandresen: tromp__ sounds like he knows what he's talking about.
20:12:47tromp__:P(X blocks in S seconds) = e^{-S/600} (S/600)^X / X!
20:13:06ryan-c|web:I use tools that have the distribution stuff as built in functions already so i don't remember how you actually calculate it.
20:13:11gavinandresen:tromp_: thanks!
20:14:10tromp__:i'm just translating from http://en.wikipedia.org/wiki/Poisson_process#Homogeneous
20:15:29kanzure:what is the difference between your e^{} syntax and e^() syntax
20:15:48tromp__:so odds of exactly one block in 10 min should be 1/e
20:16:05tromp__:no diff; i'm just using LaTeX notation
20:16:30kanzure:oops now i've leaked that i haven't written latex in like, months
20:16:31ryan-c|web:kanzure: He's writing in LaTeX syntax
20:16:57ryan-c|web:ugh, web chat isn't scrolling
20:19:45tromp__:odds of no blocks in k*10mins should be e^-k
20:22:56belcher:belcher is now known as LondonCalling
20:22:58LondonCalling:LondonCalling is now known as belcher
21:14:29Pan0ram1x:Pan0ram1x is now known as Guest89184
21:24:44justanot1eruser:justanot1eruser is now known as justanotheruser
21:38:10lclc:lclc is now known as lclc_bnc
21:48:22andytoshi:hi nubbins`, we are already being logged at https://botbot.me/freenode/bitcoin-wizards/. thanks for the offer but no thanks. (i am a chanop)
21:51:29dgenr8:tromp__'s first expression is an infinite sum, but can be replaced by 1 - e^{-S/600} sum_{k
21:57:05nubbins`:?
21:57:38nubbins`:andytoshi i think you might have me confused with the guy who was asking
22:07:40tromp__:dgenr8 right; but for larger X, numerically computing a truncated tail will probably give a more accurate reult, since the terms converge to 0 fast
22:09:47dgenr8:alrighty then ;)
22:21:04andytoshi:nubbins`: oops, yes :) i meant priynag
23:13:19starsoccer:starsoccer is now known as Guest95482
23:21:56Starsocceraway:Starsocceraway is now known as starsoccer
23:22:55starsoccer:starsoccer is now known as Guest5874
23:24:45Guest5874:Guest5874 is now known as starsoccer
23:40:05starsoccer:starsoccer is now known as Guest21545