00:48:59gmaxwell:Can anyone kick me links to "zero conf by having miners sign statements that say they're planning on mining something" citations?
00:49:01MRL-Relay:[surae] disagree, GnarSith
00:49:03gmaxwell:gwillen perhaps?
00:49:21MRL-Relay:[surae] you'd just have OpenBazaar, but on the darkweb at that point
00:49:45MRL-Relay:[surae] besides, it's not like people don't use E-Bay to sell illegal stuff by simply using euphemisms
00:50:05gwillen:gmaxwell: I like to toss related ideas around but I don't know that I've seen it written up
00:50:30gwillen:(signed statements are new to me, what I've heard of was all about taking shares and using their PoW as evidence)
00:50:34MRL-Relay:[surae] gmaxwell, how would that work, exactly? my understanding is that zero conf transactions are... optionally accepted by merchants, and are independent of mining?
00:52:30gmaxwell:gwillen: got any citations on the share level, I know everyone knows about that... just looking for some references.
00:52:43gwillen:* gwillen nods
00:52:49gwillen:I'll see what I can track down but nothing at hand
00:58:12kanzure:gmaxwell: https://bitcointalk.org/index.php?topic=97153.0
00:59:16gmaxwell:Thanks! I think that was _one_ of the proposals I was vaguely thinking of but couldn't find. I think there are two others.
00:59:58kanzure:gmaxwell: https://bitcointalk.org/index.php?topic=62137.0;all
01:05:02Pan0ram1x:Pan0ram1x is now known as Guest64179
02:48:22dgenr8:* dgenr8 thinks they should have called those proposals "let's turn the whole network into a great big BitUndo"
02:49:16kanzure:i haven't seen any good proposals for turning bitcoin into a properly-centralized centralized system
02:49:21kanzure:just really bad ones
02:49:43justanotheruser:kanzure: what is properly-centralized?
02:50:14kanzure:naturally i would find a centralization proposal in bad taste anyway, but it's curious how little effort anyone has put into it (for example: you would expect someone who strongly disbelieves in decentralization to want to make a strong effort to convert bitcoin to centralization)
02:50:28kanzure:justanotheruser: oh you know, the usual benefits of a centralized ledger.
02:50:48dgenr8:* dgenr8 would look forward to eligius refusing to sign any txes from ... whomever
02:51:09justanotheruser:dgenr8: what does that mean?
02:52:06dgenr8:would eligius be expected to mine txes from satoshidice?
02:53:08justanotheruser:dgenr8: expecting by whom?
02:54:48justanotheruser:what proposal are you referring to? The partial confirm proposal?
02:55:15dgenr8:the proposals that create a preferred channel where miners can promise to mine your tx
03:06:15dgenr8:one guy did sort of mention that an attacker could use the service too. but he was ignored.
03:17:07justanotheruser:the assumption should be that an attacker will use such a service even if it doesn't knowingly exist yet.
03:53:45tobyai:tobyai has left #bitcoin-wizards
03:53:53dgenr8:yep
04:51:27maaku:maaku is now known as Guest89859
04:52:14webdeli:You know how the first page of "Enabling Blockchain Innovations with Pegged Sidechains" has a commit 5620e43 reference... Where is the Git repo?
04:56:14justanotheruser:webdeli: github.com/bitcoin/bitcoin
04:56:46justanotheruser:oh wait, you want the papers repo, sorry
04:57:52justanotheruser:It may be a private repo, I can't find it and if it did exist publicly, It'd probably be under https://github.com/blockstream
04:58:45webdeli:Cool - thanks for the clarification. As a side-joke - ... I tried to blame the whitepaper at that first link and I all I did was built this revolutionary p2p value transaction client app.
04:59:44webdeli:You can find commit has conflicts here:
04:59:48webdeli:https://github.com/X-ROM/android_frameworks_native/commits?author=aways
04:59:55webdeli:and here: https://github.com/Wesco/IR_Open_Order_Report/commits?author=TReische
05:00:44webdeli:But both these '5620e43' are obviously 'not the whitepaper I am looking for' in obie wan kanobe voice either.
06:52:53penny:penny is now known as Guest73730
07:10:25orik_:orik_ is now known as orik
07:54:15orik:orik is now known as orik_
07:59:53orik_:orik_ is now known as orik
09:05:18cameron.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:18cameron.freenode.net:Users on #bitcoin-wizards: andy-logbot cbeams vmatekole todaystomorrow koshii hashtag_ irclouis Guest73730 MoALTz Sub|afk mortale moa bosma [7] Guest89859 Adlai spiftheninja ebfull devrandom Dr-G kefkius BananaLotus chris200_ wizkid057 warptangent NewLiberty justanotheruser Guest64179 prepost hollandais go1111111 spinza luny super3 Hunger- Cory waxwing Meeh Nightwolf shesek bbrittain roconnor_ comboy dgenr8 epscy zenojis paperbot Greed rasengan altoz fluffypony Burrito
09:05:18cameron.freenode.net:Users on #bitcoin-wizards: grandmaster2 K1773R fanquake gnusha fenn kanzure heath stonecoldpat copumpkin LarsLarsen Logicwax jaromil weex helo Alanius c0rw1n samson_ tromp_ Keefe Iriez Eliel jrayhawk crescendo Baz___ PRab lnovy Luke-Jr coutts Fistful_of_Coins CodeShark DoctorBTC HaltingState Grishnakh iddo null_radix Emcy PaulCapestany gmaxwell Flyer33 [\\\] bobke_ sneak napedia huseby GnarSith Anduck @ChanServ lechuga_ abc56889 harrow so ahmed_ Gnosis pajarillo
09:05:18cameron.freenode.net:Users on #bitcoin-wizards: roasbeef ryan-c [Tristan] TD-Linux catcow danneu btc_ amiller yoleaux michagogo @gwillen BlueMatt smooth petertodd hguux _2539 livegnik Graet CryptOprah espes__ LaptopZZ [d__d] artifexd a5m0 kinlo Krellan gribble asoltys nanotube pigeons wumpus myeagleflies Dyaheon firepacket kgk SomeoneWeird tromp zibbo_ mr_burdell AdrianG dansmith_btc gavinandresen warren throughnothing Starsoccer emsid Apocalyptic BigBitz gazab fds4345 BrainOverfl0w
09:05:18cameron.freenode.net:Users on #bitcoin-wizards: andytoshi kumavis optimator_ EasyAt Taek jbenet mappum Sangheili coryfields cfields NikolaiToryzin poggy sipa arowser Muis nsh sl01 midnightmagic pi07r mmozeiko kyletorpey phantomcircuit berndj MRL-Relay iambernie phedny
12:55:50andytoshi:webdeli: there is a git repo, but not wit hthat commit in it
12:56:01webdeli:ok.
12:56:15andytoshi:webdeli: https://github.com/apoelstra/sidechains-whitepaper
12:56:26justanotheruser:andytoshi: is that main?
12:56:28andytoshi:the "real" repo has a ton of binary pdfs and weird make targets in it
12:56:51andytoshi:and like 5 million autocommits
12:57:14andytoshi:justanotheruser: what do you mean?
12:57:23justanotheruser:andytoshi: is that the main branch
12:57:28justanotheruser:it seems you just answered that though
12:57:43justanotheruser:I was wondering why that wasn't under the blockstream github..
12:57:52webdeli:I see. The question behind the question arises from idle curiosity about ceremony an practice between the authors that provided for a Git commit on a whitepaper.
12:58:23andytoshi:webdeli: it's just a revision no, it happens to be a git commit id but that isn't actually stated anywhere
12:59:31webdeli:My personal parallel use-case being - creating (ideally in Git / not Google docs) an open an co-authored document - an association's memorandum of incorporation - and specifically for the Bitcoin Co-Working Space @ MBTC
12:59:42webdeli:(Melbourne Bitcoin Technology Centre)
13:00:02webdeli:Roger that.
13:00:03andytoshi:webdeli: ah, you can steal the code from the sidechains wp, but you also need a couple git hooks ... one sec
13:01:08andytoshi:webdeli: post-checkout post-commit post-merge post-rewrite should all be https://gist.github.com/apoelstra/0813427350c169a7536b
13:05:27webdeli:And I take to understand my best entry point to understanding the workflow employed is here: http://mirror.unl.edu/ctan/macros/latex/contrib/gitinfo/gitinfo.pdf yes?
13:07:46andytoshi:it's worth skimming that -- i didn't read it too carefully
13:07:58andytoshi:just copied out the githooks, added the commands to the doc to put the commit id in
13:08:00andytoshi:then forgot about it
13:17:07webdeli:Right... Now done. So in esssence - TeX is the sourcecode for the PDF. (Yes I am using these words by analogy rather than by absolute definition).
13:17:43webdeli:I appreciate you providing the links to these repositories.
13:18:30sipa:i don't see how it would not be true in the absolute definition :)
13:18:39webdeli:Now let me withdraw back into the shadows to do organisational work once more.. once I catch some rest.
13:20:17webdeli:This actually started for me 10 hours ago opening up the "Enabling Blockchain Innovations with Pegged Sidechains" whitepaper with a view to delve into the detail of the idea therein. At least to the extent that I might come to understand the mechanism proposed.
13:21:07webdeli:Commentary (unsurprisingly) in the Bitcoin press has been at an overview and 'hand-wavy' then 'magic happens' kind of level.
13:21:39webdeli:Bodes understanding a little more. I hope to get it by reading.
13:22:12webdeli:So far no good - only on page one I go down this Git commit on a PDF rabbit hole. Tomorrow page 2 and beyond.
13:22:55webdeli:Thank you so much (all) for the value you are contributing to Bitcoin core and the dialogue around the evolution of the Bitcoin protocol.
13:24:20webdeli:Bitcoin is fundamentally most interesting mental and commercial pursuit I personally identify where I personally hold some reasonable of adding value in associated business / apps and software services.
13:24:36webdeli:*Rambling. Sleep time. G'night.
14:29:15kanzure:haha you're telling me that blockstream believes in autocommits? that sounds unlikely :)
15:14:20andytoshi:i was the only one autocommiting ;)
15:14:38andytoshi:or was that a pun?
15:28:45Guest89859:Guest89859 is now known as maaku
15:29:27kanzure:no, it's just that developers tend to be opinionated and against autocommits, that's all
15:30:20sipa:writing a paper is not development!
15:38:14tacotime:gmaxwell: i think there's a proof of stake signing scheme for darkcoin for 'instant tx' or something
15:38:54tacotime:where 'masternodes' with 1000 DRK receive a tx and sign for it, and then apparently the network decides that's the correct version of the tx and that it can't be double spent
15:40:48spiftheninja:spiftheninja has left #bitcoin-wizards
15:52:06tacotime:kanzure: doesn't freimarkets offer centralized ledger systems?
15:52:32kanzure:haven't looked
15:52:56tacotime:there's a whitepaper out there somewhere, and the devs jtimon and maaku are usually here
16:51:27tacotime:oh, this is that darkcoin 'instant tx' noise: https://www.darkcoin.io/wp-content/uploads/2014/09/InstantTX.pdf
16:55:06justanotheruser:tacotime: and if a group signs conflicting tx, consensus is broken foreven :D
16:55:30justanotheruser:I mean a supermajority does
16:55:42wumpus:it sounds quite fragile
16:55:55justanotheruser:so just wait for the block where supernodes colluse (every block a new set of supernodes are selected)
16:55:56tacotime:justanotheruser: yeah i was wondering about that
16:56:12tacotime:and what the heck happens in the event that a miner decides he wants to mine a conflicting tx
16:56:22justanotheruser:tacotime: his block is invalid
16:56:30tacotime:...
16:56:34wumpus:and vulnerable to sybil attacks? is 1000 DRK a lot?
16:56:46tacotime:wumpus: not for an exchange :)
16:56:53justanotheruser:wumpus: fairly expensive
16:57:14justanotheruser:about $2600
16:57:26wumpus:ok
16:58:26tacotime:so if the blocks can be invalidated at will, doesn't the whole system boil down to a sort of PoS?
16:58:59wumpus:yes, it is PoS
16:59:32tacotime:and it looks instantaneous too, so if an exchange gets hacked, it's game over
17:05:09justanotheruser:but don't worry about the attacks on this darkcoin proposal. I was assured by a darkcoin dev that "once consensus is established, it cannot be broken" (near exact paraphrase).
17:06:10Dizzle__:Dizzle__ is now known as Dizzle
17:08:06tacotime:perfect
17:10:19justanotheruser:* justanotheruser deletes blockchain
17:11:32dgenr8:the DRK video shows a transaction instantly getting "6 confirmations" and he apologized for it not having the check-mark icon. so they'll just get that cleaned up, and it's off to the races
17:13:30justanotheruser:* justanotheruser considers opening http://yesthiscoinisascamandwillfailbutitusesbrokensecurityassumptionsunlikebitco.in/
17:13:51justanotheruser:that way people will know that its failure doesn't represent a bitcoin failure and aren't turned away
17:18:22tdlfbx:Hey you could set up a round robin DNS for that domain to point to all the scam coins. ;-)
17:37:15maaku:tacotime: it does
17:37:35maaku:*freimarkets does provide private ledger systems
18:54:32Sub|afk:Sub|afk is now known as SubCreative
19:32:40dgenr8:what if lock request conflicts with a tx already seen? do clients only lock txes sometimes? what happens if miner doesn't include a locked tx? how does one know "once the lock has reached everyone"?
19:35:09justanotheruser:dgenr8: I think they ignore conflicting tx and propogate accepted tx
19:41:31dgenr8:does lock consensus mean unanimity? what if a block is found before the next masternode cohort is chosen?
19:43:27justanotheruser:dgenr8: btw, most of this isn't in the whitepaper, I am just going by what some dev told me
19:43:32justanotheruser:(darkcoin dev)
19:43:46dgenr8:you seem to know everybody
19:45:04wallet42:wallet42 is now known as Guest61169
19:45:04wallet421:wallet421 is now known as wallet42
19:47:39justanotheruser:and I forgot what their "solution" to that was, but I'm pretty sure I asked. I'm pretty sure they just said their usual "if masternodes try any funny business they'll get voted out, also, we can fork if something goes wrong".
19:48:48dgenr8:if they ignore existing conflicts then they have the same problem as the "partial confirm" proposals. They are a tool of the double spender.
19:48:53dgenr8:so that implies everyone locks all the time
19:49:14justanotheruser:and you can discuss these papers on their subreddits, but I have found that 90% of the time it isn't worth the time since the responses tend to be "FUD" "FUDer" and "stop spreading this FUD, you have no idea what you're talking about you idiot. Didn't you read the paper, their solution is X you moron"
19:49:46justanotheruser:(that is how I "know" everybody)
19:49:59justanotheruser:a dev actually did give me some cool headed responses, though they weren't promising
19:51:36dgenr8:ok. well anyway, it's possible to make the 0-conf results generally better, but all this PoS stuff seems pointless and a couple seconds is not possible. nothing quantitative on time at all in the paper
19:52:45justanotheruser:dgenr8: there are ways, but I don't know any solutions other than scorched earth that don't involve invoking trust
19:53:38instagibbs:seems like they'd be better off doing GA.it-style 0-conf, maybe with signer also doing some sorta masternode-style staking of some funds that disappear if double-spends detected
19:53:50instagibbs:make the trust explicit, rather than hiding it
19:54:50justanotheruser:ya... you could just trust the masternodes and have "darkcoin-super-original-0-conf-spend" which would be an implementation of another thing already done in bitcoin, 2-of-2
19:55:10instagibbs:exactly my point
19:55:26gmaxwell:instagibbs: agreed. (wrt bonding. ... well, so there is an issue there that the losses from doublespending are unbounded, so bonding is a pretty weak protection against actual evil... may protect more against carelessness)
19:55:54gmaxwell:Of course ... doing that kind of protection works fine in bitcoin already, no need to pump an altcoin for it.
19:56:33gmaxwell:though they could perhaps have the doublespending bonds, since currently bitcoin script is not powerful enough to make that work.
19:56:51instagibbs:gmaxwell: You could bound the losses by making co-signing keys public... with a huge loss in privacy of course
19:57:31instagibbs:maybe not, nevermind
19:57:34gmaxwell:instagibbs: it doesn't bound the losses. yea.
19:57:43instagibbs:because they could gather txns
19:57:47instagibbs:then released all at once
19:57:51gmaxwell:you just doublespend ALL THE PEOPLE at once.
19:57:53gmaxwell:yep.
19:57:58instagibbs:derp
19:58:12gmaxwell:yea, to prevent that you need a consensus system. Yo dawg.
19:58:30instagibbs:Re-inventing blockchains, all the way down
19:58:42gmaxwell:But thats okay; really if you use all the available tools then mostly whant you need to protect against is carelessness and bonds may be adequate for that.
20:03:24instagibbs:Well people seem to be totally ok with trusting central servers; getting people on 2-of-2 arrangements would still be huge win. Not going to lose sleep over it.
20:04:48gmaxwell:instagibbs: well don't be too eager there, "people" != "altcoin pumpers" the issue there is that the altcoin pumping people are going to be excited about anything that promotes their altcoin, regardless of the security model; people who were thinking carefully about security left already (or never were involved there)... but yea sure, I guess the success of bc.i is evidence for your claim.
20:05:38instagibbs:Broad brush, etc :)
20:06:49instagibbs:I don't think the cause is lost. But it's education... which takes quite a while.
20:24:02luny``:luny`` is now known as luny
20:30:59dgenr8:justanotheruser: bitcoin has all the tools. defining agreement on 0-conf primacy to include a 30-second safety margin, and a relatively weak link to enforcement by miners is enough.
20:31:13dgenr8:justanotheruser: see https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
20:33:38justanotheruser:dgenr8: "The only action a node takes under this rule is to act temporarily as though it has not yet received a certain block. No consensus failure is possible"
20:34:59justanotheruser:what incentive is there to delay this miners block? If I was a miner I would start on what is most likely to be the next block right away. Consensus harm is possible. If it takes a minute for a block to "propogate" (propogate in the sense that a miner starts working on it) then 1/10 blocks will be reorged out
20:37:07gmaxwell:dgenr8: I don't think your proposal is logically coherent or workable. I tried before to explain how it creates vulnerabilities and doesn't achieve its goal, and if it could work we wouldn't need a blockchain at all... I've given up continuing to repeat myself however, since you continue to advance similar proposals without any sign of understanding the reaction you're getting.
20:37:55dgenr8:justanotheruser: If a small amount of hash power adopts, it becomes economical for others to follow. This is quantified in the proposal.
20:37:58helo:propagation isn't a binary event... if it takes 60 seconds to fully (say to 95% of nodes) propagate, i would guess that the average time to see a new block would be 40 seconds or so
20:38:14helo:but fast nodes with fast peers can probably see new blocks much faster than the average
20:39:07dgenr8:gmaxwell: i added a whole section with quantitative reasoning in response to your most recent remarks. what did you think of it?
20:40:56dgenr8:helo: the entire distribution of tx propagation times is used as a basis for reasoning and deriving a 30-second threshold as workable
20:46:34justanotheruser:dgenr8: you've got to consider what happens when I generate a block on top of the new block that is supposed to be delayed while everyone else is working on the old block. If one miner mines a new block and I mine a new block then my block is on the tallest chain. I can forge timestamps and all that good stuff to make it look like I accounted for the delay too.
20:46:47justanotheruser:This example demonstrates the lack of incentive to ignore a new block
20:47:33dgenr8:justanotheruser: network instantly accepts it (C = 1) timestamps don't play into it
20:48:11justanotheruser:s/If one miner mines a new block and I mine a new block then my block is on the tallest chain./If a block is mined on the old chain you're "supposed" to be working on and you generate a block on top of the delayed block, your block is in the tallest chain./
20:48:11dgenr8:justanotheruser: think back to your choice of where to mine though
20:48:29justanotheruser:dgenr8: timestamps can be irrelevant then
20:48:59justanotheruser:I'm not sure how that fixes the problem.
20:50:00dgenr8:justanotheruser: sorry, think back to the guy who included the double-spend's choice.
20:50:27justanotheruser:there is a strong incentive to work on the tallest block unless *no-one* else is working on it.
20:51:01dgenr8:justanotheruser: no, the block reward is so big compared to any DS fees, he isn't going to risk it.
20:51:37justanotheruser:dgenr8: not sure how you prevent him from getting the block reward or what he is risking
20:52:10dgenr8:justanotheruser: this is quantified. if 100% delay his block, it costs him 25btc to a first approximation
20:52:56justanotheruser:dgenr8: sure, but what is the incentive for anyone to "delay" his block?
20:53:21Dizzle__:Dizzle__ is now known as Dizzle
20:53:50dgenr8:justanotheruser: depending on assumptions, only a very small amount of hash power has to be concerned enough with the network becoming opaque to double-spends to implement this rule
20:55:07justanotheruser:dgenr8: so you propose >50% not mining a taller fork in general because it contains doublespends, or what is your mechanism preventing the hash power from going towards processing the more economical blocks?
20:55:10dgenr8:justanotheruser: per proposal, if there is just one double-spend "premium" to be claimed, the break-even number is .24% of hash power.
20:56:13justanotheruser:dgenr8: right, so you're incentivizing forcing reorgs
20:57:01dgenr8:no reorgs with c = 1
21:02:00dgenr8:a "delayer" could be implemented as a preprocessor outside of the main block accept logic, though depending on how much validation was done this would not be as efficient as doing it inside that logic
21:06:46dgenr8:the delayer wouldn't get used much though. what would actually happen is miners would stop including double-spends whose gap from tx1 was in the deprecated window (for ex: (30s, 2hr)). which is the goal
21:19:37dgenr8:i don't think i've expressed this directly enough -- there is a cascade effect. delays could also be used for things like including way too few transactions vs. what was available.
21:20:03Dizzle__:Dizzle__ is now known as Dizzle
21:48:36starsoccer:starsoccer is now known as Guest81469
22:05:19OP_NULL:the darkcoin masternode stuff is actually very interesting from the standpoint of incentives. the masternodes now take a more significant portion of the block reward of the miners, so things are increasingly muddy in that regard. it’ll be interesting to see how they go balancing that as they risk devaluing mining until they are completely vulnerable.
22:10:18OP_NULL:justanotheruser: there's other strange things they haven't addressed with regards to network sanity. there's a limit to the number of masternodes, but it's not clear how that's enforced in a sensible way.
22:14:39scoobysnacking:hey guys, anyone had this issue with Bitcoind before? 2014-11-09 20:21:34 ERROR: CheckProofOfWork() : nBits below minimum work 2014-11-09 20:21:34 ERROR: ReadBlockFromDisk : Errors in block header
22:14:51scoobysnacking:(Bitcoind then crashes)
22:15:29OP_NULL:scoobysnacking: #bitcoin-dev
22:15:40kanzure:or #bitcoin
22:16:28scoobysnacking:asked in both, thanks
22:18:04Guest81469:Guest81469 is now known as starsoccer
22:18:33starsoccer:starsoccer is now known as Guest54524
22:18:54Guest54524:Guest54524 is now known as starsoccer
22:56:34gmaxwell:petertodd: I wonder if we should add a citation to https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-04 when its finally published to the comment in bitcoin core that tells people to not immitate the merkle tree.