| 00:49:36 | justanotheruser: | justanotheruser is now known as Kermit70 |
| 00:49:47 | Kermit70: | Kermit70 is now known as justanotheruser |
| 01:04:43 | Guest73126: | Guest73126 is now known as starsoccer |
| 01:08:52 | Luke-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:33 | phantomcircuit: | like Factom (but not poorly designed) |
| 01:17:35 | phantomcircuit: | lolin |
| 04:04:50 | AlexeiTodorov: | AlexeiTodorov is now known as NikolaiToryzin |
| 05:18:37 | fanquake_: | fanquake_ is now known as fanquake |
| 08:03:43 | orik_: | orik_ is now known as orik |
| 09:05:16 | rajaniemi.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:16 | rajaniemi.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:16 | rajaniemi.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:16 | rajaniemi.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:16 | rajaniemi.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:05 | fluffypony: | now we just need loggy-bot to be andying |
| 10:48:02 | stonecoldpat: | 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:02 | stonecoldpat: | prunable merkle tree, then it's open to abuse. (if I have understood your idea correctly, of course). |
| 10:50:13 | amincd: | 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:44 | amincd: | *the only tricky part from what I can - it's entirely possible I'm missing some major flaw in the design |
| 10:53:09 | Eliel_: | 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:01 | stonecoldpat: | 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:04 | Eliel_: | 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:51 | amincd: | Eliel_: yes ZKP look like magic to me. If they can work, we would live in a magical world |
| 10:56:03 | Eliel_: | well, it certainly is a pretty arcane process :D |
| 10:58:03 | stonecoldpat: | 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:03 | stonecoldpat: | 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:39 | stonecoldpat: | but your transactions would need to literally only spend a fee, and not send bitcoins to anyone, which is not very practical |
| 10:59:50 | stonecoldpat: | so a single OP_RETURN output, and the fee is collected by miner |
| 11:07:06 | amincd: | 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:06 | stonecoldpat: | 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:17 | amincd: | stonecoldpat: yes exactly |
| 11:08:55 | stonecoldpat: | 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:23 | stonecoldpat: | 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:54 | amincd: | stonecoldpat: yeah that makes sense but for some reason it seems dangerous to allow that |
| 11:10:14 | stonecoldpat: | amincd: it doesnt make me feel easy either, but its a good thought experiament |
| 11:10:24 | Eliel_: | 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:58 | Eliel_: | and have some kind of a reward that is only available for miners running that algo |
| 11:12:02 | Eliel_: | 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:55 | amincd: | Eliel_: apparently PoW functions dependent on real-world transaction data are not very practical |
| 11:13:14 | stonecoldpat: | 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:19 | amincd: | Eliel_: IIRC, Vitalik Buterin did some research on this for Ethereum |
| 11:13:19 | Eliel_: | amincd: in what sense? |
| 11:13:57 | Eliel_: | do you have a link? Are they not practical to be used as the only PoW or just not practical at all? |
| 11:14:06 | amincd: | Eliel_: it's hard to programmatically determine how much work it requires |
| 11:14:35 | Eliel_: | 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:58 | Eliel_: | and will incentivize archival nodes |
| 11:15:06 | amincd: | Eliel_: don't have a link on hand, I can look for it later. |
| 11:15:29 | Eliel_: | although, probably makes sense to call it PoA, in this case :) |
| 11:16:11 | amincd: | 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:27 | amincd: | s/while preventing/while preserving/ |
| 12:06:20 | amincd: | 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:12 | amincd: | 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:50 | amincd: | However it still preserves one of the design goals of this concept: only verified hashes would be permanently stored |
| 12:09:21 | amincd: | s/verified hashes/data verified to be a hash/ |
| 12:20:03 | stonecoldpat: | 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:03 | stonecoldpat: | merkle-tree and that this pre-image 'd' matches the inside the fee paying transaction, such that = H(D) |
| 12:20:49 | stonecoldpat: | the data eventually gets deleted (after 100 blocks), but the commitment to that data still exists |
| 12:21:13 | stonecoldpat: | but it depends if u want to store hashes or the pre-image of a hash in the pruneable tree |
| 12:21:52 | stonecoldpat: | i think ideally the hash and pre-image (or either), so a fee paying trnasaction doesnt bloat the chain |
| 12:22:40 | Pasha: | Pasha is now known as Cory |
| 12:26:36 | amincd: | stonecoldpat: yes that's exactly what I was proposing. My description may have been unclear |
| 12:29:32 | stonecoldpat: | 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:08 | stonecoldpat: | 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:25 | op_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:36 | op_mul: | amincd, rather. |
| 12:32:23 | amincd: | stonecoldpat: ah good point. I was using 'prunable transaction' interchangeably with 'pre-image data', which is not correct. |
| 12:32:56 | amincd: | I gotta for now. I look forward to discussing this further if you have any further thoughts |
| 12:33:00 | amincd: | *gotta go |
| 12:33:04 | op_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:06 | stonecoldpat: | good luck, ill give it a think |
| 12:34:54 | amincd: | 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:06 | amincd: | op_mul: in any case, it turned out to be a dead-end |
| 12:35:18 | op_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:31 | op_mul: | amincd: eh, sorry, failed juxtaposed conversations and mixed the responses. sorry. |
| 12:37:04 | op_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:16 | priynag: | Heya! We're building an IRC client with built-in logging called scrollback.io - do you mind if we log #bitcoin-wizards? |
| 12:50:24 | priynag: | we're already logging a bunch of freenode channels including #node.js - scrollback.io/nodejs |
| 12:51:00 | nubbins`: | o.O |
| 12:51:15 | nubbins`: | if someone minded, you'd stop? |
| 12:52:13 | nubbins`: | also, is the client you're building called "chatzilla"? :P |
| 12:52:43 | priynag: | @nubbins` - If people have issues, we won't |
| 12:52:51 | priynag: | No...its called scrollback.io |
| 12:53:14 | priynag: | You can check rooms like scrollback.io/nodejs or scrollback.io/mozilla-india |
| 12:53:15 | nubbins`: | just wondering because you're currently using chatzilla |
| 12:53:32 | nubbins`: | also wondering why you'd stop logging on someone's request |
| 12:53:45 | nubbins`: | it's a public channel, there are probably a hundred people logging it already |
| 12:54:01 | priynag: | We don't want to log rooms, if channel ops or most users are against it |
| 12:54:22 | nubbins`: | you seem a bit confused |
| 12:55:07 | priynag: | 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:19 | priynag: | Thats the reason I stopped by to take permission here |
| 12:57:42 | op_mul: | priynag: do you know that's against freenode rules right? |
| 12:58:52 | op_mul: | well. I suppose if you're asking. it's not as bad. |
| 12:59:06 | nubbins`: | logging or the public posting of logs? |
| 12:59:08 | priynag: | We are already logging a few freenode channels like node.js...again, it permission from channel oop |
| 12:59:32 | op_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:48 | op_mul: | private logging is of course a totally different matter. |
| 12:59:48 | nubbins`: | well til! |
| 13:00:55 | priynag: | op_mul: So, do you think its okay if we log this channel? |
| 13:01:16 | op_mul: | priynag: I'm not a chanop, it's not my choice. |
| 13:02:01 | priynag: | op_mul: Sure. |
| 13:02:10 | op_mul: | priynag: you are logging #bitcoin which you most certainly shouldn't be doing though. |
| 13:05:12 | priynag: | op_mul: No...I just checked |
| 13:05:17 | priynag: | We currently are not |
| 13:22:54 | op_mul: | priynag: https://scrollback.io/bitcoin |
| 13:27:16 | priynag: | op_mul: I think thats because the channel op had accepted to do so |
| 13:27:35 | priynag: | We generally don't link Scrollback to any IRC channel, without permission |
| 13:35:20 | lclc: | lclc is now known as lclc_bnc |
| 14:00:34 | Eliel_: | * 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:01 | Eliel_: | Would that be too costly? |
| 14:01:38 | Eliel_: | err, make that txouts that haven't been proven to be spendable. |
| 14:03:12 | Eliel_: | as for the proof, well, you need to prove the private key exists. So, a signature would do. |
| 14:04:19 | Eliel_: | perhaps make the system such that without a proof, the utxo set will keep the txout for a year or two. |
| 14:04:37 | Eliel_: | and then assume unspendable and prune it. |
| 14:04:38 | wumpus: | that's the same idea as expiring utxos |
| 14:05:30 | Eliel_: | yes, but with the addition of a way to prevent it without needing an active online system to do it. |
| 14:05:33 | wumpus: | so to maintain a balance, you have to involve it in a transaction every N blocks |
| 14:06:10 | wumpus: | 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:19 | Eliel_: | ah, yes, if you provide the input transaction plus the merkle tree branch. |
| 14:08:10 | Eliel_: | come to think of it, wouldn't this allow a kind of utxo pruning without actually making anything unspendable? |
| 14:08:44 | wumpus: | I think so |
| 14:09:18 | stonecoldpat: | 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:59 | Eliel_: | oh right, you'd need to keep a record of all spend txouts somehow for this to work. |
| 14:11:06 | Eliel_: | *spent |
| 14:12:05 | siraj: | 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:12 | wumpus: | 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:19 | wumpus: | uh oh, someone said the DH.. word *braces for impact* |
| 14:14:41 | op_mul: | * op_mul braces for brammc |
| 14:18:58 | priynag: | priynag has left #bitcoin-wizards |
| 14:19:38 | siraj: | 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:07 | wumpus: | 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:19 | kanzure: | why would you have to tell sipa that? |
| 14:25:33 | wumpus: | who is saying anything to sipa? |
| 14:25:39 | kanzure: | oh interesting |
| 14:25:43 | kanzure: | right |
| 14:26:16 | op_mul: | op_mul is now known as siqa |
| 14:27:29 | stonecoldpat: | 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:05 | fluffypony: | siqa: "how do you make the backwards p?" |
| 14:32:08 | fluffypony: | :-P |
| 14:32:46 | siraj: | 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:49 | siqa: | fluffypony: doesn't matter how it's made, the end result is a thousand angry irssi users. |
| 14:33:32 | siqa: | siqa is now known as op_mul |
| 14:33:58 | stonecoldpat: | siraq: just to finalise the payment, i'm not the greatest person with words |
| 14:46:34 | Eliel_: | 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:05 | Eliel_: | 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:20 | siraj: | Thanks Eliel |
| 14:47:21 | Eliel_: | because only the correct version has been registered in the blockchain. |
| 14:52:54 | jcluck: | jcluck is now known as cluckj |
| 15:19:02 | starsoccer: | starsoccer is now known as Guest64296 |
| 15:31:47 | lclc_bnc: | lclc_bnc is now known as lclc |
| 15:54:41 | AlexStraunoff: | AlexStraunoff is now known as NikolaiToryzin |
| 16:52:56 | DoctorBTC_: | DoctorBTC_ is now known as DoctorBTC |
| 17:37:50 | cletus11: | cletus11 has left #bitcoin-wizards |
| 18:39:43 | andytosh1: | andytosh1 is now known as andytoshi |
| 19:58:15 | gavinandresen: | 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:47 | ryan-c|web: | gavinandresen: you want to compute a poisson distribution using the probability of finding a block in any given second |
| 20:04:05 | ryan-c|web: | https://en.wikipedia.org/wiki/Poisson_distribution |
| 20:04:35 | gavinandresen: | ryan-c|web: right, but I don’t know nuthin about combining statistical distributions |
| 20:04:54 | gavinandresen: | If I had infinite time I’d take a few statistics classes..... |
| 20:05:13 | nubbins`: | don't do it, they're a trap |
| 20:05:21 | nubbins`: | +1 for poisson, it's been too long tho |
| 20:05:42 | ryan-c|web: | gavinandresen: It should just be one distribution, you want the cumulative distribution function. |
| 20:05:54 | ryan-c|web: | one sec, translating it |
| 20:08:22 | gavinandresen: | 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:05 | ryan-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:51 | gavinandresen: | ryan-c|web: so the odds of finding, say, eleven blocks in one hour would be… |
| 20:11:11 | tromp__: | P(>=blocks in S seconds) = e^{-S/600} sum_{k>=X} (S/600)^k / k! |
| 20:12:24 | ryan-c|web: | gavinandresen: tromp__ sounds like he knows what he's talking about. |
| 20:12:47 | tromp__: | P(X blocks in S seconds) = e^{-S/600} (S/600)^X / X! |
| 20:13:06 | ryan-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:11 | gavinandresen: | tromp_: thanks! |
| 20:14:10 | tromp__: | i'm just translating from http://en.wikipedia.org/wiki/Poisson_process#Homogeneous |
| 20:15:29 | kanzure: | what is the difference between your e^{} syntax and e^() syntax |
| 20:15:48 | tromp__: | so odds of exactly one block in 10 min should be 1/e |
| 20:16:05 | tromp__: | no diff; i'm just using LaTeX notation |
| 20:16:30 | kanzure: | oops now i've leaked that i haven't written latex in like, months |
| 20:16:31 | ryan-c|web: | kanzure: He's writing in LaTeX syntax |
| 20:16:57 | ryan-c|web: | ugh, web chat isn't scrolling |
| 20:19:45 | tromp__: | odds of no blocks in k*10mins should be e^-k |
| 20:22:56 | belcher: | belcher is now known as LondonCalling |
| 20:22:58 | LondonCalling: | LondonCalling is now known as belcher |
| 21:14:29 | Pan0ram1x: | Pan0ram1x is now known as Guest89184 |
| 21:24:44 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 21:38:10 | lclc: | lclc is now known as lclc_bnc |
| 21:48:22 | andytoshi: | 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:29 | dgenr8: | tromp__'s first expression is an infinite sum, but can be replaced by 1 - e^{-S/600} sum_{k |
| 21:57:05 | nubbins`: | ? |
| 21:57:38 | nubbins`: | andytoshi i think you might have me confused with the guy who was asking |
| 22:07:40 | tromp__: | 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:47 | dgenr8: | alrighty then ;) |
| 22:21:04 | andytoshi: | nubbins`: oops, yes :) i meant priynag |
| 23:13:19 | starsoccer: | starsoccer is now known as Guest95482 |
| 23:21:56 | Starsocceraway: | Starsocceraway is now known as starsoccer |
| 23:22:55 | starsoccer: | starsoccer is now known as Guest5874 |
| 23:24:45 | Guest5874: | Guest5874 is now known as starsoccer |
| 23:40:05 | starsoccer: | starsoccer is now known as Guest21545 |