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
<bsm1175321>
Creating an asset, selling it (caveat emptor) and profiting off it is *illegal* unless done under the correct regulatory framework, and for good reason.
<bsm1175321>
He claims that the Lamport 3f+1 result is synonymous with asynchronicity. I don't think that's true...
<bsm1175321>
(Relevant because a braid is an asynchronous blockchain)
Newyorkadam has joined #bitcoin-wizards
<katu>
bsm1175321: is there a paper for this somewhere?
<bsm1175321>
katu: Not that I know of. I know, I can't be bothered with videos either.
<katu>
i just skipped through, but have hard time understading what kind of bond/commitment this actually is. i know that vitalik tried to propose various punishing schemes (for competing forks and such), is this one of those?
<bsm1175321>
It's just Pedersen commitment, as I understood
<katu>
bsm1175321: yes, he does explain pedersen commitments for first 20 minutes i skipped through. i mean 24m onwards.
<bsm1175321>
That's where I got lost. I twittered Charles to link the other half.
<bsm1175321>
I do think he probably has a workable idea, but I also think that any PoS system only works with a PoW bootstrap, and if you dispense with the PoW, then it's a zero sum game and results in monopoly control, at which point profit maximization fails. A PoS/PoW hybrid can mitigate attacks for large miners having < 51%, as has been shown by others.
AusteritySucks has quit [Ping timeout: 255 seconds]
Ylbam has quit [Quit: Connection closed for inactivity]
oleganza has joined #bitcoin-wizards
Giszmo has quit [Remote host closed the connection]
Giszmo has joined #bitcoin-wizards
<katu>
bsm1175321: to me, costless simulation is a dark dungeon full of traps and circular logic
<katu>
there are crutches to solve some of its problems, of course, like piggybacking NUMS timestamps from other PoW chain, thus making the altchain dependent on it. but even then.
<gmaxwell>
if you've already got a consensus then having a consensus is easy. what a surprise.
HostFat_ has joined #bitcoin-wizards
HostFat has quit [Ping timeout: 244 seconds]
oleganza has quit [Quit: oleganza]
rusty2 has joined #bitcoin-wizards
gielbier has quit [Read error: Connection reset by peer]
gielbier has joined #bitcoin-wizards
<bsm1175321>
Yep.
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
HostFat_ has quit [Quit: Leaving]
Mazz_ has quit [Ping timeout: 276 seconds]
GAit has quit [Read error: Connection reset by peer]
GAit has joined #bitcoin-wizards
<midnightmagic>
:-D
Samdney has left #bitcoin-wizards ["Verlassend"]
pro has quit [Quit: Leaving]
Mazz_ has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
btcdrak has quit [Quit: Connection closed for inactivity]
mdavid613 has quit [Quit: Leaving.]
grubles has quit [Quit: Leaving]
jtimon has quit [Ping timeout: 240 seconds]
oleganza has quit [Quit: oleganza]
GAit has quit [Quit: Leaving.]
amiller has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
contrapumpkin has joined #bitcoin-wizards
copumpkin has quit [Ping timeout: 244 seconds]
Alopex has quit [Remote host closed the connection]
chjj has quit [Ping timeout: 276 seconds]
Alopex has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
<Taek>
The 2015 paper "On Scaling Decentralized Blockchains" showed that block propagation time was linear with block size for sufficiently large blocks
<Taek>
(about 80kb iirc)
<Taek>
and that the 90% nodes were able to do about 55Kbps throughput
<Taek>
does anybody know if these numbers have gotten better, or what the characteristics of the 10% slow nodes were that made them so slow?
<Taek>
the 50% was >400Kbps, which is obviously a whole lot better
<Taek>
hops introduce delay proportional to the length of the path."
<Taek>
"Moreover, due to lack of pipelining, propagation over multiple overlay
<Taek>
I guess I was misreading the throughput
<Taek>
If the paper is suggesting that pipelining could increase the throughput, that means that the slow nodes in their analysis were not downloading blocks the whole time
ThomasV has quit [Ping timeout: 252 seconds]
gielbier has quit [Quit: Leaving]
Newyorkadam has quit [Quit: Newyorkadam]
chjj has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
oleganza has joined #bitcoin-wizards
Emcy_ has quit [Remote host closed the connection]
Emcy_ has joined #bitcoin-wizards
PeterR has joined #bitcoin-wizards
<PeterR>
Taek: if the experiment were repeated with Xthin-enabled (or CB-enabled) nodes, the "throughput measure" would be significantly better.
<PeterR>
For example, we found that Xthin blocks propagated 5.6X as fast across the normal P2P network, and 9.7X as fast thru the GFC, so I'd expect a corresponding increase in "throughput" as defined by the Cornell paper.
<Taek>
PeterR: were your experiments performed on a 6000 node network, and does 5.6X as fast apply to the 90 percentile?
<Taek>
e.g., were the slowest 10% of nodes also seeing speedups of 5.6X?
<Taek>
Though I only skimmed it, I don't think your analysis hits nearly the depth that I'm looking for
<PeterR>
Yes, our experiments were performed on main-net over 8000 blocks.
afdudley has quit [Read error: No route to host]
<PeterR>
It probably doesn't hit the depth you're looking for. We're only comparing single-hop propagation times between Xthin and standard block propagation. The Cornell paper is looking at propagation across the entire network.
ThomasV has joined #bitcoin-wizards
<PeterR>
But clearly improving single-hop times improves network wide propagation times, ceteris paribus.
<PeterR>
I'd love to see a new test on a large number of nodes, where all the nodes support Xthin (or CB).
<PeterR>
Would be interesting to see the improvements over a large node population (rather then just over a large block population).
<Taek>
so, hopefully I'm not reading this wrong, but the paper states that throughput begins to dominate latency at a block size of about 80kb, at which point the throughput is 55Kbps
<Taek>
which means that the latency for an 80kb block is about 1.5s total
<Taek>
That number is important to my Scaling Bitcoin proposal, and if it really is that low, it makes my life a lot easier
<PeterR>
Right. Latency dominates for smaller blocks.
<Taek>
especially b/c it seems like Tor only adds a few seconds of latency
<Taek>
(my proposal is essentially to reduce the blocktime to 1 second)
<Taek>
security is pretty easy to achieve, but at the cost of a high confirmation time
<Taek>
like, 30 minutes
<PeterR>
It's something like time = latency + k * blocksize
arubi has quit [Ping timeout: 252 seconds]
<PeterR>
What is the advantage of increasing the confirmation time to 30 min?
<Taek>
well, requires a lot more context
<Taek>
but basically there's a system I'm working that's braids based
<PeterR>
I think braids has a lot potential.
<Taek>
and, as long as an attacker can't reasonably mine X blocks in a row, there will be no orphans on the network period
<Taek>
Simulations are suggesting that X needs to be around 600.
<Taek>
If you bring the blocktime down to 1 second though, to keep pace with the 4MB throughput you end up with blocks that are 6kb each
<Taek>
one huge advantage here though is that throughput is constant instead of bursty
<Taek>
so you get this great pipelining that you just can't do in standard satoshi style consensus
<Taek>
which means that you can potentially push the ratelimit up from 4MB. The paper doesn't really go into enough detail though to suggest what sorts of gains you get from pipelining
<PeterR>
Have you talked to Bob about how he did his modelling?
<Taek>
not in-depth yet
<Taek>
the SB deadline has pushed me to actually put together proper proofs ha
<Taek>
until now I haven't really been that rigorous, been happy to handwave
<PeterR>
Good! That's what deadlines are great for.
btcdrak has joined #bitcoin-wizards
<PeterR>
We've submitted a proposal to present more test results for Xthin, and I'm trying to finish a proposal to present on subchains.
danrobinson has joined #bitcoin-wizards
<PeterR>
Regarding rigorous proofs, Bob was explaining a proof he made regarding the expectation value between confirmations in a Braid.
<PeterR>
Ugh....it seemed quite profound at the time--like it would apply more generally than just to Briads--but I forget the essence of it now.
BashCo has quit [Remote host closed the connection]
gmaxwell has left #bitcoin-wizards [#bitcoin-wizards]
moli has quit [Ping timeout: 250 seconds]
daddinuz has quit [Quit: Leaving]
jannes has joined #bitcoin-wizards
<amiller>
Taek, pipelining wouldn't increase the throughput, at least the assumption there at least is that the slowest node on a path is the one that constrains the throughput
<Taek>
so, my guesstimate of the network propagation that was happening there is that a node would get a block in full, validate it, then propagate it
<Taek>
which means that if a block was large, it'd download the *whole* block before doing any validation or uploading, and that would cause a severe bottleneck
<Taek>
elsewhere in the paper it was stated that the bandwidth for the 90 percentile nodes was 3mbps
<Taek>
but I could see where a single node bottleneck could cause issues
<Taek>
I still imagine that pipelining would get you large gains
<Taek>
also, would it be safe to assume in a continuous bandwidth scenario that the slowest node could be routed around via other peers?
<Taek>
perhaps that's too optimistic
<midnightmagic>
Oh, what a surprise. Ban-evading again.
alan_ has joined #bitcoin-wizards
alan_ is now known as Alanius
blkdb has quit [Ping timeout: 260 seconds]
gribble has quit [Read error: Connection reset by peer]
sipi has quit [Quit: Leaving]
<sipa>
Taek: fibre relays before receiving the full block
<sipa>
and it seems to help a lot
Guyver2 has joined #bitcoin-wizards
blkdb has joined #bitcoin-wizards
cdecker has quit [Ping timeout: 264 seconds]
tripleslash has quit [Ping timeout: 265 seconds]
gribble has joined #bitcoin-wizards
cdecker has joined #bitcoin-wizards
Hunger- has quit [Ping timeout: 260 seconds]
Hunger- has joined #bitcoin-wizards
blkdb has quit [Read error: Connection reset by peer]
blkdb has joined #bitcoin-wizards
tripleslash has joined #bitcoin-wizards
<vega4>
Taek: thank you for posting the paper, I haven't seen it before
blkdb has quit [Ping timeout: 260 seconds]
pro has joined #bitcoin-wizards
blkdb has joined #bitcoin-wizards
Emcy_ has quit [Quit: Leaving]
Emcy has joined #bitcoin-wizards
lmatteis_ is now known as lmatteis
Giszmo has joined #bitcoin-wizards
blkdb has quit [Ping timeout: 260 seconds]
JackH has quit [Ping timeout: 240 seconds]
blkdb has joined #bitcoin-wizards
blkdb has quit [Ping timeout: 260 seconds]
rusty2 has joined #bitcoin-wizards
blkdb has joined #bitcoin-wizards
moli has joined #bitcoin-wizards
rusty2 has quit [Ping timeout: 265 seconds]
BashCo_ has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 244 seconds]
blkdb has quit [Ping timeout: 260 seconds]
blkdb has joined #bitcoin-wizards
blkdb has quit [Ping timeout: 260 seconds]
blkdb has joined #bitcoin-wizards
blkdb has quit [Ping timeout: 260 seconds]
laurentmt has joined #bitcoin-wizards
molz has joined #bitcoin-wizards
moli has quit [Ping timeout: 264 seconds]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
xeon-enouf has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
blkdb has joined #bitcoin-wizards
blkdb has quit [Ping timeout: 260 seconds]
blkdb has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
vega4 has quit [Ping timeout: 250 seconds]
Newyorkadam has quit [Quit: Newyorkadam]
Samdney has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
vega4 has joined #bitcoin-wizards
cdecker has quit [Ping timeout: 260 seconds]
Guyver2 has quit [Ping timeout: 252 seconds]
Guyver2_ is now known as Guyver2
blkdb has quit [Ping timeout: 260 seconds]
veleiro has quit [Ping timeout: 250 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
grubles has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
GAit has quit [Read error: Connection reset by peer]
Guyver2 has quit [Ping timeout: 252 seconds]
Guyver2_ is now known as Guyver2
GAit has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
assder has joined #bitcoin-wizards
blkdb has joined #bitcoin-wizards
BashCo_ has quit [Remote host closed the connection]
contrapumpkin is now known as copumpkin
face_ has joined #bitcoin-wizards
<bsm1175321>
Just caught up on that conversation... Taek keep in mind that the "fastest block time" as defined by creating a total-ordering on the braid (finding cohorts) is around 10 seconds. Pushing the block time down below that results in exponentially-increased time between total-ordering (cohort) events, because you're waiting for the network to be accidentally quiescent for a time proportional to the network size.
bsm117532 has quit [Remote host closed the connection]
bsm117532 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
Mazz_ has quit [Ping timeout: 244 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
Mazz_ has joined #bitcoin-wizards
jannes has quit [Quit: Leaving]
Sosumi has quit [Ping timeout: 276 seconds]
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
mdavid613 has joined #bitcoin-wizards
<Taek>
<bsm1175321> Taek keep in mind that the "fastest block time" as defined by creating a total-ordering on the braid (finding cohorts) is around 10 seconds
<Taek>
our ordering algorithms are different
<bsm117532>
Well the fundamental time scale of consensus is the size of the network, and is ~few seconds, you can't get faster than that and maintain consensus.
<Taek>
mine can :)
<Taek>
total ordering is based on the highest block that you know about
<bsm117532>
Uh...no, if I'm on the other side of the Earth, I can't possibly know...
<bsm117532>
Consensus is defined globally.
<Taek>
right, so instead of getting consensus on the immediate block, you get consensus on a block with X confirmations
<Taek>
beyond X confirmations, I can prove that causing a reorg would require Y much work, and I can show that, assuming no 51% attackers, Y much work is practically impossible to achieve
<Taek>
all that without requiring that we aren't actually seeing the same list of confirmations
<Taek>
as long as we each have X confirmations, the merging takes care of the rest
<bsm117532>
Can you define "confirmation" for you in the context of a DAG?
<Taek>
Where X confirmations needs to be sufficiently large, on the order of 5-30 minutes
<Taek>
the number of confirmations on a block is all known descendents of that block
<bsm117532>
I'm using "cohort" = total order as the definition of "confirmation" -- you mean something different.
<Taek>
yes
<Taek>
that is perhaps what is causing the confusion then
<Taek>
my merging algorithm doesn't have any cohorts
<Taek>
actually, I've completed the full description of my merging algorithm. I'll post it to pastebin
<Taek>
the security proofs and txn fee handling isn't finished yet
<Taek>
hopefully today though
<bsm117532>
But consider a DAG where one node branches to two, and then merges (a diamond). Now take one side of that diamond and insert several nodes.
PaulCapestany has quit [Read error: Connection reset by peer]
<bsm117532>
Yeah I've been ignoring txn fees too :-/
PaulCapestany has joined #bitcoin-wizards
<Taek>
This week I came up with a pretty great solution to ensure miner fairness when including txn fees
<bsm117532>
The diagram I describe has two notions of "confirmations" seen by different participants, before the merge. You don't have consensus until the merge.
<Taek>
pastebin sadly does not render markdown
<Taek>
so you'll have to navigate to the beautiful pictures manually
<bsm117532>
All of your diagrams are complete cohorts (in other words they start and end with a single block). Sure, you can further define an ordering within a cohort if you desire.
<bsm117532>
But that ordering is impossible until the merge happens.
<Taek>
bsm117532: these cohorts can be assumed to be incomplete
<Taek>
e.g. people on the other side of the network may be viewing a different set of blocks
<Taek>
the 6th image sort of demonstrates that
<Taek>
it shows what happens when a block gets 100 confirmations, and then 200 new blocks are added to the longest known chain
<bsm117532>
And they could be seeing double spends. You can't know what you don't know, and you don't have consensus until you do.
<Taek>
the handling of double spends is explained at the bottom
<Taek>
and then it says 'we'll restore SPV later' because you're only seeing an excerpt of the full post
<Taek>
the part where we bring back SPV is not fully written yet
<Taek>
but basically, we make it so that you don't need to know if there's a double spend or not, you just include all the blocks and all the transactions
<Taek>
then you use post-processing to determine which parts of the block get included in consensus.
vega4 has quit [Quit: Leaving]
<bsm117532>
What I'm saying is that you do post processing when a merge happens (or more generally, when a cohort is formed). Prior to the merge you can't order the blocks.
<bsm117532>
Ordering, (within a cohort) for the purpose of resolving double spends can be done in many ways, I'm just using the usual "highest difficulty" rule. I'm not sure why you need to invent a new ordering...
bsm117532- has joined #bitcoin-wizards
<bsm117532->
Any other ordering will be gamed using mining hash power anyway. So "highest difficulty" is really the only ordering should use.
<bsm117532->
e.g. you can order a cohort just using block hashes. But someone will grind that hash to dictate the order in their favor.
<bsm117532->
I can show how to compute "highest work" in the presence of a DAG, and in the presence of non-constant difficulty targets among the blocks to be ordered.
<Taek>
well, you always have an ordering based on the full list of blocks you know about
<Taek>
my ordering description is also highest-work
<katu>
one fun approach is to make the grind itself the PoW function. each block projection into the future is still 1 bit of difficulty...
<bsm117532->
Take: there's exactly one correct answer to "highest work" and if that's what you have it will be identical to mine. :-)
<bsm117532->
*Taek damn autocorrect
<katu>
(imposes limit on minimum unique inputs and block size)
<Taek>
I count work by summing all of the work of all known unique ancestors
<Taek>
so any given block has a 'relative height' determined by all known ancestors directly for that block
<bsm117532->
A sum only works for constant difficulty (a la Satoshi's longest chain rule)
<Taek>
well, if that given block is the highest work block you know about, relative height is the same as absolute height
<Taek>
no you take into account the difficulty differences
<bsm117532->
Now we have to talk about how retargets happen...
<Taek>
you sum the difficulties of the ancestors
<Taek>
naively, retargets can work just the same as in Bitcoin
<Taek>
you get some funky incentives, but it ends up making a difference of only a small percent, and only applies a small percent of the time, so imho it's not worth worrying about
<Taek>
but that's also dicussed in a portion of my writeup that's incomplete atm
<bsm117532->
Retargets are a synchronous event, and the DAG is intended to be asynchronous. It's not so trivial. :-)
Chris_Stewart_5 has joined #bitcoin-wizards
<Taek>
you use a block's relative height (the parents it was pointing at) to determine which side of the retarget it is on
<Taek>
after the merge, it may be on the other side of the retarget, but you just forgive the block
<Taek>
the funky incentives come in because if the difficulty goes up, miners will want to have their blocks be on the pre-adjustment side of the fork
<bsm117532->
I've moved to a window of acceptable difficulty targets, so that retargets are continuous (the window changes over time)
<Taek>
which means you'll get a bunch of blocks with high gaps as the miners compete for that extra revenue
<Taek>
I was at one point trying to design a continuous difficulty adjustment
<Taek>
but decided it added too much complexity
<Taek>
primarlily for the purposes of making it more easily understandable, I've chosen to accept the awkward incentive tradeoff, because ultimately it only makes a difference of like 0.1% in revenue for a miner that is strategically mining around the diffiulty gap vs. a miner that is not
<bsm117532->
It's not so hard... Basically the size of the network can be directly translated into the window. Just a little math...
Newyorkadam has joined #bitcoin-wizards
<katu>
huh?
<katu>
i thought the only gauging factor of network size is miner competition, assuming you allow it to manifest somehow (orphans etc)
<katu>
and that its often a prtetty unstable guess
bsm117532- has quit [Read error: Connection reset by peer]
bsm117532- has joined #bitcoin-wizards
AndChat-7049 has joined #bitcoin-wizards
<bsm117532>
"size" is measured in seconds, and is the transit time for data across the network.
<bsm117532>
Your reward schedule is a function of time R(t), and given a window of time dt defined by the network size, you can compute dR, the reward window, from the derivative dR/dt
[7] has quit [Ping timeout: 255 seconds]
TheSeven has joined #bitcoin-wizards
<katu>
so, you mean adjusting window to observed latency of propagation. again, how do you actually plan to measure latency?
<bsm117532>
That latency is measured implicitly by the orphan rate in bitcoin, and the "width" of a braid/DAG -- average number of siblings.
bsm117532- has quit [Ping timeout: 260 seconds]
BashCo has joined #bitcoin-wizards
<katu>
well, in bitcoin it's clear cut - adversary does not have much incentive to inflate orphan rate, as they'd hurt themselves.
<katu>
but with dag, the whole point is to reward "orphans"
<bsm117532>
Yes. I argue for "Equal pay for equal (proof-of-) work"...all valid PoW hashes get rewarded.
<bsm117532>
Because an asymmetry in rewards creates the selfish mining incentive.
<katu>
just saying that using the dag width to influence *anything* does not strike me as good idea
<katu>
given that said width can be inflated at no cost, since you explicitly adjust for it
<bsm117532>
Good point.
Newyorkadam has quit [Ping timeout: 264 seconds]
jtimon has quit [Remote host closed the connection]
* bsm117532
ponders
<katu>
i suppose it can be fixed by still slightly disincentivizing wide dag, but unsure how
Newyorkadam has joined #bitcoin-wizards
<NewLiberty>
So it becomes what could be considered a traditional block chain at each old-enough merged braid?
laurentmt has joined #bitcoin-wizards
<bsm117532>
NewLiberty: yes. By defining total-ordering events (what I call a "cohort" -- a group of blocks) those transactions can be grouped and organized into a chain.
laurentmt has quit [Client Quit]
<bsm117532>
The simplest merging event is having a block where *all* previous blocks are its ancestors. But you can have a 2-block parallel merge if both blocks have all preceeding blocks as ancestors. And so on for 3, 4, etc.
oleganza has joined #bitcoin-wizards
<NewLiberty>
this complicates references to braid states somewhat, except at cohorts. To refer to a transaction within several blocks at differing heights from the most previous cohort.
<katu>
hmm, this sounds almost like fast chain of blocks + slow superblocks in p2pool fashion
<bsm117532>
A transaction can be mined into multiple blocks, but by the "highest work" rule or Taek's ordering, only the first one is considered. The second appearance of the same transaction doesn't modify the UTXO set.
<bsm117532>
katu: it is indeed very similar
<Taek>
(in the simple organization)
<Taek>
(to deal with transaction fees fairly... you establish 'consensus points' and then select transactions at random to be the 'real' transaction)
<bsm117532>
So NewLiberty I'd say, don't hand out references to the second appearance of the transaction...
<katu>
bsm117532: so, the "slow" superblock (which tries to canonicalize all precedeing transactions, if possible) would behave pretty much same as bitcoin, like NewLiberty said.
<katu>
their orphaning could be rare, but it could still happen.
<NewLiberty>
defining second appearance is the complication was contemplating
<Taek>
katu: depending on how you define when a cohort counts as a 'superblock', you can make orphaning extremely rare, like 1-in-quintillion rare
<NewLiberty>
It works only from a reference frame
<Taek>
*assuming no 51% attacker
<bsm117532>
katu: There is no synchronous point where a single actor can create said superblock. The superblocks (cohorts) are decided by examining the graph structure instead.
<bsm117532>
There can be no orphaning of cohorts.
<katu>
Taek: superblocks can't be reliably paced, typically they're simply blessed by bing, say, 1 in 256 blocks by blessing all blocks with 256x higher difficulty as blessed, in same way as p2pool does.
<katu>
or is there a way to pace those non-stochastically?
<Taek>
bsm117532: what happens if a completely new alternate history is provided where no blocks are in common, but the new history has substantially more work?
<bsm117532>
Cohorts are stochastically paced, since they're derived from individual blocks, which are themselves stochastically paced.
<katu>
then you'll inevitably get close races
<katu>
and orphans
<Taek>
katu: at least in my merging process, a 'superblock' is more of a rolling idea, and it's essentially 'anything with X confirmations', where X is on the order of 600
<Taek>
*300
<Taek>
but block times are on the order of 1 second
<Taek>
so you get confirmations in about 5 minutes
<Taek>
*
<bsm117532>
Taek: When a block appears naming your new chain and the old one, their UTXO sets are merged. Double-spends are decided in favor of the side with higher work.
<NewLiberty>
If the number of threads grows to a very large number, could there become a point past which there will never again be a cohort?
<bsm117532>
What changes is the definition of "confirmation" -- that is a calculation that takes into account the (known) amount of work, resulting in a probability. There's no rule like "6 blocks deep" that makes sense...
<Taek>
ah yeah, I'm not being perfectly consistent with the definitions. Sorry about that, I will try to keep things clear
<bsm117532>
NewLiberty: As the block time decreases, the probability of that happening goes up exponentially fast -- because you're waiting for an accidental quiescent period on a Poisson process.
<bsm117532>
katu: an "orphan" is just an unmerged chain tip. Any miner can add that chain tip as one of his block's parents, merging it back into the main chain. Miners are incentivized to do this because it increases the total work behind their own block.
<Taek>
yeah but if you allow orphans to be merged from arbitrary points back you get problems with long range attacks
<bsm117532>
How do you perform such an attack?
<Taek>
e.g. someone mines blocks for weeks and then presents hundreds of unmerged blocks all at once
<bsm117532>
How is that an attack, and what does the attacker gain by doing that?
<bsm117532>
(algorithmically, we can handle it...)
<Taek>
how do you order blocks?
<Taek>
say we have the historic chain, that's 50,000 blocks
<Taek>
and then we have some new parts of the chain, that's 100 blocks
<Taek>
and then the attacker dumps in 200 blocks that he's been mining for weeks
<bsm117532>
I see where you're going.
<Taek>
how does the merging algorithm handle that?
<Taek>
if the attacker blocks ignore the 100 blocks, does the attacker's block get ordered first?
<Taek>
but also, you get this data flood, which is a DoS attack on the network
<bsm117532>
Define the notion of "cohort" recursively (so, sub-cohorts). Use the network size parameter to define when you switch algorithms from including things in the cohort, to creating sub-cohorts.
<NewLiberty>
A DoS attack with quite a large reward for resolving it however, yes?
<bsm117532>
IOW if a bunch of blocks appear late, it's one giant cohort, according to my definition.
<Taek>
if the tip of those 200 blocks have references to the 100 recent blocks, does it create a giant cohort of 300 blocks?
<Taek>
with the 100 block sub-cohort?
<bsm117532>
So you need a second definition of "sub-cohorts" so that you can recurse.
<bsm117532>
Taek: correct.
<Taek>
wouldn't that cause problems with achieving consensus? When do you know that a transaction is confirmed if there's this constant threat of 200+ blocks being dumped into the network?
<NewLiberty>
It sort of relies upon the transactions and the mining using a similar network, so that information about transactions flows in the same ways that the mining does.
<bsm117532>
Confirmation is defined by using the visible hashpower compared to the "high water mark" of the highest hashpower ever seen. When I see 95% of the hashpower, an attacker with 5% won't be able to reverse any transactions. When he broadcasts his 100 blocks, they will be a minority fork.
<NewLiberty>
Or that the mining has better flow or not much worse
<katu>
i still like satoshi's fix to selfish mining more
<bsm117532>
katu: what's that?
<katu>
it "fixes" itself over time with decreasing reward and higher fees
laurentmt has joined #bitcoin-wizards
<katu>
bsm117532: still, that does not invalidate what you're doing, especially for new altcoins, selfish mining could prove destructive way before diminishing coinbase reward incentive kicks in
<katu>
but for bitcoin, fees already start being somewhat lucrative, they account for what, 5-10% now?
<bsm117532>
I had some argument that a fee-only coin was unworkable. It's escaping me now though...
GAit has quit [Read error: Connection reset by peer]
<katu>
yeah, all other bootstrap schemes seem just less appaling than fair mining race
GAit has joined #bitcoin-wizards
Wazza has joined #bitcoin-wizards
<NewLiberty>
This system could resolve some otherwise problematic very far distant edge cases. Like science fiction edge... consider interplanetary crypto-currencies with travelers to and from...
mdavid613 has quit [Ping timeout: 250 seconds]
mdavid6131 has joined #bitcoin-wizards
<bsm117532>
I've thought a bit about that...the timescale I'm referencing is fundamentally related to the size of the Earth. Expanding to interplanetary usage would increase the network size, and cohort time. I think you'd want planetary coin networks, and a sidechain-like interconnection between them.
jtimon has joined #bitcoin-wizards
<katu>
NewLiberty: or more realistically - blockchains which can work over sneakernet
<katu>
with enormous latencies
<NewLiberty>
Either way it is a novel solution to problems that we don't really have in practice now.
<bsm117532>
I'm trying to think of a use for a sneakernet coin. Your mining hardware could be totally offline, and occasionally you grab the latest blocks and transmit your own. The network can measure the speed of the sneakernet by the width of the braid...(yeah it's slow, but measurable)
<katu>
yeah, confirm times would be proportionally large too
<katu>
ie matters of days/weeks
<katu>
but hey, its a sneakernet, it basically works offline
<bsm117532>
Yeah, fundamentally, the braid is asynchronous where the blockchain is synchronous. And it really doesn't care about the time scale of that asynchronicity...
Giszmo has quit [Ping timeout: 255 seconds]
laurentmt has quit [Quit: laurentmt]
<katu>
bsm117532: well, i'd definitely focus on that. dont you make some assumptions about partitioning, though?
cdecker has joined #bitcoin-wizards
<bsm117532>
katu: yes, to define recursive cohorts I need a timescale at which to group things into a single cohort, or break them into sub-cohorts. It can be a constant factor times the (measured) network size though.
<katu>
sneakernets have very pronounced latency long trails. you get 80% reachability in a day, but 99% in a month
<katu>
will the lagged "backwater" partitions be able to participate, or would whole network need to lag to include those?
<Taek>
katu: in this sneakernet do you care about that extra 20% being able to be effective miners?
<Taek>
A lot of the assumptions here is that your 90% propagation rate is hitting *miners* and not just normal nodes
Samdney has quit [Ping timeout: 255 seconds]
<Taek>
if your miners are a little tighter than your general nodes, then you can have fast consensus without risk
<bsm117532>
katu: As long as that long tail is a minority, they don't affect everyone else's confirmation times. But their transactions can never take priority over another one appearing faster.
<bsm117532>
Confirmation times are basically defined by time scale at which the sneakernet reaches 50% hashpower.
<bsm117532>
If one adopts my "Equal pay for equal (proof-of-)work" then the tail *can* be effective miners.
<Taek>
until revenue is dominated by transaction fees
<katu>
bsm117532: im more thinking of local partitions operating completely independently, and reconciling with rest of network when they happen to sync. this scenario would most likely be pow/pos mixed system, as the local communities are unlikely to have the hashpower.
<katu>
it can be modelled somewhat as a sidechain already
<bsm117532>
Taek: if revenue is dominated by tx fees, a "tail miner" is still profitable unless he broadcasts the transactions he's mining for other miners to mine before him.
<bsm117532>
If he's doing that, why is he on the (latency) tail?
<Taek>
presumably he's drawing his transactions from the mempool
<Taek>
the other miners are going to have similar mempools
<bsm117532>
Only if they're online ;-)
<Taek>
why wouldn't they be?
<bsm117532>
It's a sneakernet! ;-)
<Taek>
oh
<katu>
miners are incentivized to be well connected of course, but the operating assumption is that real time communication cost is extremely high
<Taek>
but I also mean in a non-sneakernet environment
edvorg has quit [Ping timeout: 265 seconds]
arubi_ has quit [Ping timeout: 244 seconds]
<Taek>
katu: the goal (at least for me) is equitable mining - as long as you meet some minimum requirement for connectivity, your expected revenue per-hash is identical, regardless of connectivity or hashpower
<bsm117532>
Yeah in that case a high latency miner would never win transaction fees.
<katu>
so at one hand, you have to reward well-connectness in proportion to match real world well-connectness cost.
<katu>
Taek: ie fixed point cutoff, either youre in a club or not.
<katu>
im not sure that could work.
<Taek>
I am confident that it can be made to work :)
<Taek>
because I'm writing the propsal right now ha
<bsm117532>
What kind of proposal?
<Taek>
but yes, it's a fixed point cutoff, if you have latency to the global network in less than X seconds, you have equal revenue per-hash
arubi has joined #bitcoin-wizards
<Taek>
and if you are below the cutoff, you basically can't participate at all
<Taek>
*as a miner
<Taek>
you can still participate as a node, you just need to wait for more confirmations
bsm117532- has joined #bitcoin-wizards
<Taek>
I'm working on a proposal for scaling bitcoin
<Taek>
I was hoping to have a sample implementation by the deadline tomorrrow, but that's not going to happen
<Taek>
but maybe I can have a working implementation by Milan
<Taek>
I will have simulation code though that provides security bounds
AndChat-7049 has quit [Ping timeout: 244 seconds]
<instagibbs_>
Taek: for jute?
<Taek>
yes
AndChat-7049 has joined #bitcoin-wizards
bsm117532- has quit [Ping timeout: 265 seconds]
Giszmo has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
<bsm117532>
We should really work together Taek
Newyorkadam has joined #bitcoin-wizards
<bsm117532>
What's the deadline for tomorrow?
<Taek>
Our methodologies are pretty different up to this point
<Taek>
proposal deadline for Milan presentations is 7pm EST tomorrow
<bsm117532>
From the above conversation it seems like we're converging on the same thing. :-D
<Taek>
my goal is to have a system that is fully described by that time
<Taek>
including accounting for transactions fees, difficulty adjustments, etc.
<Taek>
also including security arguments
<Taek>
once we have that, people who have been waiting for a fully described system can join the discussion :)
<bsm117532>
I see I'm not getting any sleep tonight... *sigh*
<instagibbs_>
you don't have to have a fully finished presentation for proposal. You can if you want I guess
<Taek>
My proposal is just going to be a blog post heh
<Taek>
hopefully that's acceptable
NewLiberty has quit [Ping timeout: 250 seconds]
<instagibbs_>
*shrug* I hope so, my proposal was pretty concise
NewLiberty has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
Newyorkadam has joined #bitcoin-wizards
instagibbs_ has quit [Ping timeout: 264 seconds]
assder has quit [Ping timeout: 264 seconds]
vega4 has joined #bitcoin-wizards
AndChat-7049 has quit [Ping timeout: 240 seconds]
vega4 has quit [Client Quit]
Samdney has joined #bitcoin-wizards
vega4 has joined #bitcoin-wizards
rusty2 has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
rusty2 is now known as rusty
chjj has quit [Ping timeout: 265 seconds]
JHistone has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
e4xit_ has joined #bitcoin-wizards
e4xit has quit [Ping timeout: 265 seconds]
e4xit_ is now known as e4xit
e4xit has quit [Remote host closed the connection]
Newyorkadam has quit [Quit: Newyorkadam]
Wazza has quit [Read error: Connection reset by peer]
kurti has quit [Ping timeout: 276 seconds]
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
rusty has left #bitcoin-wizards [#bitcoin-wizards]
chjj has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
kurti has joined #bitcoin-wizards
Newyorkadam has quit [Ping timeout: 244 seconds]
MoALTz has quit [Quit: Leaving]
JHistone has quit [Quit: Leaving]
JHistone has joined #bitcoin-wizards
GAit has quit [Read error: Connection reset by peer]
GAit has joined #bitcoin-wizards
Hunger- has quit [Ping timeout: 260 seconds]
Hunger- has joined #bitcoin-wizards
da2ce7_ has quit [Ping timeout: 260 seconds]
da2ce7 has joined #bitcoin-wizards
JHistone has quit [Quit: Leaving]
RedEmerald has quit [Ping timeout: 244 seconds]
Guyver2 has quit [Remote host closed the connection]
RedEmerald has joined #bitcoin-wizards
e4xit has joined #bitcoin-wizards
r0ach has joined #bitcoin-wizards
priidu has quit [Ping timeout: 276 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
jtimon has quit [Remote host closed the connection]