#bitcoin-wizards on 2015-11-09 — irc logs at freenode.irclog.whitequark.org

2015-10-30 00:53 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

00:03 pozitrono has joined #bitcoin-wizards

00:13 jojva has joined #bitcoin-wizards

00:15 Quanttek has quit [Ping timeout: 240 seconds]

00:20 <jojva> Hi. In his AMA, Mike Hearn said sidechains are not composable. Is this something desirable? And second, the first thing that pops up in my head is that there would be obviously compatible features (e.g. faster blocks + bigger blocksize + anonymity), incompatible features (e.g. current bitcoin economy + demurrage), others probably more subtle than that. Is there work I can read somewhere about how different consensus rules woul

00:20 <jojva> d be mergeable or not? Has work been done on that?

00:22 <kanzure> "mergeable" into what?

00:22 <jojva> between themselves. Like a git merge.

00:22 <sipa> from the "feature" point of view they are completely independent

00:22 <sipa> every blockchain has its own consensus rules

00:23 <jojva> sipa: what if consensus rules are compatible?

00:23 <sipa> you can create a new one with rules composed of things from two other ones

00:23 <sipa> not sure what you mean

00:25 <jojva> sipa: I'm thinking about ways to determine whether 2 or more features are mergeable (read: compatible) or not. An interesting thing I could imagine with sidechains would be choosing several features as a user for your transaction. Like plugins on Firefox.

00:26 <sipa> if you're talking about script features, that's usually trivally

00:26 <sipa> if you don't want to use a feature, dob't use it in the scripts you create/hand out

00:26 <sipa> but they still need to be rules enforced by the consensus system

00:27 <sipa> adding new rules requires soft ot hard forks, just as with bitcoin itself

00:27 <sipa> or

00:27 <jojva> i understand

00:28 <sipa> it's not so much that sidechains are easier to change

00:28 <sipa> they're mostly easier to create and adopt, and switch between

00:28 <jojva> I was wondering if creating a new sidechain could be automated by somehow selecting from a set of proposed feature.

00:29 rusty has joined #bitcoin-wizards

00:29 <jojva> sipa: are you sure about that?

00:29 <sipa> i don't believe that building a new interesting cryptosystem from scratch will ever be easy

00:29 <jojva> i mean, the adoption part. Once a userbase is established, why would they switch? the inertia could get big

00:29 <sipa> if we're able to create a new chain and easily pick from features A B and C... why don't we just create a single chain that has all thoae features, and use it instead?

00:30 <sipa> jojva: as opposed to adopting an altcoin

00:30 <sipa> there is of course still inertia

00:31 <sipa> what sidechains allow are more easy experimentation with features of a consensus system without needing to first beat a currency's network effect

00:31 <jojva> sipa: I guess I'm dreaming a bit. I'm wondering if it's possible to have *some* features, not all

00:31 <sipa> why would you not want all?

00:31 <sipa> ... apart from political disagreements

00:31 <jojva> hmm

00:32 alex__ has quit []

00:32 <jojva> You have that great experimental feature

00:32 <sipa> i guess if you're talking about introducing features that have high cost for some users of the system

00:32 <jojva> it's not ready to be pushed into production

00:32 <jojva> yep

00:32 <sipa> but those are imho more appropriate for private deployments

00:32 <jojva> i guess so

00:33 <jojva> so we would basically have master, develop and topic sidechains

00:34 <sipa> yes :)

00:35 <jojva> Well that was quick and enlightening. Thanks :) I guess the answer is sidechain composition is not really useful.

00:35 dEBRUYNE__ has joined #bitcoin-wizards

00:38 dEBRUYNE_ has quit [Ping timeout: 244 seconds]

00:39 <sipa> they're just one tool

00:39 <sipa> they're not a solution to all problems related to feature changes

00:39 <sipa> in particular, a large proportion of feature are easily softforked into bitcoin itself

00:39 <jojva> like what?

00:39 <jojva> so?

00:41 TBI_ has joined #bitcoin-wizards

00:42 frankenmint has joined #bitcoin-wizards

00:42 <gmaxwell> Any script related features which do not have high verification costs, for example.

00:42 <jojva> I have to admit I see the future of sidechains as more than testing. They could be used to play with real BTC money with features that would never be merged into Core (for political reasons as you said)

00:42 <gmaxwell> Elements alpha has several script related features, and one of them is about to be soft-forked into the bitcoin network (CLTV), and several others are in the pipeline at varrious stages.

00:43 <gmaxwell> Other than the external costs of verification someone's script related features are no one elses business-- users should decide how they control their own coins.

00:43 TBI has quit [Ping timeout: 240 seconds]

00:43 <gmaxwell> P2SH set up the standard for that where, without coperation by the reciever, a sender can't even tell what the specific rules a reciever of funds will be using to control their spending.

00:44 Keefe has quit [Ping timeout: 252 seconds]

00:44 <jojva> i'm not very well versed in the scripting system..

00:45 <jojva> i'll have to read about it a bit more

00:45 spinza has joined #bitcoin-wizards

00:45 <jojva> It's a shame because it seems to be 90% of a feature's implementation :p

00:46 <jojva> Gotta go to bed. Thanks for the clarifications.

00:46 <sipa> yw

00:50 CodeShark has joined #bitcoin-wizards

00:51 Piper-Off is now known as Monthrect

00:51 CodeShark has quit [Client Quit]

00:51 CodeShark has joined #bitcoin-wizards

00:55 bedeho has quit [Ping timeout: 255 seconds]

00:55 pozitrono has quit [Ping timeout: 246 seconds]

01:04 <jgarzik> jojva, Creating a new sidechain can certainly be automated with a point and click. That's the easy part. The difficult part is rolling out _validation_ of new features -- the checks-and-balances where everybody checks everybody else's work, to make sure there are no shenanigans.

01:04 <jgarzik> jojva, Some side chains will indeed be temporary - created one day, then collapsed/composed/merged back into the bitcoin main chain at the end of the week.

01:05 <jgarzik> There will be chain analogues to git repo branching and merging.

01:10 prosodyvVerreabC has quit [Quit: Connection closed for inactivity]

01:12 CodeShark has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]

01:12 CodeShark has joined #bitcoin-wizards

01:13 CodeShark_ has joined #bitcoin-wizards

01:13 Monthrect is now known as Piper-Off

01:14 CodeShark is now known as Guest88917

01:14 CodeShark_ has quit [Client Quit]

01:14 Guest88917 has quit [Client Quit]

01:15 <phantomcircuit> jgarzik, agreed (also insert OP_X86 joke)

01:17 snthsnth has joined #bitcoin-wizards

01:18 <jgarzik> In RE the original purpose of side chains...

01:18 <jgarzik> I would like to see a cross-vendor side chain with experimental features being tested

01:18 <phantomcircuit> as in constructed by multiple groups or run by multiple groups?

01:18 <jgarzik> M-of-N as in Liquid is cheesy but easy to implement

01:18 <jgarzik> run by multiple independent orgs

01:19 <jgarzik> s/run/validated/

01:19 <phantomcircuit> jgarzik, elements alpha is sort of already like that, everybody who runs a signer is running it as an individual

01:19 <jgarzik> I would like to participate in some 1-of-N agreements with other bitcoin companies

01:19 <phantomcircuit> (something something testnet)

01:19 dEBRUYNE__ has quit [Ping timeout: 265 seconds]

01:21 <phantomcircuit> jgarzik, 1 of n?

01:25 <jgarzik> phantomcircuit, my org joins with N other orgs, where no org holds more than 1 validation vote/node/trust nexus

01:26 <jgarzik> similar to Liquid IIUC

01:27 frankenmint has quit [Remote host closed the connection]

01:28 p15 has joined #bitcoin-wizards

01:30 Yoghur114 has quit [Remote host closed the connection]

01:33 <phantomcircuit> jgarzik, oh i was thinking you meant the signing threshold would be 1/n which provides no security over 1/1

01:33 <phantomcircuit> so i was confused

01:34 <bramc> In new working on a merkle set data structure I figured out that it's a good idea at each node to give the values of both children locally, because that reduces cache misses on invalidation because you don't have to look up sibling values because they're always local

01:41 Piper-Off is now known as Monthrect

01:44 Ylbam has quit [Quit: Connection closed for inactivity]

01:59 prosodyvVerreabC has joined #bitcoin-wizards

02:01 <bramc> Rather than special case this for exits from blocks I'm propagating it through everything. It's a lot cleaner that way.

02:02 <bramc> Leads to the actual hash root of everything having to be a special variable.

02:06 <jgarzik> phantomcircuit, yeah 1-of-N from my org's PoV, M of N from user's PoV

02:07 <jgarzik> Also want to research some more egalitarian validation schemes... can PoS (BTC CLTV) be employed as alternative to M-of-N?

02:08 digitalmagus has joined #bitcoin-wizards

02:08 <jgarzik> (ok, maybe egalitarian is not the best word for PoS... looking for a less permissioned entry/exit system)

02:08 <jgarzik> All this is strictly within the context of a BTC sidechain

02:09 digitalmagus8 has quit [Ping timeout: 272 seconds]

02:14 frankenmint has joined #bitcoin-wizards

02:18 frankenm_ has joined #bitcoin-wizards

02:19 digitalmagus8 has joined #bitcoin-wizards

02:20 frankenmint has quit [Ping timeout: 264 seconds]

02:21 digitalmagus has quit [Ping timeout: 240 seconds]

02:22 kgk has joined #bitcoin-wizards

02:23 SwedFTP has joined #bitcoin-wizards

02:25 archobserver has quit [Remote host closed the connection]

02:27 kgk has quit [Ping timeout: 255 seconds]

02:33 archobserver has joined #bitcoin-wizards

02:37 frankenm_ has quit [Remote host closed the connection]

03:28 Monthrect is now known as Piper-Off

03:38 <bsm117532> Reading the Bitcoin-NG paper again. What prevents someone from discovering the current leader, and DDoSing them off the network? Then discovering the next one, and DDoSing them of the network...rinse lather repeat.

03:39 <bsm117532> Seems to me you can shut down the entire network this way, where with bitcoin you'd have to DDoS every single mining node since you don't know where the next one is coming from. (Ignoring mining centralization problems for the moment)

03:41 roxtrongo has joined #bitcoin-wizards

03:44 archobserver has quit [Quit: :(){ :|: &};:]

04:02 JackH has quit [Ping timeout: 265 seconds]

04:09 jgarzik has quit [Quit: Leaving]

04:18 <phantomcircuit> bsm117532, you can make it hard to identify the leader by ip address

04:18 <phantomcircuit> (but yes that would almost certainly turn into a problem)

04:18 <bsm117532> I can identify him by looking at my own peers and who sent me the last block.

04:19 <bsm117532> And work my way up the tree...

04:19 <bsm117532> The not-knowing-who-makes-the-next-block is really important to Bitcoin's byzantine resiliency, it seems to me...

04:20 <phantomcircuit> bsm117532, im actually constantly surprised that miners aren't ddos'ing each other and taking out large chunks of the internet

04:21 <bsm117532> I'm surprised too. We really have to fix the miner centralization problem. Sooner or later someone will start DDoSing competing miners.

04:24 kgk has joined #bitcoin-wizards

04:24 TheSeven has quit [Disconnected by services]

04:25 [7] has joined #bitcoin-wizards

04:25 <rusty> bsm117532, phantomcircuit: my understanding was that it happens on a regular basis, at least to pools.

04:27 <bsm117532> Yes I'm aware of a couple attacks...

04:28 <bsm117532> e.g. http://www.wired.com/2014/08/isp-bitcoin-theft/

04:28 kgk has quit [Ping timeout: 252 seconds]

04:28 roxtrongo has quit [Remote host closed the connection]

04:32 <phantomcircuit> rusty, it's happened multiple times but isn't the norm

04:33 <kanzure> jgarzik: current m-of-n fedpeg implementation is sorta buggy and needs eyelooking

04:39 <kanzure> er, at least for networking reasons

04:45 <phantomcircuit> kanzure, replace the zmq stuff with something else and it wouldn't be too bad

04:47 <kanzure> zeromq isn't that bad :-)

04:47 <kanzure> just needs some parameter tweaks

04:47 <kanzure> set highwater line parameter (HWM or something)

04:48 <phantomcircuit> ehhhh

04:51 roxtrongo has joined #bitcoin-wizards

04:51 binaryatrocity has quit [Quit: No Ping reply in 180 seconds.]

04:54 <bramc> After posting to the bitcoin-dev list my post on transaction fees has gotten some more coverage, mostly positive. The negative responses have mostly been from people not understanding that monopoly pricing is higher than efficient pricing.

04:55 <bramc> Thanks kanzure for asking me to post there

04:55 <kanzure> yeah was figuring would be good to send where people would know to look for such a thing

04:56 * bsm117532 reads...

04:58 <bramc> Notably none of the people being dismissive of what I proposed actually suggested a concrete algorithm to use instead. Going through the exercise of trying to do that makes the problems come to the surface.

04:59 <kanzure> would there be any utility to manually working examples of expected scenarios?

04:59 <bsm117532> Anyone ever suggesting a concrete algorithm is a rare thing in the bitcoin world. :-/

05:00 gribble has quit [Remote host closed the connection]

05:01 <kanzure> also; miners will tend to use simple (good) software if made easily available, so eventually writing good transaction pickers would also be a good thing to do

05:01 sparetire_ has quit [Quit: sparetire_]

05:01 <kanzure> from the miner angle it's more of an integration detail rather than algorithmic, of course...

05:02 bedeho has joined #bitcoin-wizards

05:02 <bsm117532> You know, I posted my same complaint about Bitcoin-NG to bitcoin-dev 3 weeks ago and no one replied (I just re-had the thought while re-reading the paper). We've got a pretty serious communications breakdown in this community. :-/ Bram not being on the mailing list too... :-/

05:04 <bramc> kanzure, The lack of a reference wallet in core is a big problem.

05:10 <bramc> bsm117532 I haven't evaluated bitcoin-ng but my general thought is that we should simply assume that there's a scaling limit for bitcoin and plan appropriately.

05:10 <bsm117532> Their analysis is quite good. Question is: What's the plan? ;-)

05:12 <bramc> I'm not on the mailing list because (a) I'm not on mailing lists generally, as a productivity thing (b) there's a lot of humdrum bitcoin dev work which involves stuff which I haven't touched and have no plans to touch, and (c) I'm still a bit of a tourist in cryptocurrency space and don't want to make a pretense otherwise

05:12 p15 has quit [Max SendQ exceeded]

05:14 <bsm117532> bramc: I can understand that, I wasn't trying to single you out personally. You're only a tourist if you want to be. I *really* want to know more about how you're implementing Merkle sets. ;-)

05:15 Giszmo has quit [Quit: Leaving.]

05:17 gribble has joined #bitcoin-wizards

05:20 Piper-Off is now known as Monthrect

05:29 Monthrect is now known as Piper-Off

05:30 <bramc> bsm117532 That will be forthcoming. It will be easier to simply read my code than a human language explanation of it.

05:46 CodeShark has joined #bitcoin-wizards

06:03 digitalmagus has joined #bitcoin-wizards

06:03 digitalmagus has quit [Changing host]

06:03 digitalmagus has joined #bitcoin-wizards

06:03 frankenmint has joined #bitcoin-wizards

06:05 digitalmagus8 has quit [Ping timeout: 272 seconds]

06:10 Keefe has joined #bitcoin-wizards

06:22 kyuupichan has quit [Read error: Connection reset by peer]

06:25 chmod755 has joined #bitcoin-wizards

06:35 p15 has joined #bitcoin-wizards

06:43 rusty has quit [Quit: Leaving.]

06:55 Piper-Off is now known as Monthrect

06:56 Ylbam has joined #bitcoin-wizards

06:58 snthsnth has quit [Ping timeout: 255 seconds]

07:03 <fluffypony> bramc: I don't think that very specific criticism, or finding a flaw in the fundamentals, necessarily has to be accompanied by a suggestion

07:04 <fluffypony> but if they're just generally being dismissive that's unhelpful

07:07 <bramc> fluffypony, The criticism is mostly 'using past price information to set prices now immediately is faster'

07:08 <bramc> If the claim is that there's something better, then that supposedly better thing should be suggested.

07:11 <fluffypony> yeah that's needless

07:12 NLNico has joined #bitcoin-wizards

07:46 mjerr has joined #bitcoin-wizards

07:51 matsjj has joined #bitcoin-wizards

07:55 bramc has quit [Quit: This computer has gone to sleep]

07:55 Monthrect is now known as Piper-Off

07:58 DougieBot5000 has quit [Quit: Leaving]

08:04 digitalmagus has quit [Ping timeout: 255 seconds]

08:07 ThomasV has joined #bitcoin-wizards

08:11 kyuupichan has joined #bitcoin-wizards

08:12 alferz has joined #bitcoin-wizards

08:19 ThomasV has quit [Ping timeout: 240 seconds]

08:23 damethos has joined #bitcoin-wizards

08:26 kgk has joined #bitcoin-wizards

08:27 alferz has quit [Ping timeout: 244 seconds]

08:31 kgk has quit [Ping timeout: 264 seconds]

08:34 JackH has joined #bitcoin-wizards

08:40 frankenmint has quit [Remote host closed the connection]

08:40 frankenmint has joined #bitcoin-wizards

09:06 CoinMuncher has joined #bitcoin-wizards

09:11 c0rw1n has quit []

09:13 ThomasV has joined #bitcoin-wizards

09:17 NLNico has quit [Quit: Leaving]

09:25 alferz has joined #bitcoin-wizards

09:28 c0rw1n has joined #bitcoin-wizards

09:33 nivah has joined #bitcoin-wizards

09:45 alferz has quit [Ping timeout: 244 seconds]

09:58 dEBRUYNE__ has joined #bitcoin-wizards

10:03 frankenmint has quit [Remote host closed the connection]

10:05 bedeho has quit [Ping timeout: 260 seconds]

10:07 ThomasV has quit [Quit: Quitte]

10:09 sparetire_ has joined #bitcoin-wizards

10:12 melvster has quit [Ping timeout: 272 seconds]

10:13 rubensayshi has joined #bitcoin-wizards

10:13 rusty has joined #bitcoin-wizards

10:24 alferz has joined #bitcoin-wizards

10:25 melvster has joined #bitcoin-wizards

10:25 jtimon has quit [Read error: Connection reset by peer]

10:28 kgk has joined #bitcoin-wizards

10:31 hazirafel has joined #bitcoin-wizards

10:31 jrayhawk has quit [Ping timeout: 240 seconds]

10:32 kanzure has quit [Ping timeout: 250 seconds]

10:32 heath has quit [Ping timeout: 260 seconds]

10:32 AaronvanW has joined #bitcoin-wizards

10:32 kgk has quit [Ping timeout: 240 seconds]

10:32 gnusha_ has quit [Ping timeout: 260 seconds]

10:37 alferz has quit [Ping timeout: 244 seconds]

10:45 rht___ has joined #bitcoin-wizards

10:45 hazirafel has quit [Remote host closed the connection]

10:50 GAit has joined #bitcoin-wizards

10:57 melvster has quit [Ping timeout: 260 seconds]

11:04 spinza has quit [Excess Flood]

11:10 melvster has joined #bitcoin-wizards

11:12 spinza has joined #bitcoin-wizards

11:20 dEBRUYNE_ has joined #bitcoin-wizards

11:23 dEBRUYNE__ has quit [Ping timeout: 246 seconds]

11:26 melvster has quit [Ping timeout: 272 seconds]

11:31 atgreen has quit [Ping timeout: 265 seconds]

11:39 ThomasV has joined #bitcoin-wizards

11:40 melvster has joined #bitcoin-wizards

11:40 jrayhawk has joined #bitcoin-wizards

11:40 heath has joined #bitcoin-wizards

11:40 dEBRUYNE__ has joined #bitcoin-wizards

11:41 kanzure has joined #bitcoin-wizards

11:41 gnusha has joined #bitcoin-wizards

11:43 dEBRUYNE has joined #bitcoin-wizards

11:44 atgreen has joined #bitcoin-wizards

11:44 dEBRUYNE_ has quit [Ping timeout: 265 seconds]

11:44 dEBRUYNE_ has joined #bitcoin-wizards

11:45 kyuupichan has quit [Read error: Connection reset by peer]

11:45 dEBRUYNE__ has quit [Ping timeout: 244 seconds]

11:48 dEBRUYNE has quit [Ping timeout: 265 seconds]

11:50 dEBRUYNE has joined #bitcoin-wizards

11:51 rusty has left #bitcoin-wizards [#bitcoin-wizards]

11:52 dEBRUYNE__ has joined #bitcoin-wizards

11:53 dEBRUYNE_ has quit [Ping timeout: 265 seconds]

11:55 dEBRUYNE has quit [Ping timeout: 255 seconds]

12:02 dEBRUYNE has joined #bitcoin-wizards

12:05 dEBRUYNE__ has quit [Ping timeout: 255 seconds]

12:07 kyuupichan has joined #bitcoin-wizards

12:13 melvster has quit [Ping timeout: 244 seconds]

12:20 bramc has joined #bitcoin-wizards

12:22 GAit has quit [Quit: Leaving.]

12:22 pozitron has joined #bitcoin-wizards

12:27 melvster has joined #bitcoin-wizards

12:46 eudoxia has joined #bitcoin-wizards

12:51 GAit has joined #bitcoin-wizards

12:53 dfdfdfdfd has joined #bitcoin-wizards

12:53 dfdfdfdfd has quit [Client Quit]

12:58 rht___ has quit [Quit: Connection closed for inactivity]

12:59 atgreen has quit [Ping timeout: 240 seconds]

13:03 roxtrongo has quit [Remote host closed the connection]

13:13 atgreen has joined #bitcoin-wizards

13:13 rustyn has quit []

13:22 Giszmo has joined #bitcoin-wizards

13:33 atgreen has quit [Ping timeout: 265 seconds]

13:45 damethos has quit [Remote host closed the connection]

13:49 bramc has quit [Quit: This computer has gone to sleep]

13:53 kgk has joined #bitcoin-wizards

13:55 p15 has quit [Ping timeout: 265 seconds]

13:58 kgk has quit [Ping timeout: 260 seconds]

14:00 damethos has joined #bitcoin-wizards

14:02 bit2017 has joined #bitcoin-wizards

14:02 King_Rex has joined #bitcoin-wizards

14:03 roxtrongo has joined #bitcoin-wizards

14:05 GAit has quit [Quit: Leaving.]

14:05 nivah has quit [Ping timeout: 264 seconds]

14:07 Guest91590 has quit [Ping timeout: 255 seconds]

14:07 bit2017 has quit [Ping timeout: 250 seconds]

14:08 GAit has joined #bitcoin-wizards

14:08 roxtrongo has quit [Ping timeout: 244 seconds]

14:09 pozitron has quit [Ping timeout: 264 seconds]

14:13 pigeons has joined #bitcoin-wizards

14:13 pigeons is now known as Guest51134

14:32 ratbanebo has joined #bitcoin-wizards

14:38 ratbanebo has quit [Read error: Connection reset by peer]

14:39 ratbanebo has joined #bitcoin-wizards

14:40 atgreen has joined #bitcoin-wizards

14:45 lclc has quit [Ping timeout: 272 seconds]

14:49 Meeh has quit [Ping timeout: 260 seconds]

14:51 Meeh has joined #bitcoin-wizards

14:53 lclc has joined #bitcoin-wizards

14:55 kgk has joined #bitcoin-wizards

14:57 waxwing has quit [Read error: Connection reset by peer]

14:57 Quanttek has joined #bitcoin-wizards

14:59 kgk has quit [Ping timeout: 240 seconds]

15:01 waxwing has joined #bitcoin-wizards

15:06 GAit has quit [Quit: Leaving.]

15:08 damethos has quit [Quit: Bye]

15:10 GAit has joined #bitcoin-wizards

15:14 lclc has quit [Ping timeout: 240 seconds]

15:14 bsm1175321 has quit [Ping timeout: 240 seconds]

15:14 <amiller_> whooo, asynchronous BFT experiments

15:17 <amiller_> im running BFT experiments across 64 ec2 nodes in eight regions, with maximum fault tolerance n=3f+1.... and achieving thousands of transactions committed per second

15:18 eudoxia has quit [Quit: Leaving]

15:18 <nsh> BFT?

15:19 bsm1175321 has joined #bitcoin-wizards

15:20 <nsh> oh, byzantine fault tolerance

15:21 lclc has joined #bitcoin-wizards

15:23 DougieBot5000 has joined #bitcoin-wizards

15:27 foobar_ has joined #bitcoin-wizards

15:28 lclc has quit [Ping timeout: 260 seconds]

15:29 lclc has joined #bitcoin-wizards

15:35 roxtrongo has joined #bitcoin-wizards

15:39 roxtrongo has quit [Ping timeout: 240 seconds]

15:48 kyuupichan has quit [Read error: Connection reset by peer]

15:51 matsjj has quit [Remote host closed the connection]

15:52 roxtrongo has joined #bitcoin-wizards

15:56 King_Rex has quit [Remote host closed the connection]

15:56 kgk has joined #bitcoin-wizards

15:57 nwilcox has joined #bitcoin-wizards

15:59 foobar_ has quit [Ping timeout: 246 seconds]

15:59 damethos has joined #bitcoin-wizards

16:01 kgk has quit [Ping timeout: 272 seconds]

16:07 gribble has quit [Remote host closed the connection]

16:10 damethos has quit [Quit: Bye]

16:14 matsjj has joined #bitcoin-wizards

16:14 gribble has joined #bitcoin-wizards

16:19 MoALTz has joined #bitcoin-wizards

16:33 damethos has joined #bitcoin-wizards

16:38 StephenM347 has joined #bitcoin-wizards

16:41 GAit has quit [Quit: Leaving.]

16:43 GAit has joined #bitcoin-wizards

16:51 King_Rex has joined #bitcoin-wizards

16:54 GAit has quit [Quit: Leaving.]

16:58 ThomasV has quit [Ping timeout: 260 seconds]

17:00 hazirafel has joined #bitcoin-wizards

17:09 Dizzle has joined #bitcoin-wizards

17:18 roxtrongo has quit [Remote host closed the connection]

17:48 zooko has joined #bitcoin-wizards

17:48 kyuupichan has joined #bitcoin-wizards

17:48 jgarzik has joined #bitcoin-wizards

17:48 jgarzik has quit [Changing host]

17:48 jgarzik has joined #bitcoin-wizards

17:50 darmou has joined #bitcoin-wizards

17:52 bobke has quit [Remote host closed the connection]

17:54 nwilcox has quit [Ping timeout: 250 seconds]

17:56 bobke has joined #bitcoin-wizards

17:57 kgk has joined #bitcoin-wizards

18:00 spinza has quit [Excess Flood]

18:02 kgk has quit [Ping timeout: 240 seconds]

18:02 hazirafel has quit [Ping timeout: 264 seconds]

18:04 GAit has joined #bitcoin-wizards

18:06 matsjj has quit [Remote host closed the connection]

18:06 el33th4x0r has joined #bitcoin-wizards

18:07 CoinMuncher has quit [Quit: Leaving.]

18:09 mjerr has quit [Ping timeout: 255 seconds]

18:09 spinza has joined #bitcoin-wizards

18:11 rubensayshi has quit [Remote host closed the connection]

18:11 <kanzure> well at least they admit that you still have to wait for actual confirmations? http://hackingdistributed.com/2015/11/09/bitcoin-ng-followup/

18:13 <el33th4x0r> hi Brian

18:14 <el33th4x0r> a merchant's transaction acceptance policy depends on their risk profile. this is true for any protocol, NG included.

18:14 <el33th4x0r> but 1-confirmations in NG offer strictly stronger guarantees than 0-confs in Core, and come much faster than 1-confirmations in Core.

18:18 roxtrongo has joined #bitcoin-wizards

18:20 GAit has quit [Read error: Connection reset by peer]

18:20 GAit has joined #bitcoin-wizards

18:21 zooko has quit [Read error: Connection reset by peer]

18:22 zooko has joined #bitcoin-wizards

18:23 roxtrongo has quit [Ping timeout: 255 seconds]

18:25 orik has joined #bitcoin-wizards

18:45 iddo has quit [Ping timeout: 240 seconds]

18:48 dEBRUYNE_ has joined #bitcoin-wizards

18:51 dEBRUYNE has quit [Ping timeout: 244 seconds]

18:52 iddo has joined #bitcoin-wizards

18:55 dEBRUYNE__ has joined #bitcoin-wizards

18:59 dEBRUYNE_ has quit [Ping timeout: 255 seconds]

18:59 zooko has quit [Ping timeout: 240 seconds]

18:59 mrkent has joined #bitcoin-wizards

18:59 dEBRUYNE_ has joined #bitcoin-wizards

19:00 matsjj has joined #bitcoin-wizards

19:02 dEBRUYNE has joined #bitcoin-wizards

19:03 dEBRUYNE__ has quit [Ping timeout: 255 seconds]

19:04 dEBRUYNE_ has quit [Ping timeout: 255 seconds]

19:04 erasmospunk has joined #bitcoin-wizards

19:06 dEBRUYNE_ has joined #bitcoin-wizards

19:07 atgreen has quit [Ping timeout: 250 seconds]

19:08 dEBRUYNE__ has joined #bitcoin-wizards

19:10 dEBRUYNE has quit [Ping timeout: 276 seconds]

19:11 gribble has quit [Remote host closed the connection]

19:12 dEBRUYNE_ has quit [Ping timeout: 244 seconds]

19:12 dEBRUYNE has joined #bitcoin-wizards

19:15 dEBRUYNE__ has quit [Ping timeout: 244 seconds]

19:17 iddo has quit [Ping timeout: 240 seconds]

19:19 iddo has joined #bitcoin-wizards

19:20 dEBRUYNE_ has joined #bitcoin-wizards

19:22 Yoghur114 has joined #bitcoin-wizards

19:23 gribble has joined #bitcoin-wizards

19:24 dEBRUYNE has quit [Ping timeout: 265 seconds]

19:25 dEBRUYNE__ has joined #bitcoin-wizards

19:28 dEBRUYNE_ has quit [Ping timeout: 265 seconds]

19:30 dEBRUYNE_ has joined #bitcoin-wizards

19:31 damethos has quit [Quit: Bye]

19:31 dEBRUYNE has joined #bitcoin-wizards

19:33 dEBRUYNE__ has quit [Ping timeout: 265 seconds]

19:33 darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]

19:34 dEBRUYNE_ has quit [Ping timeout: 265 seconds]

19:37 skyraider has joined #bitcoin-wizards

19:40 Doge_Funnie has quit [Quit: Leaving]

19:42 matsjj has quit [Remote host closed the connection]

19:50 jojva has quit [Ping timeout: 255 seconds]

19:52 King_Rex has quit [Remote host closed the connection]

19:55 dEBRUYNE_ has joined #bitcoin-wizards

19:58 dEBRUYNE has quit [Ping timeout: 255 seconds]

19:59 kgk has joined #bitcoin-wizards

20:03 kgk has quit [Ping timeout: 240 seconds]

20:07 AaronvanW has quit [Ping timeout: 246 seconds]

20:07 dEBRUYNE__ has joined #bitcoin-wizards

20:10 dEBRUYNE_ has quit [Ping timeout: 255 seconds]

20:11 <Taek> the idea is only half-baked at this point, but could you achieve similar goals to bitcoin-ng by using near-blocks instead of assigning a leader?

20:11 <Taek> set a rule that transactions in a particular block must have been seen in near-blocks building off of one of the previous N blocks

20:12 <gwillen> Taek: if you're talking about blocks that nearly have enough work, but not quite, people talk about that under the name "weak blocks" I believe

20:12 zooko has joined #bitcoin-wizards

20:12 <Taek> I thought we settled on the term 'near blocks', I know there's been some back-and-forth on the term. I'm content with either, but though we chose 'near blocks'

20:12 <gwillen> ahhh okay

20:13 <Taek> *thought

20:13 <gwillen> I have been wrong before :-)

20:13 <gwillen> I've definitely heard these kinds of schemes talked about as an alternative to NG-like stuff though

20:13 <gmaxwell> Taek: I am of the belief that block preforwarding and efficient transmission can give the same benefits, yes. Though I've not yet convinced myself it's precisely the same benefits.

20:14 smk has quit [Quit: Page closed]

20:18 dEBRUYNE_ has joined #bitcoin-wizards

20:18 tulip has joined #bitcoin-wizards

20:19 <Taek> a proposal with similar goals that I've not seen discussed here is the 'Helix blockchain'

20:19 <Taek> https://bitcointalk.org/index.php?topic=1067534.0

20:19 <gavinandresen> I agree with gmaxwell. I’ve had a little back-and-forth email conversation with Ittay and Gun about weak blocks versus NG.

20:21 <gavinandresen> Taek : re: helix: fragmenting a user’s wallet’s UTXOs into multiple pieces that can’t be spent all at once is a terrible, horrible, no-good idea. Extra complexity for illusory benefit.

20:22 <Taek> gavinandresen: I believe a user would want to set up their wallet so that all utxos inside of it are on a single part of the helix

20:22 dEBRUYNE__ has quit [Ping timeout: 276 seconds]

20:22 <gavinandresen> Taek : fragmenting the user base is an even worse idea.

20:23 <gavinandresen> “oh, you’re on helix.3 ? I use helix.2 ….”

20:23 <Taek> it would need to fragment the user base. You can send an output from any helix segment to any helix segment, it's just that you can only spend from 1 at a time

20:23 <Taek> You can send from helix2 to helix3, it's just that you can't send from helix1 AND helix2 to helix3 in the same txn

20:25 <Taek> the major advantage is that miners can mine without needing to have validated the most recent block

20:25 <gavinandresen> and if I’ve got a fully-validating wallet on helix.3 how do I know transactions from helix.2 are valid, unless I’m watching the chain? Might as well run with SPV security….

20:25 <Taek> you still have to validate the whole chain

20:26 <Taek> the construction is to improve the orphan rate, which means bigger or more frequent blocks are possible

20:26 <gavinandresen> weak/near blocks can give the same benefit

20:26 <Taek> I haven't spent too much time looking at it, but I'm guessing that combining the two could produce a compounded benefit

20:26 <Taek> (maybe not, haven't looked at it yet)

20:27 <gavinandresen> e.g. miners announce a weak block along with a zero-POW “here’s the block I’ll build on top of that”

20:28 jojva has joined #bitcoin-wizards

20:28 darmou has joined #bitcoin-wizards

20:29 dEBRUYNE__ has joined #bitcoin-wizards

20:32 damethos has joined #bitcoin-wizards

20:32 dEBRUYNE_ has quit [Ping timeout: 276 seconds]

20:32 zooko has quit [Ping timeout: 276 seconds]

20:37 dEBRUYNE_ has joined #bitcoin-wizards

20:40 dEBRUYNE has joined #bitcoin-wizards

20:40 dEBRUYNE__ has quit [Ping timeout: 240 seconds]

20:41 Jeremy_Rand has quit [Ping timeout: 272 seconds]

20:43 matsjj has joined #bitcoin-wizards

20:43 dEBRUYNE_ has quit [Ping timeout: 276 seconds]

20:43 chmod755 has quit [Quit: Ex-Chat]

20:47 matsjj has quit [Ping timeout: 240 seconds]

20:48 ratbaneb_ has joined #bitcoin-wizards

20:48 orik has quit [Quit: Textual IRC Client: www.textualapp.com]

20:49 Eliel_ is now known as Eliel

20:50 ratbanebo has quit [Ping timeout: 255 seconds]

20:55 nwilcox has joined #bitcoin-wizards

20:56 <bliljerk101> https://forum.bitcoin.com/dev-tech-talk/unobtrusively-anonymizing-the-u-s-postal-service-with-smart-contracts-t2003.html#p6048 - I proposed a way to anonymously assimilate, decentralize, and manage inventory without trust and physical interaction using smart contracts. I think this could work. Thoughts?

20:58 derpderp has joined #bitcoin-wizards

20:59 AaronvanW has joined #bitcoin-wizards

21:01 derpderp_ has quit [Ping timeout: 272 seconds]

21:07 Quanttek has quit [Remote host closed the connection]

21:07 Quanttek has joined #bitcoin-wizards

21:08 rusty has joined #bitcoin-wizards

21:08 Quanttek has quit [Remote host closed the connection]

21:09 roxtrongo has joined #bitcoin-wizards

21:10 <amiller_> bliljerk101, i dunno, i think that post is full of fallacies (or at least unsatisfactorily resolved problems) that aren't that much different in the different scenarios (whether it's about inventory, postal service or whatever)

21:10 Quanttek has joined #bitcoin-wizards

21:11 <bliljerk101> amiller_ could you elaborate? i'm happy to examine

21:11 <amiller_> the main one i'm picking at there is the idea that if both a buyer and seller both put in a bunch of collateral,

21:11 paveljanik has quit [Quit: Leaving]

21:11 <amiller_> that it's now incentive compatible for both of them to be honest

21:11 <amiller_> i don't think that's the case because of coercion (there's some other better name for this scenario but i forget)

21:11 <el33th4x0r> I can see how block preforwarding and efficient transmission are complementary to NG. For them to provide the same benefits, you need a lot more mechanism around them.

21:12 <amiller_> if the seller says "hey i'm absoluetly not sending you an item, and if you want any of your collateral back at all, you should just liie and say the transaction went ok"

21:12 snthsnth has joined #bitcoin-wizards

21:12 <bliljerk101> amiller_ collusion? what coercion?

21:12 <amiller_> then it's in the buyer's personal best interest to comply with the seller

21:12 Quanttek has quit [Read error: Connection reset by peer]

21:13 Quanttek has joined #bitcoin-wizards

21:13 <bliljerk101> amiller_ so in the case you propose, it would cost the sender money and the peer would gain the commission

21:13 <gmaxwell> el33th4x0r: the primary benefit of NG is that none of the intensive work of verifying things happens at the time of the mastership race.

21:13 <bliljerk101> this would be enforced in the contact

21:13 <bliljerk101> contract*

21:14 <bliljerk101> so the incentive here seems correct to me. thoughts?

21:14 <gmaxwell> el33th4x0r: the efficient transfer and perforward schemes have the same benefit, at least in the absense of adversarial authorship.

21:15 <amiller_> bliljerk101, my point with this example is that once the malicious seller has revealed that he's malicious and won't send the package, it's in the buyer's best interest to release their collateral anyway.. this is a bad outcome for the victim buyer

21:17 darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]

21:17 <bliljerk101> amiller_ correct me if i'm wrong, but i think you're confusing my algo with the marketplace itself. because there would not be a reason to even establish a DNIS chain if the seller was not going to send the package. there would be absolutely no point to that. the seller would lose commission for at least 1 peer, so he'd only be putting himself at additonal loss

21:18 <bliljerk101> the buying/selling isn't a part of my algo

21:18 <bliljerk101> my algo is the trustl-less transference of real world assets through a chain

21:19 <el33th4x0r> gmaxwell: agreed on the main benefit.

21:20 darmou has joined #bitcoin-wizards

21:20 <el33th4x0r> gmaxwell: but for weak blocks to serve the same purpose, miners would have to agree prior to mining. and that seems difficult. esp without a punishment mechanism for misbehavior.

21:21 zooko has joined #bitcoin-wizards

21:21 <el33th4x0r> gmaxwell: so a fully worked out solution that gets close to the same benefits may or may not be possible. if possible, it might be very complicated.

21:21 <el33th4x0r> gmaxwell: nevertheless, i'd be thrilled to see such a solution worked out. is this something you are planning to work on?

21:22 damethos has quit [Quit: Bye]

21:23 <bliljerk101> amiller_ also the buyer can't release any collateral. in the case that DNIS chain was used to transfer an asset that was purchased in a marketplace. only the seller would be able to release the last (i.e. recipient's) contract. and again, he'd be foolish to do this as he would lose all the collateral tied up in all previous peers' contracts' transactions

21:23 <bsm1175321> The NG guys didn't address my concerns that the current master is discoverable, and therefore DDoSable... :-(

21:24 <gwillen> bsm1175321: what's the procedure for discovering the master's IP? Just watch blocks and see where they're coming from?

21:24 <bliljerk101> i realize this is intricate system (it's hard, even for me as the designer to have fast conversation about it), but i think that's all the more reason we should review it seriously. i really tried to design this carefully, taking into account every possible incentive i could conceive

21:24 damethos has joined #bitcoin-wizards

21:24 <bsm1175321> gwillen: yes.

21:25 <gwillen> that seems like it would also lead to possible DDoS against current mining pools, if that were a simple procedure to follow.

21:25 <bsm1175321> ex-post-facto block publication adds significant byzantine protection.

21:25 <bsm1175321> gwillen: It does, and it is.

21:25 <gmaxwell> el33th4x0r: they do not have to agree prior to mining, in fact, thats where the efficient transmission comes in.

21:26 <gmaxwell> el33th4x0r: I've been working on efficient transmission on and off for a long time.

21:26 dEBRUYNE_ has joined #bitcoin-wizards

21:27 <gmaxwell> el33th4x0r: it's weird that you seem to regard something that requires _no_ changes in the bitcoin consensus rules as a long shot relative to bitcoin-ng!

21:27 <el33th4x0r> gmaxwell: i know all about the efficient xansmission work, had a hand in initiating that discussion and pointing towards some of the early strategies

21:28 <el33th4x0r> gmaxwell: so if there are multiple weak blocks, which ones can i as a merchant believe to look like the next block, given that i cannot know who will get the block?

21:29 <gmaxwell> This has nothing to do with merchants.

21:29 rusty has quit [Ping timeout: 240 seconds]

21:30 <el33th4x0r> ok how would weak blocks work? is there a spec i should read?

21:30 dEBRUYNE has quit [Ping timeout: 276 seconds]

21:31 erasmospunk has quit [Ping timeout: 272 seconds]

21:32 zooko has quit [Ping timeout: 244 seconds]

21:32 dEBRUYNE_ has quit [Read error: Connection reset by peer]

21:32 <gmaxwell> el33th4x0r: There are posts but it is not complex. miners announce candidate blocks, using POW 'weak blocks' to rate limit the process. Efficient differential transmission (including referencing earlier weak blocks) is used, so the amount of data transfer is small. Blocks commit to two sets of transactions, one for use as a weak block, and a subset for use if it is an actual block.

21:32 dEBRUYNE_ has joined #bitcoin-wizards

21:33 <gmaxwell> When an actual block is found, it is transmitted using a prior weak block (decided on a per hop basis, whatever shared context is most efficient) as a differential starting point.

21:34 <el33th4x0r> ok, that's what i thought. do you think this can achieve xput comparable to ng?

21:34 <gmaxwell> If blocks are selected to look like prior weak blocks, the amount sent at the latency critial time is just a constant (a weak block reference, nonce, etc.)

21:34 <gmaxwell> I believe it can.

21:35 <gmaxwell> It has some nice deployment benefits, including even blocks produced by non-participants benefit from it. (to the extent their blocks are similar to participant blocks)

21:36 <gmaxwell> It does not get you 'soft confirmations' (beyond perhaps being able to monitor weak blocks 'true' transaction sets, to gauge hashpower support); but I think that benefit in bitcoin-ng is mostly an illusion because the fee spliting scheme is not incentive compatible. (it's in everyone's interest to pay fees 'out of band' to bypass the split)

21:38 <bliljerk101> amiller_ are you the guy from zero cash?

21:38 <instagibbs> Thinking of it the other way, it's in everyone's own interest to stick just enough fees in the split to incentivize someone to build on top of the microblock. I have no idea how much that is.

21:38 <el33th4x0r> how does one reconcile and keep track of the N different weak block announcements from N different miners?

21:38 <gmaxwell> instagibbs: well the users would leave all fees out, and then the miner themselves would pay into that.

21:39 AaronvanW has quit [Ping timeout: 246 seconds]

21:39 <instagibbs> I had that thought too. :)

21:39 <instagibbs> but yeah, the fee sharing seems like "suggested donation" to me

21:42 frankenmint has joined #bitcoin-wizards

21:42 <gmaxwell> el33th4x0r: one can keep track of many, as they're relatively cheap (just a list of indexes for member transactions)-- but they do not have to be globally consistent, because the reference point chan change from hop to hop. (though with some efficieny loss if the reference isn't the one the miner used). So for example, one can keep the nearest block so far, and the N nearest misses more than N s

21:42 <gmaxwell> econds old from your perspective.

21:43 mpmcsweeney has joined #bitcoin-wizards

21:43 <gmaxwell> And you communicate to your peers which reference points you know, so they can use an acceptable one.

21:44 mpmcsweeney has quit [Client Quit]

21:44 * gmaxwell steps out for a bit

21:44 <kanzure> oh some of this deprecates previous weak-block talk

21:45 bramc has joined #bitcoin-wizards

21:48 Jeremy_Rand has joined #bitcoin-wizards

21:53 <el33th4x0r> gmaxwell: so every miner must send an updated weak block for every new xaction that modifies their block. this would scale as T*M with the number of miners (M) and transactions (T).

21:53 <el33th4x0r> gmaxwell: so the throughput benefit isn't comparable to NG.

21:54 <el33th4x0r> gmaxwell: and if you're not suggesting trusting weak blocks in some way, they don't help with latency.

21:58 jgarzik has quit [Quit: hotel-ward]

22:00 snthsnth has quit [Ping timeout: 252 seconds]

22:01 el33th4x0r has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]

22:05 hashtag has joined #bitcoin-wizards

22:06 el33th4x0r has joined #bitcoin-wizards

22:08 Dizzle has quit [Quit: Leaving...]

22:08 kgk has joined #bitcoin-wizards

22:11 malte- is now known as malte

22:13 AaronvanW has joined #bitcoin-wizards

22:14 <instagibbs> I am under the impression you'd set some diff thresshold and discriminate based on that. Not based on number of peers mining. So T will be there, but instead of M it's relative to that threshhold you pick.

22:20 erasmospunk has joined #bitcoin-wizards

22:22 Jeremy_Rand has quit [Ping timeout: 250 seconds]

22:22 nabu has quit [Ping timeout: 260 seconds]

22:26 <gmaxwell> el33th4x0r: I disagree. There is no need for an updated week block for each additional transaction. New transactions can simply wait until the next block.

22:27 <gmaxwell> el33th4x0r: I think two distinct benefits are being conflated. The improvement in network convergence and fairness, which I believe weak blocks plus efficient transmission provide.

22:27 zooko has joined #bitcoin-wizards

22:28 <gmaxwell> And "soft confirmations", which bitcoin-ng claims to provide but I believe could not provide in practice, because the soft confirmation depends on the fee sharing scheme which is not incentive compatible and I believe would be bypassed in normal operation.

22:30 <gmaxwell> (weak blocks could provide for a different kind of 'soft confirmation', e.g. letting people measure the share of hashrate that would immediately commit to their transaction)

22:31 King_Rex has joined #bitcoin-wizards

22:32 rusty has joined #bitcoin-wizards

22:32 darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]

22:35 zooko` has joined #bitcoin-wizards

22:36 rusty has quit [Ping timeout: 246 seconds]

22:37 zooko has quit [Ping timeout: 260 seconds]

22:38 StephenM347 has quit []

22:40 <el33th4x0r> gmaxwell: i see. you're suggesting a 2x increase in xaction latency. 20 min for 1 conf.

22:40 rusty has joined #bitcoin-wizards

22:41 <el33th4x0r> gmaxwell: on the fee sharing scheme,there's a lot of misunderstanding -- NG does not depend on that particular fee splitting for correctness. Described here: http://hackingdistributed.com/2015/11/09/bitcoin-ng-followup/

22:42 <el33th4x0r> gmaxwell: the soft confirmation from weak blocks is better than nothing but not as strong as NG.

22:42 davec has quit [Read error: Connection reset by peer]

22:42 devrandom has quit [Ping timeout: 250 seconds]

22:43 devrandom has joined #bitcoin-wizards

22:43 zooko` is now known as zooko

22:45 <bramc> What are 'weak' blocks?

22:45 <gmaxwell> el33th4x0r: I'll read! I realize the fee sharing is not fundimental, but I think it is strictly necessary for the weak confirmation to have force. E.g. you mine a weak block and then you can produce an unbounded amount of fradulent single confirmations during that window, and later too if you have a partitioned victim.

22:46 <gmaxwell> e.g. it was the threat of losing the fees if you got caught that prevents you from signing multple blocks but if there are no 'fees' visible to the system, that threat does not exist.

22:46 <gmaxwell> (at least not in the long term with zero subsidy)

22:47 <bramc> My guess as to what weak blocks are is that they're blocks which almost but not quite passed muster to form a new block, so they're deemed worthy of propagating and a real successful new block can shorthand what transactions it's accepting by referring to a chain of weak blocks to reduce propagation latency

22:47 <gmaxwell> bramc: yes.

22:47 davec has joined #bitcoin-wizards

22:48 <bramc> Sounds like a decent idea but doesn't change anything fundamental

22:48 <gmaxwell> bramc: in particular, start with the observation that if you have a consensus system in advance of mining, you can reduce mining latency to nothing, and so fairness impacts from latency go away. Then (maybe) observe that consensus is actually stronger than you need for that effect.

22:48 ThomasV has joined #bitcoin-wizards

22:49 <gmaxwell> bramc: I think it renders orphan rate largely independant from transaction load, which is pretty substantial.

22:49 <bramc> gmaxwell, Sort of depends on how weak you let the weak blocks be

22:49 <el33th4x0r> gmaxwell: you lose the block subsidy as well as the fees.

22:49 nanashi has joined #bitcoin-wizards

22:49 <gmaxwell> you can adapt what you'll accept based on how many you are seeing.

22:50 <bramc> Also, do you propagate all weak blocks or only the longest chain?

22:50 <gmaxwell> el33th4x0r: if you are assuming subsidy, then you are assuming an inflationary currency-- as bitcoin subsidy is only temporary.

22:50 <el33th4x0r> gmaxwell: the premise that there will be no fees is flawed here, or at least, "remains to be shown"

22:50 <bramc> If you have utxo commitments you probably want the rule that they don't have to be validated for weak blocks, otherwise that's a lot of computation for a whole lot of nothing.

22:51 <gmaxwell> el33th4x0r: in the ng scheme as I understand it a miner should _always_ accept a lower fee from a transaction that bypasses the fee system and pays them directly, because they get 100% of it. So users should always be willing to pay fees that way (and get half off on their fees).

22:52 <gwillen> gmaxwell: that's only true if users value cheaper transactions over earlier weak confirmations

22:52 <gmaxwell> (I'm not arguing that there won't be fees; I'm arguing that no rational party would participate in the 'official' fee scheme in bitcoin-ng, that instead they'd pay fees via additional outputs; and we've already had miners in bitcoin that accept fees that way in hte past)

22:52 <el33th4x0r> gmaxwell: no. as a user, you can always partition the fee F any which way you like, including 100 to 0, for the two miners surrounding the microblock. But 100-0 would be a bad idea, as it undermines the incentive to build on top.

22:52 <bramc> Come to think of it, weak blocks can be built into the peer protocol without touching the blockchain format at all

22:52 <el33th4x0r> gmaxwell: so a user would be hurting himself by going that route.

22:52 <gwillen> I think you have to make an argument about some kind of attackers doing that, not ordinary users -- their incentive to pay directly comes from wanting to get the earlier confirms from the microblocks

22:53 <bramc> It's just a form of compression of a block: "This block is that other weak block plus this delta"

22:53 <gmaxwell> el33th4x0r: Why would a user not pay 100%/0%, and leave it to the miner to decide to pay some fees forward?

22:54 <gmaxwell> gwillen: not earlier, but stronger weak confirmation, no? I would accept that argument.

22:54 <el33th4x0r> bramc: in a truly decentralized world where there are N miners, where N is large, there are N weak blocks. Not the most bandwidth efficient idea.

22:54 <el33th4x0r> gmaxwell: they would not, that's my point.

22:54 <gwillen> gmaxwell: well if the payor bypasses the fee split and pays directly to the miner who's working on the next keyblock, then there's no incentive for them to get any weak confirmation

22:55 <gwillen> the current keyblock holder will have no reason to mine them at all

22:55 <gmaxwell> el33th4x0r: There do not need to be N weak blocks, and the bandwidth costs of the weak blocks are only proportional to the difference between state.

22:56 <bramc> el33th4x0r, No the number of weak blocks is stochastic and a multiplier of the number of strong blocks depending on where you set your threshold

22:57 <nanashi> interesting to the testnet3 flip over to BIP101

22:57 <bramc> As long as the number of weak blocks is substantially smaller than the number of transactions accepted the overhead of them is no big deal

22:57 <nanashi> any idea what will happen next? is this good or bad?

22:58 darmou has joined #bitcoin-wizards

22:58 <el33th4x0r> bramc, "number of strong blocks"?

22:59 <bramc> el33th4x0r, If you set the threshold for 'accepting' weak blocks at six bits less than the threshold for a new block being minted (a 'strong' block) then you'll have about 64 times as many weak blocks as strong blocks

22:59 <el33th4x0r> for N outstanding transactions, and T transactions per block, there are N choose T possible weak blocks

23:00 <el33th4x0r> bramc: thanks, indeed, weak blocks require such measures to deter spam.

23:01 <el33th4x0r> here's another problem with weak blocks: smaller miners will not be able to mine them effectively, so they will be at a disadvantage when they discover a real block.

23:01 <bramc> It's also a good sanity measure to only propagate the longest chain of weak blocks you've seen

23:02 <bramc> How are smaller miners at a disadvantage for mining weak blocks effectively?

23:03 <bramc> Weak blocks should help everyone by making latencies be reliably lower

23:03 <el33th4x0r> when weak blocks require a PoW (which they would, to deter spam), small miners are likely to experience high variance when discovering a valid PoW.

23:04 <nanashi> whats a weak block

23:05 <gmaxwell> el33th4x0r: I'm not sure if you followed my earlier point that we've been talking about a system where the weak block commits to two transaction sets: one which is used if it is a weakblock, and another which is used if its is a block. This means that even if you have not produced a weak block, if your 'If I am a block set' matches a weak block then you get the perfect speedup, even though you d

23:05 <gmaxwell> id not create it.

23:06 <gwillen> gmaxwell: I missed the explanation of what you gain by separating the two transaction sets -- is there a quick summary?

23:07 <gmaxwell> gwillen: you do not suffere a disavantage if you find a real block before a weak block which reflects your preferences exists.

23:07 <gmaxwell> el33th4x0r: N choost T is not a useful model. As there is a logical selection criteria: highest fee-per-limit, so on average (and in the absense of adversarial behavior) the discrepencies will be small.

23:08 GAit has quit [Quit: Leaving.]

23:09 <el33th4x0r> gmaxwell: how do you protect the network from miners spamming weak-block-preferences. (and thx, btw, I hadn't quite caught on to prefs!)

23:10 erasmospunk has quit [Ping timeout: 276 seconds]

23:11 <el33th4x0r> gmaxwell: N choose T is indeed the number of possible weak blocks. one might prune them down, but that requires additional assumptions about which weak blocks are important.

23:12 <el33th4x0r> gmaxwell: that is to say, i agree that you could argue that we would not encounter as many in practice, iff you make some assumptions.

23:12 erasmospunk has joined #bitcoin-wizards

23:14 <gmaxwell> el33th4x0r: the spamming is prevented via the same POW mechenism. (in theory you could use any other functional mechenism -- but using POW has the property of sharing influence there equal to the actual finding of blocks)

23:14 <rusty> bramc: indeed, this is what I'm working on now for HK. Simulations seem to make it work quite well.

23:16 <rusty> gmaxwell: I have been using a 20x ratio for weak block threshold (ie. 30 seconds avg) but a 16x extra boost for the first weak block seen. This helps in the "full blocks" case.

23:17 <rusty> gmaxwell: of course, the "first weak block" heuristic is imperfect in a distributed system.

23:17 AaronvanW has quit [Ping timeout: 246 seconds]

23:19 rusty has left #bitcoin-wizards [#bitcoin-wizards]

23:20 <bramc> rusty, I don't understand what you're saying about first weak block. Also, are you judging the quality of weak blocks by the length of their chain and only accepting the longest one?

23:20 <gmaxwell> bramc: one _could_ use weak blocks to perform a pre-consensus; but I think it is not actually needed for the fairness benefits (though it may help soft confirmations)

23:22 ThomasV has quit [Ping timeout: 250 seconds]

23:24 <bsm1175321> If weak blocks were allowed to contain the same transaction in different weak blocks, and have multiple parent weak blocks, then I think this proposal is identical to my proposal of using a DAG instead of linked list (/chain)

23:27 <bramc> gmaxwell, What are the fairness benefits other than pre-consensus?

23:27 <bramc> It looks like a great trick for consistently reducing latency, not sure what else it buys.

23:27 <bsm1175321> While the chain can be removed in favor of a DAG, there's an intermediate state required for Bitcoin where the DAG results are checkpointed back to the chain.

23:28 <bramc> bsm117532 It's possible to use weak blocks without changing the blockchain format at all. You just 'compress' a block by saying 'apply this delta to that weak block'

23:28 ratbanebo has joined #bitcoin-wizards

23:29 ratbaneb_ has quit [Ping timeout: 240 seconds]

23:29 <bsm1175321> bramc: true. However then you can have weak block orphans, no?

23:30 <gmaxwell> bramc: the more latency there is in block transmission the less fair the bitcoin network is (larger miners get excess profits). When latency goes up with block size this is bad news for increased throughput.

23:30 King_Rex has quit [Remote host closed the connection]

23:30 <bramc> Yes you can have weak block orphans, but so what? In some sense they're all orphaned when a new real block comes out.

23:31 <bramc> gmaxwell, Right. I don't understand what you mean about pre-consensus and fairness though.

23:31 <gmaxwell> by preconsensus above I mean that a weak block scheme could be 'very strong' in the sense that later weakblocks and blocks are required to agree with prior weakblocks. And I was just saying that I don't believe a system this strong is actually needed to gain most of the fairness benefit.

23:31 <bsm1175321> bramc: I want to additionally divide the block reward among weak block publishers.

23:32 <bsm1175321> Doing that decreases miner centralization by making more frequent, smaller block rewards.

23:32 orik has joined #bitcoin-wizards

23:33 <bramc> gmaxwell, The reason for only using the longest chain is to encourage everybody to use older weak blocks when making newer weak blocks, because that reduces latency.

23:33 <bramc> I'm assuming that weak blocks are themselves a chain

23:33 damethos has quit [Quit: Bye]

23:33 <bramc> bsm117532 That's a bit hard with the current blockchain. This other stuff we're talking about requires no blockchain changes whatsoever.

23:34 <gmaxwell> bramc: right and what I'm pointing out is that I think that making a weak block chain ("pre consensus") is actually more than is needed.

23:35 <bramc> gmaxwell, Yes more than is needed, but is there any downside to it?

23:35 <bsm1175321> Well people are honing in on the idea of having a smaller, faster layer between 10m bitcoin blocks. (e.g. Bitcoin-NG does the same thing) One has the opportunity to make this new layer be anything we want, why duplicate the blockchain with its problems (orphans, centralization) in that layer?

23:35 <gmaxwell> complexity/overhead, perhaps. Unclear.

23:37 <bramc> gmaxwell, I think it's if anything simpler, because weak blocks 'want' to be a chain, because regular blocks are expressed as a diff off a weak block, so why not make weak blocks be diffs off of weak blocks?

23:38 <bramc> bsm117532 There are deep issues with getting the time until a transaction is 'safe' down, regardless of blockchain format. Even when it's really working, it's going to be like 3 minutes instead of 30 minutes, which is still problematic. Micropayment channels are a much better approach.

23:39 <bsm1175321> A faster layer doesn't mean a transaction is "safe" faster. Just that it gets transmitted faster.

23:39 GAit has joined #bitcoin-wizards

23:39 Newyorkadam has joined #bitcoin-wizards

23:39 <sipa> transactions are transmitted instantly if you're not using the blockchain as a communication mechanism, but just send it directly to the receiver

23:40 <mrkent> gmaxwell: based on the above convo, it sounds like weak blocks take work to produce, but also benefits those who do not put work in. If this is true, what is the incentive to produce weak blocks?

23:40 <gmaxwell> bramc: you would make weak blocks diffs of weak blocks for sure, but the observation I made is that how you transmit and what you commit to can be completely orthorgonal.

23:40 <gmaxwell> E.g. you can make a weak block X and then differentially transmit it relative to X, or Y, or Z and do so all at once to different peers.

23:41 GAit has quit [Client Quit]

23:41 <bramc> gmaxwell, Having peers use the longest weak chain maximizes the chances that they'll all be working off the same thing

23:41 <bsm1175321> gmaxwell: would X, Y, Z have independent proofs of work?

23:41 <bramc> It has the same benefits as it does for the regular blockchain

23:41 GAit has joined #bitcoin-wizards

23:42 <gmaxwell> bsm1175321: NO

23:43 atgreen has joined #bitcoin-wizards

23:43 <bsm1175321> gmaxwell: then they share the same PoW but you're sending different sets of transactions to different peers?

23:43 <gmaxwell> bsm1175321: again, the commitment and the transmission have no reason to be at all connected that I'm aware of. When you transmit something to a peer you should do so with the most efficient means available for doing so.

23:43 <bramc> My guess for the best time between weak blocks is about 30 seconds, same as rusty's

23:43 <bsm1175321> I see.

23:44 <gmaxwell> bsm1175321: no, its the same transactions, but you can use different basises for them.

23:44 <bramc> Oh duh, when you're making a new block it doesn't have to explicitly reference a particular previous weak block, you can express any of them as diffs off any others. Took me a bit to realize that.

23:44 <gmaxwell> Say you know peer Y knows weak block Z which happens to be exactly the same as Z2, so you'd use Z to Y as the reference for Z2. But peer Q does not know Z, it knows M and N and M is closer, so you use that.

23:45 <gmaxwell> now sure, it's best if everyone is using a common thing to go off of, you get more efficiency; but it is not strictly required.

23:46 <bsm1175321> Now I'm confused. I thought the weak block *was* a delta (and that was it's point) and contained a PoW. But now you're saying you're going to transmit deltas relative to weak blocks and they don't require a new PoW?

23:46 <bramc> You can also potentially do a diff off a combo of two weak blocks. Take block A, then everything in block B which is still allowed, then do this diff

23:46 <gmaxwell> and it may be good to not strictly require it so that you punish different policies less. E.g. big miners are censoring some transaction, a small miner is not, you don't want to punish the small miner by requiring he work only be differentially referenced to the big miners, rather than other non-censoring miners and himself.

23:47 <bramc> bsm117532 A weak block is a partial - it's a regular block which didn't make the PoW cut

23:47 <sipa> bsm1175321: a weak block is an almost-valid block, it's not different from a real block (except not meeting the PoW)... but you can use the same differential transfer mechanism for them

23:47 <bsm1175321> Gotcha.

23:47 <gmaxwell> bsm1175321: all weak blocks are commits to sets of transactions above and beyond the blockchain. And you use differential transmission to efficiently transmit weak blocks between peers (as normally the weak blocks are almost all the same)

23:49 <bsm1175321> And unfortunately that scheme isn't going to allow partial block rewards very easily. :-/

23:49 <bramc> Since transaction removals can be expressed with a very compressed bitfield, it should never be all that inefficient to transmit a bunch of weak blocks to a peer compared to transmitting just the biggest weak block to them.

23:50 <bramc> bsm117532 Right, that's a different problem

23:50 GAit has quit [Quit: Leaving.]

23:51 Newyorkadam has quit [Quit: Newyorkadam]

23:51 <gmaxwell> In any case, there are hidden costs to worry about; it's not all puppies and unicorns. :)

23:51 <bsm1175321> This is an excellent opportunity to address it -- at the point we're adding a smaller faster mining-based communicatoin layer.

23:52 darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]

23:53 nanashi has quit [Quit: Leaving]

23:54 ratbanebo has quit [Read error: Connection reset by peer]

23:55 <bsm1175321> e.g. the block reward could be divided among the weak block publishers, weighted by the hash they generate relative to the difficulty.

23:55 <sipa> how so? there is no strong consensus about weak blocks

23:55 c-cex-yuriy has quit [Quit: Connection closed for inactivity]

23:55 <bramc> bsm117532 That makes orphaning be a serious issue and opens up the whole can of worms which the blockchain is designed to solve in the first place.

23:55 <sipa> you can't prove that a weak block existed

23:55 ratbanebo has joined #bitcoin-wizards

23:56 <sipa> exactly, if you do that, you could just as well turn the weak blocks into full ones

23:56 <bsm1175321> bramc: That's the reason to use a DAG and get rid of the orphaning issue.

23:57 Newyorkadam has joined #bitcoin-wizards

23:57 <bsm1175321> sipa: Good point. Not sure how to address that.