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
joesmoe_ has quit [Ping timeout: 248 seconds]
voxelot has quit [Ping timeout: 246 seconds]
laurentmt has quit [Quit: laurentmt]
RoboTeddy has quit [Ping timeout: 250 seconds]
stqism has quit [Ping timeout: 250 seconds]
GreenIsMyPepper has quit [Ping timeout: 250 seconds]
coup_de_shitlord has joined #bitcoin-wizards
Church- has joined #bitcoin-wizards
Dizzle has quit [Quit: Leaving...]
GreenIsMyPepper has joined #bitcoin-wizards
bramc has quit [Ping timeout: 252 seconds]
Cory has quit [Ping timeout: 248 seconds]
belcher has quit [Read error: Connection reset by peer]
binaryatrocity has quit [Ping timeout: 240 seconds]
PaulCapestany has quit [Max SendQ exceeded]
PaulCapestany has joined #bitcoin-wizards
Cory has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
belcher has joined #bitcoin-wizards
joesmoe has joined #bitcoin-wizards
jaekwon has quit [Remote host closed the connection]
jaekwon has joined #bitcoin-wizards
jaekwon has quit [Remote host closed the connection]
moa has quit [Quit: Leaving.]
RoboTeddy has joined #bitcoin-wizards
joesmoe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
joesmoe has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 248 seconds]
Tiraspol has quit [Read error: Connection reset by peer]
Tiraspol has joined #bitcoin-wizards
roconnor has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
dnaleor has joined #bitcoin-wizards
everyBloc has quit [Remote host closed the connection]
everyBloc has joined #bitcoin-wizards
priidu has quit [Ping timeout: 248 seconds]
joesmoe has quit [Ping timeout: 260 seconds]
droark has quit [Quit: Later.]
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #bitcoin-wizards
veleiro has quit [Read error: Connection reset by peer]
veleiro has joined #bitcoin-wizards
jgarzik__ has quit [Quit: Leaving]
RoboTeddy has joined #bitcoin-wizards
joesmoe has joined #bitcoin-wizards
voxelot has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 250 seconds]
wallet42 has joined #bitcoin-wizards
roconnor has quit [*.net *.split]
PaulCapestany has quit [*.net *.split]
bliljerk101 has quit [*.net *.split]
jtimon has quit [*.net *.split]
bildramer has quit [*.net *.split]
c0rw1n has quit [*.net *.split]
slackircbridge has quit [*.net *.split]
amiller has quit [*.net *.split]
Iriez has quit [*.net *.split]
jannes has quit [*.net *.split]
roybadam1 has quit [*.net *.split]
harrow` has quit [*.net *.split]
PsychoticBoy has quit [*.net *.split]
jbenet has quit [*.net *.split]
adams__ has quit [*.net *.split]
CodeShark has quit [*.net *.split]
SheffieldCrypto_ has quit [*.net *.split]
aem has quit [*.net *.split]
Jaamg has quit [*.net *.split]
c0rw1n has joined #bitcoin-wizards
roconnor has joined #bitcoin-wizards
PaulCapestany has joined #bitcoin-wizards
bliljerk101 has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
bildramer has joined #bitcoin-wizards
slackircbridge has joined #bitcoin-wizards
amiller has joined #bitcoin-wizards
Iriez has joined #bitcoin-wizards
roybadam1 has joined #bitcoin-wizards
jannes has joined #bitcoin-wizards
harrow` has joined #bitcoin-wizards
jbenet has joined #bitcoin-wizards
adams__ has joined #bitcoin-wizards
PsychoticBoy has joined #bitcoin-wizards
CodeShark has joined #bitcoin-wizards
SheffieldCrypto_ has joined #bitcoin-wizards
Jaamg has joined #bitcoin-wizards
aem has joined #bitcoin-wizards
PaulCapestany has quit [Max SendQ exceeded]
PaulCapestany has joined #bitcoin-wizards
markus-k_ has joined #bitcoin-wizards
johnwhitton has quit [Quit: johnwhitton]
johnwhitton has joined #bitcoin-wizards
markus-k has quit [Ping timeout: 248 seconds]
johnwhitton has quit [Client Quit]
johnwhitton has joined #bitcoin-wizards
hashtag_ has quit [Ping timeout: 268 seconds]
<bsm1175321>
proslogion: Re: Serenity, one of my big concerns is that they haven't actually solved the problem of sharding the blockchain. Instead they introduced an economic incentive to not-cross-shards, without any technical proposal to organize things in shards. This will cause tremendous breakage as expected gas costs go up because old contracts are (unknowingly) crossing shards.
<bsm1175321>
Economic incentives are fuzzy and malleable and depend on ambient conditions and are not to be depended on, unless you're blocked by a theorem that forces you to consider it as the only way to achieve consensus.
belcher has quit [Quit: Leaving]
<bsm1175321>
Economic conditions arise that cause assets to have a net negative value if you're holding them, which is why shorting exists, but is counter to the notion that technical problems can be solved by coin-quantity-maximizing miners. Technical solutions are always preferred over economic incentives.
johnwhitton has quit [Quit: johnwhitton]
dEBRUYNE has quit [Quit: Leaving]
crossing-styx has quit [Ping timeout: 244 seconds]
<bsm1175321>
I'm not convinced that sharding is a problem that cannot be solved by purely technical means.
<funkenstein_>
wrong channel bro? :)
<bsm1175321>
No. funkmeister. Responding to a comment from earlier today.
johnwhitton has joined #bitcoin-wizards
jl2012 has quit [Quit: Connection closed for inactivity]
wumpus has quit [Read error: Connection reset by peer]
RoboTeddy has joined #bitcoin-wizards
wumpus has joined #bitcoin-wizards
nuke1989 has quit [Remote host closed the connection]
RoboTeddy has quit [Ping timeout: 246 seconds]
e0 has quit [Ping timeout: 248 seconds]
johnwhitton has quit [Quit: johnwhitton]
wallet42 has quit [Quit: Leaving.]
hashtag_ has joined #bitcoin-wizards
wizkid057 has quit [Ping timeout: 248 seconds]
Emcy has quit [Ping timeout: 260 seconds]
Church- has quit [Ping timeout: 240 seconds]
rusty has left #bitcoin-wizards [#bitcoin-wizards]
wizkid057 has joined #bitcoin-wizards
everyBlo_ has joined #bitcoin-wizards
everyBloc has quit [Read error: Connection reset by peer]
<bsm1175321>
Taek: Just did some calculations: the minimum theoretically allowed bead time using a braid is 61ms. With a blockchain it is 200ms. (Both are due to the geometry of the Earth and speed of light). This is *far* too slow to have individually mined transactions. Details to follow...
<bsm1175321>
Or another way to look at it: the braid structure buys more than a factor of 3 in increasing the speed of blockchains.
<funkenstein_>
:o this i want to see
* bsm1175321
whips it out for funkenstein_
<funkenstein_>
lol
Church- has joined #bitcoin-wizards
iLearn has joined #bitcoin-wizards
<bsm1175321>
One can push these average numbers down, at the cost of higher variance in the block/cohort time.
<bsm1175321>
Taek: the problem is that if everyone on the surface of the earth is quickly transmitting transactions, there is no definable "checkpoint" which everyone can agree on a consistent ledger state. Each participant sees local transactions faster. In terms of the propagation time across the network, imagine each node is emitting transactions at 1000 per propagation time. The system would never converge. Cohort size
<bsm1175321>
Here the logical analog of a "block" is "every participant sees the exact same ledger state".
<funkenstein_>
consensus is always probabilistic
<funkenstein_>
i see where you're coming from though, its helpful to have a limit
<bsm1175321>
funkenstein_: no, it's not.
<funkenstein_>
there's a chance of reorg which reduces exponentially with depth
<bsm1175321>
This system has no possibility for reorgs.
<funkenstein_>
all measurement is also probabilistic
mrkent has quit []
mrkent has joined #bitcoin-wizards
<funkenstein_>
no reorgs? if i see one side of a double spend first, somebody else sees the other... one of us has to give
<bsm1175321>
Well, let's put it this way: I'm assuming mining is equally distributed around the globe, and assuming a network which is has the same fairness/performance for all participants, in the above numbers. If you're willing to centralize mining and live close to it, you can get faster. But two mining centers on opposite sides of the globe will always decide on the side with more hashpower.
<bsm1175321>
funkenstein_: reorgs today are caused almost entirely by the non-synchronicity of the network, and miners producing blocks at nearly the same time, not double-spends. My braiding work is intended to address that. Double-spends still revert to most-work-wins.
mrkent has quit [Ping timeout: 248 seconds]
<funkenstein_>
is there an implementation in the works? or other paper than your scalingbitcoin presentation?
<bsm1175321>
Once I figure out all my shit...yes. It's hard to implement things you haven't figured out. ;-)
<bsm1175321>
There is a paper that I've been distracted from finishing. Soon...
<funkenstein_>
interesting stuff, looking forward to it :)
iLearn has quit [Remote host closed the connection]
<bsm1175321>
FWIW, some python code for generating braids, evaluating rewards, and plotting will be published alongside the paper.
<bsm1175321>
The algorithms all rely on graph_tool which is based on the Boost Graph Library, so are straightforwardly importable into Bitcoin.
<funkenstein_>
i see this as being more interesting towards decentralizing other types of database
<bsm1175321>
Possibly.
<bsm1175321>
What's your interest?
iLearn has joined #bitcoin-wizards
<funkenstein_>
something like a repository
<funkenstein_>
git repo
<bsm1175321>
funkenstein_: FWIW the structure deeply relies on the ability to determine that two transactions are not *conflicting*. In the context of Bitcoin this means double-spends (usually) but in the context of Ethereum it also means data dependency. In other words, transactions must commute. Or git commits must be reorderable without conflicts.
<bsm1175321>
Depending on the complexity of your system, just determining that two transactions are reorderable can be extremely complex. I'm seriously worried that my work will be useless for Ethereum due to data dependencies.
<funkenstein_>
right, but i guess your main point here is that sometimes different sets of transactions don't conflict
<bsm1175321>
Exactly. For Bitcoin it's easy: the don't spend the same UTXO's. But for Ethereum, they have to leave the entire state the same if you reorder them. This can be very hard to determine.
<bsm1175321>
Now in Ethereum if you ask for a pairwise commutator it's pretty easy, but now ask for pairwise commutators for all 1000 transactions in a block, and ask whether *any* reordering is possible? This is an exponentially complex problem.
<bsm1175321>
Oddly, in the end, I think I can make Bitcoin faster than Ethereum because of this!
<bsm1175321>
(or a bitcoin-like-coin without the Ethereum state machine)
<funkenstein_>
that's better ;)
mol11111 has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
moli has quit [Ping timeout: 244 seconds]
MoALTz_ has joined #bitcoin-wizards
MoALTz has quit [Ping timeout: 244 seconds]
rusty has joined #bitcoin-wizards
kisspunch has quit [Ping timeout: 276 seconds]
<bsm1175321>
By restricting Bitcoin scripts to be context free (they can't refer to blockchain state), Satoshi avoided this problem (but also delayed payment channels and Lightning by many years).
everyBlo_ has quit [Remote host closed the connection]
iLearn has quit [Remote host closed the connection]
Newyorkadam has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
<Taek>
the network would converge just fine, as long as everyone had enough bandwidth to see transactions as fast as they were appearing
RoboTeddy has quit [Ping timeout: 248 seconds]
<Taek>
meaning, if 1000 transactions are appearing per propagation period, but you can download 1200 per propagation period, you will be eventually convergent
<Taek>
your instant state will always be different from people in a different locality, but as far as anything with multiple propagation periods of confirmations go, you're fine
<bsm1175321>
Define "convergent". In such a scenario, no two particpants ever see the same UTXO state.
ThomasV has joined #bitcoin-wizards
<bsm1175321>
(this is not necessarily incompatible with consensus, mind you -- I just don't see how it works, right now)
<Taek>
it means that after a certain period of time they will be in agreement about whether a specific transaction appears in the full set
<Taek>
they may not have an identical UTXO set at any particular point, but they will have an identical interpretation for a certain output, provided no new transactions for that output have been produced recently
<Taek>
this is completely fine
<bsm1175321>
So in such a scenario, there is no "checkpoint" in which UTXO sets can be compared. So how do I define "in agreement"?
<Taek>
you have an exact ordering for transactions
<bsm1175321>
They would only be in agreement if new tx's stopped for a time period roughly the size of the propagation time across the network.
<bsm1175321>
A braid does *not* have an exact ordering. You and I would disagree on the ordering.
<Taek>
it's the same thing with blocks though, you don't have any guarantee that the whole world has the same utxo set
<bsm1175321>
(based on first-seen)
joesmoe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Taek>
you can't know if someone else has seen a block that hasn't propagated to you yet
<Taek>
but you can know that a given transaction has 6 confirmations
<Taek>
in txn-POW, 6 confirmations would not be enough (because you might be doing 100 or 1000 txn per propagation period). You might want 10,000 confirmations before being certain
<bsm1175321>
Ok so let me take your argument. Let's assume you and I have different UTXO sets because we've seen different sets of transactions, and the tx's happen so rapidly that you and I cannot clearly define a comparison point. How do we know that we have "consensus"?
<Taek>
we have consensus on older transactions
<Taek>
we don't need to be in perfect consensus about new stuff, we treat it as unconfirmed
<bsm1175321>
So "older" defines a comparison point.
<Taek>
more or less
<bsm1175321>
How do you define that comparison point?
<Taek>
so
<Taek>
I don't think there's any need to define an exact comparison point. I don't think there's utility in doing so
<Taek>
but, if you really want one, there's a fairly simple way to do it
<bsm1175321>
I'm using "cohorts" which I've defined a few times, but ask if it's not clear.
<Taek>
For the time being I'm describing the system I designed, which has no sense of cohorts, given a set of transactions that point to eachother you can always arrive at an exact ordering
<bsm1175321>
There is absolutely a need to define an exact comparison point. Or otherwise a different comparison mechanism. (what is it?)
<bsm1175321>
I'm defining "consensus" as "agreement on UTXO set". If you want to define consensus in a different way, that's fine, but what is it?
<Taek>
in Bitcoin, there arrives a point in time where you've achieved certainty that a transaction will not be reorg'd out of the chain
<Taek>
often this is 6 known confirmations, but in some scenarios you may only need 2 or (like during the SPV mining incident) you may want 100+ confirmations
Tiraspol has quit [Ping timeout: 260 seconds]
kisspunch has joined #bitcoin-wizards
<Taek>
not everyone is going to arrive at 6 confirmations at the exact same point in time, because blocks take time to propagate
<bsm1175321>
So, a "confirmation" is a total ordering. DAGs and braids are only partial ordered. A cohort defines a total ordering, and regardless of your assumptions, cohorts will exist, and still define a total order.
<Taek>
the graphs I described had an exact ordering, because they were not based on first-seen, they were based on total amount of work that they point to
<bsm1175321>
In the presence of partial ordering (only) one needs a new notion of "confirmation".
<Taek>
and in the event of a tie, a deterministic random process was used to break the tie
<Taek>
the graphs I described do not have partial ordering, they have exact ordering!
<bsm1175321>
BTW have you read the Iota whitepaper? They use a scoring which does something similar.
<bsm1175321>
Ok, I see.
<bsm1175321>
So what do you do with "siblings" as I define them? -- You use the mined work (not the target work)?
phiche has joined #bitcoin-wizards
<Taek>
the target is defined by what parents you point to, and the amount of 'weight' added to the chain is defined by the target
<bsm1175321>
Argh, here's the problem...as the tx rate increases, you have siblings of siblings of siblings. In order to order them, you have to have a starting point, and a subset you're going to order (a cohort). If the transaction rate is too high, the only starting point is the genesis block. If the tx rate is too high, you will *never* generate a cohort, and never be able to define a subset with a clear start and end p
Tiraspol has joined #bitcoin-wizards
<Taek>
'too high' would need to be higher than the amount of bandwidth available to the miner
<Taek>
but that's the whole reason we have a difficulty in the first place - it's a ratelimit
<Taek>
as long as you pick a sane ratelimit for the speed of transactions, you'll converge
<bsm1175321>
It's not bandwidth, it's causality. If tx's are generated much faster than the propagation time across the network, you will never be able to decide a subset to total order.
<Taek>
that's not correct
<Taek>
so
<Taek>
transactions will always point to a finite number of parents
<bsm1175321>
I agree with your previous statements up to "that's not correct". ;-)
<Taek>
and from those parents you can build a coherent exact ordering
<Taek>
so what happens is you end up with a bunch of different exact orderings from transaction chains that haven't seen eachother
<Taek>
oh
<Taek>
'chaintips' is the word I've been using for it
<Taek>
so you might have any number of chaintips with ~equal work
<bsm1175321>
I'm assuming (per your slides) tx = chaintips.
<Taek>
(or even exactly equal work, depending on how the difficulty is managed)
<bsm1175321>
or tx per block/bead...
<Taek>
a chaintip is a txn for which there is no known child
<bsm1175321>
agreed
Newyorkadam has quit [Quit: Newyorkadam]
<Taek>
so lets assume a system where the throughput is higher than the propagation speed, and therefore you always have ~10 chaintips
<bsm1175321>
So you order possible parents. What happens when you're 18 levels deep in ordering parents? I argue a total order doesn't exist.
<Taek>
and by the time people have seen and merged those 10 chaintips, you have 10 new chaintips
<bsm1175321>
fuck now I have to prove that...
wallet42 has joined #bitcoin-wizards
<Taek>
no, you only pay attention to the longest chaintip you know of
<Taek>
just like in bitcoin
zooko has joined #bitcoin-wizards
<bsm1175321>
So...how do you relate the parents of your parent, to the parents you are choosing?
<Taek>
in Bitcoin, you only pay attention to the longest chain
priidu has joined #bitcoin-wizards
<Taek>
oh
<bsm1175321>
And how do you compare the merging of two sibling chains?
<Taek>
are you asking about how you arrive at an exact ordering?
<bsm1175321>
yes
<Taek>
ok, this is described better in the slides
<Taek>
but
<bsm1175321>
In graph theory it's called "total order"
<Taek>
noted
<bsm1175321>
a > b vs. a >= b.
<bsm1175321>
total vs. partial.
<Taek>
ah
<Taek>
okay, I will use that terminology going forward
CrazyTruthYakDDS has quit [Quit: Connection closed for inactivity]
<Taek>
so, each node has a collection of nodes in the DAG that it points to
<Taek>
I don't know what to call them, so temporarily I'll just say 'P'
<bsm1175321>
parents, sure.
<bsm1175321>
I find the geneaological analogies very useful in this...
<Taek>
I mean that it includes grand parent, great-grand-parents, etc.
<bsm1175321>
ancestors
<Taek>
oh. huh we have I word for that after all
<Taek>
lol
<Taek>
ok
<bsm1175321>
;-)
<moa>
forbears
<bsm1175321>
ancestors/descendants for all generations, parents/children for one generation. It's a useful analogy ;-)
<Taek>
so, if you are pointing to multiple parents, there is a rule that none of the parents can be ancestors to eachother
<Taek>
A <- B <- C ===> C is not allowed to point to both B and A, because B already includes A
<bsm1175321>
Yeah. I tried to convince the Iota people of that without success. If you're using scoring of some kind, that rule *may* not be useful... but then I have to examine your scoring.
<bsm1175321>
Anyway, agreed and understood.
<Taek>
so, you score things by counting the total amount of work in a node's ancestors (including the node itself)
<Taek>
then, when picking an ordering, you prefer the ancestor that has more total work
<Taek>
in the event of an exact tie, you use your own id (the POW hash) to randomly select a winner
<bsm1175321>
Ok so the first conflict there is siblings, which are by definition an exact tie.
<bsm1175321>
They're a depth-1 tie.
<bsm1175321>
Ok, you can use the PoW hash like that...
<bsm1175321>
Though I mentioned something similar in this channel a long time ago, and there was frothing at the mouth...I don't remember why...
phiche has quit [Read error: Connection reset by peer]
<bsm1175321>
IOW do you use the target difficulty, or the actual hash value to decide total collective work?
<Taek>
A <- B | A <- C | B <- D | C <- D ===> A has value 1, B & C have value 2, D has value 4. D randomly selects between B and C for which comes first, then you end up with a total ordering that is deterministically either A < B < C < D or A < C < B < D
<Taek>
(but it's deterministic)
<Taek>
ok, now we will add the final rule, which is the tricky part but I think what will sove your N-tie problem
<bsm1175321>
In order to get (statistically) deterministic orderings, you need to use the hash value instead of the target difficulty. (which is the idea that caused frothing at the mouth...memory...jogging...)
<Taek>
let's add 2 new nodes: A <- E | E <- F | D <- F
<Taek>
(you need to use the target difficulty otherwise you open yourself to various forms of intelligent withholding attacks. Someone who unintentionally gets a very lucky number can withhold it and cause a huge reorg)
<Taek>
F is conirming 2 chaintips, E & D
<bsm1175321>
Using the target difficulty means that siblings (diamond graphs) are undecidable for a total ordering.
<Taek>
A is a common ancestor in both, so it comes before anything that follows
<Taek>
(no you use the hash as a random variable that selects an ordering - it's not the same as favoring the hash value. The random number that's generated is separate, and therefore can't be abused)
<Taek>
Then D has more work, so all ancestors to D are next
<Taek>
then E, and finally F
<bsm1175321>
Any hash value can be abused by grinding.
<Taek>
the total ordering is therefore A < B < C < D < E < F
<bsm1175321>
So let me distill everything you're saying...
<Taek>
bsm1175321: that is true, except in this case you'd need to do enough grinding to find the target at least one more time, which takes the same amount of working as just adding another confirmation, which would achieve the same thing
priidu has quit [Ping timeout: 248 seconds]
<bsm1175321>
You're arguing there's a way to define a total ordering on a DAG/braid, in a way that can't be gamed. No?
<Taek>
yes, I'm arguing that
<bsm1175321>
Ok.
funkenstein_ has quit [Quit: Leaving]
<Taek>
if you take a 4 node diamond, a bc d, you can use min(H(d || b), H(d || c)) to pick an exact ordering in a way that can't be gamed
<bsm1175321>
So, I think one can still reorder beads within a cohort.
<Taek>
gaming would require finding an alternate value for 'd', which would require completely redoing the POW
<bsm1175321>
So a cohort is an absolute, irrefutable total ordering on a DAG.
<bsm1175321>
Everything you're saying is *within* a cohort.
<Taek>
(is the HK presentation the most recent public version of your work?)
<bsm1175321>
So your argument is then that one can't gain an advantage by reordering within a cohort.
<Taek>
well, I'm aruging that reording within a cohort would take at least as much work as just adding more nodes
<bsm1175321>
which I think means that a vendor/adversary should wait until the end of the cohort, and no possible DAG reordering is possible, no?
<bsm1175321>
yes sadly I haven't published anything since HK, been busy. :-/
<Taek>
can you redefine cohort?
<Taek>
I'm not 100% clear on the definition
<bsm1175321>
It's pretty easy to add DAG nodes by withholding beads.
<Taek>
right, but I don't think there's any advantage you gain by withholding beads
<bsm1175321>
\item[cohort] The union of $b$ with all its siblings and its siblings
<bsm1175321>
siblings, recursively; the largest set of beads such that no bead in the
<bsm1175321>
set is an ancestor or descendant of every other bead in the set.
<Taek>
*in my design, where each transaction is a bead with an acceptable POW
<bsm1175321>
where $b$ is any bead (or txn in your case)
<Taek>
ok, so in my system, you might actually have infinite sized cohorts
<bsm1175321>
And, I worry, an inability to define a total ordering.
<bsm1175321>
If you use target difficulty as total ordering, it's definitely true, at high enough txn rate, you will always have siblings at equal depth/difficulty/block height, and cannot perform a total order.
<bsm1175321>
Taek: which, I realized an hour or so ago, means there is a maximum bead rate, and you can use this to define a target difficulty in such a way as to maximize the (bead) throughput of the network.
<bsm1175321>
But, I would love to hear an idea about consensus in the absence of cohorts!
jaekwon has joined #bitcoin-wizards
<Taek>
there is a maximum bead rate in my system too, though I think that it's approximately the bandwidth of whatever node is listening. If your bandwidth is below that, you can't be sure you've got the longest chain because you can't see everything that's being built
<Taek>
but, it should be independent of latency. Higher latency means you need more confirmations before being certain that something is confirmed
iLearn has joined #bitcoin-wizards
<Taek>
the key in my system is that you can take any set of nodes and built a total ordering
<bsm1175321>
Don't forget about the geometry of the Earth.
<Taek>
*build
<bsm1175321>
That defines being able to "see everything".
<Taek>
well, you need to have all the ancestors of every bead you are considering
<bsm1175321>
And really I'm using "geometry of Earth" as a poor man's proxy for "topology of the network"
<Taek>
but your universe does not need to match anyone else's universe, and indeed the assumption is that it does not
<Taek>
the assumption is only that at some point you will see every node that they currently see
<Taek>
and you may have new nodes that they don't see at that point, but that's okay
<Taek>
things with enough confirmations (several propagation periods of confirmations) can be safely assumed to be in every set
jaekwon has quit [Ping timeout: 240 seconds]
<Taek>
Just like in Bitcoin
<Taek>
hmm. I think I haven't broken it down all the way, but I'm not sure how to break it down further
<Taek>
I think of it like a zipper
<Taek>
*an infinite zipper
<Taek>
there are prongs in front of you that aren't confirmed yet, there's the zipper of consensus, and there's a weave of prongs behind the zipper that have confirmations
<Taek>
there's always stuff that's not fully woven, but there's also definitely stuff behind the zipper that would take great effort to unweave
<bsm1175321>
So what I realized today: increasing difficulty (obviously) increases the cohort time, and your graph approximates a blockchain. But also *decreasing* cohort time also *increases* the cohort time because of the siblings-of-siblings effect.
<Taek>
I haven't written proof for it, and I'm only 90% sure it's true, but I believe that in my graph, in order to reorg a total ordering that has 10 confirmations, you would need to merge a chaintip that's got at least 10 nodes in it
<Taek>
*10 new nodes
<bsm1175321>
eh. English. But also *decreasing* cohort /difficulty/ also *increases* the cohort time because of the siblings-of-siblings effect.
RoboTeddy has joined #bitcoin-wizards
<bsm1175321>
In other words, there's a local minima. ;-) And, a maximum network speed, that fundamentally comes from the network topology.
ThomasV has quit [Ping timeout: 244 seconds]
<Taek>
if you need finite cohors, which in my design is not required
<bsm1175321>
(given my definitions of total ordering in terms of cohorts)
<bsm1175321>
Agreed.
everyBloc has joined #bitcoin-wizards
everyBloc has quit [Remote host closed the connection]
<Taek>
in my design, if you've got on average unmerged chaintips of depth 10, then 10 confirmations would be equivalent to 1 propagation period of confirmatoins. You'd want to wait several, but a node with 50 or 500 confirmations is unlikely to be reorg'd away because in 1 propagation period a single chaintip only ever gets ahead by about 10
<bsm1175321>
So, let's assume a miner both mines and grinds to get his txn reordered with respect to your decided total ordering.
<Taek>
ok
<bsm1175321>
We have to dump the notion of "confirmations" absent a total ordering.
CrazyTruthYakDDS has joined #bitcoin-wizards
<Taek>
but we do have a total ordering
<bsm1175321>
Yes.
iLearn has quit []
<bsm1175321>
So everyone is using the same target, no?
<Taek>
so, I'm going to simplify things a lot, we're going to assume that all txns have the same target
<bsm1175321>
Let's say I make two txn's which are double-spends, with the same parent(s).
<bsm1175321>
Ok good.
<bsm1175321>
Now, I release the first one to be successfully mined, and continue to mine the second one until it satisfies your second condition which would total order it before the first.
RoboTeddy has quit [Ping timeout: 244 seconds]
<Taek>
ok. So you first release A <- B, then you grind on 'C' until you get a result A < C < B
<bsm1175321>
Yes.
<Taek>
so, minimally, you need to do 1 work to achieve that. After 1 work, you have 50% chance of success. After 2 works, 66% chance of success, 3:75%, ect
<bsm1175321>
But you don't have cohorts. So there's no limit as to how long I can grind the second txn to achieve a favorable result.
<Taek>
oh, not fully accurate
everyBloc has joined #bitcoin-wizards
<Taek>
my probabilities are too low, but it's late and I don't want to derive the exact values
<bsm1175321>
mmm ignoring %, I get your point
<Taek>
right, so I'm going to assume that you've got less than 50% hashrate
<bsm1175321>
Yes.
<Taek>
After you release A <- B, everyone else is mining on top of B
<bsm1175321>
That's fine though, since A<C and time is not measured.
<Taek>
well, by the time you find 'C', there likely already exists another node
<bsm1175321>
Certainly. Now you've inserted time measurement into the system...which is something Bitcoin doesn't do...
<Taek>
so now you've got two chaintips, one that's A < B < D and one that's A < C < B
<bsm1175321>
Damn laggy networks.
<Taek>
there's no sense of time here that Bitcoin doesn't have
<Taek>
Bitcoin nodes will prefer the chain they see first in the event of 2 competing chains at the same depth
<Taek>
we do the same
<bsm1175321>
That's not true. Bitcoin prefers the chain with more work, using the hash value.
* Taek
requests backup.
<Taek>
:p
* bsm1175321
googles
<Taek>
bitcoin nodes prefer the chain they see first, I'm 98% confident about this
<bsm1175321>
As a -wizards conversation, I'm malleable on this point in any case.
<Taek>
ok
<gwillen>
Bitcoin prefers the chain it sees first, given the same work, but it always prefers more work
<gwillen>
so I think you're both correct because by 'depth' Taek probably meant 'work'
<gwillen>
(in non-pathological cases they'll be the same since every block mined at the same depth should have the same work)
<bsm1175321>
gwillen: "same work" is a statistical impossibility unless we're talking about the actual hash value.
<gwillen>
same target
<gwillen>
a hash further below the target doesn't count more
<gwillen>
but blocks count for work based on their target
voxelot has quit [Ping timeout: 268 seconds]
<gwillen>
which is what prevents someone mining a parallel chain starting at genesis with only 1 work in each block, to the same depth as the real chain, and winning
<gwillen>
but as long as someone doesn't mine a fork long enough to cause a retarget down to a lower difficulty... 'depth' and 'work' are the same because legitimate blocks at the same depth are going to have the same target
<bsm1175321>
Taek: So I'm with gwillen on this, if you use the actual hash value, or some other grindable value, a total order is grindable (decidable) by the transaction writer.
<gwillen>
I'm trying to make sure I understand what 'total order' is being used to mean here before I comment
<bsm1175321>
gwillen: so it's only between retargets that actual hash value is taken into account?
<Taek>
to satisfy the POW, the hash value has to be below some target, grinding on the hash value is as expensive as just adding more nodes
<gwillen>
but I do agree with what you're saying, bsm1175321, if 'total order' means what you're interpreting it to mean
<gwillen>
or what I think you are :-)
<bsm1175321>
gwillen: "total" order is implicit in bitcoin/any blockchain... it's the block height.
<gwillen>
bsm1175321: the actual hash value is never taken into account -- retargets change the target hash value based on the average time to find a block using a preset formula, and work that counts for the chain is always based on the target hash value (the difficulty value)
wallet42 has quit [Quit: Leaving.]
<gwillen>
any 'extra' amount that the actual hash is below the target hash is "wasted"
<bsm1175321>
Taek: so per gwillen's response, your algorithm has many equal-ordered siblings, unless you wish to insert another tie-breaker, which can be ground, possibly.
<bsm1175321>
(and I agree, it's easy to make this cost as much as the original mined block)
<Taek>
you can already reorg txns by doing work
<Taek>
but yes, if you have enough work, you can reorg txns
<bsm1175321>
gwillen: mining is really first-seen? So it's easy to attack a mining pool by delaying their network?
<Taek>
I forget what point I was trying to make, what direction are we going?
<gwillen>
hmm, I feel like at one point I was convinced that a grindable tie-breaker was a bad idea for obvious reasons that are worse than just "you can reorg by doing work", but I can't come up with them right now
<gwillen>
bsm1175321: if you delay a mining pool's network, they will lose money, yeah
<bsm1175321>
Taek: hahaaa we were talking whether total ordering with your scheme was doable.
<gwillen>
it will increase their orphan rate, which is the rate at which their successful blocks are ignored by the network because someone else got there first
<Taek>
oh, I think we have had a slightly different definition of total ordering
ThomasV has joined #bitcoin-wizards
<bsm1175321>
You can easily achieve total ordering by network synchronicity (a la Bitcoin) or cohorts in braids. I'm yet to be convinced of another idea. ;-)
<Taek>
(one of the big advantages to the txn-POW scheme I've described is that miners on slower networks have a much smaller disadvantage. They are still disadvantaged, but the effect is probably an order of magnitude less)
DougieBot5000 has quit [Quit: Leaving]
<bsm1175321>
Heh. I want to dis-incentivize the slow bastards off the network. I have no interest in a slow network.
<Taek>
bsm1175321: my graph scheme can achieve a total ordering from any set of nodes that you give it, and the ordering can only be changed by doing work. The amount of work required to change the ordering is minimally equal to the amount of work on top of whatever txn you are trying ot reorder
<bsm1175321>
gwillen: the definition I'm using has no orphans, because rewards are decided later.
<Taek>
bsm1175321: requiring a fast network connection is a centralization pressure
<bsm1175321>
Taek: I have no doubt that a total ordering can be achieved in the way you describe. I doubt that it can't be gamed.
wallet42 has joined #bitcoin-wizards
<bsm1175321>
Taek: requiring a fast network is an anti-chinese-communisim-censorship measure.
<bsm1175321>
I see no reason to enable censorship, or slow networks, in my financial system.
Giszmo has quit [Quit: Leaving.]
<Taek>
uh
<bsm1175321>
Anyhoo...convince me you can achieve a total ordering...
<Taek>
I don't want to get into that now, maybe someone else can take that one later. Let it be known publically though that I actively think that decentralized mining requires slow connections to be nearly as equally profitable as fast connections.
<Taek>
bsm1175321: you are asking me to convince you that I have achieved a total ordering which can't be gamed
<Taek>
so I will provide a definition of 'gamed'
<bsm1175321>
The system is as fast as its slowest connection. I desire fast finance...
<Taek>
and I desire decentralized finance :)
<Taek>
there's a direct tradeoff there
<bsm1175321>
Decentralization behind the great firewall is not decentralization.
<Taek>
someone has to decide the speed limit of the network
<Taek>
and that speed limit decides who can participate
<Taek>
urg back to total ordering
<bsm1175321>
Yeah. More interesting.
<Taek>
ok, so my assertion is that a txn with X confirmations (where every decendent counts as a confirmation) cannot be reordered unless a chaintip is merged with at least X previously unmerged txns
<bsm1175321>
Taek: FWIW the 'total order' I define is due to causality...it's impossible for someone on one side of the Earth to know the block/bead a person on the other side of the Earth is constructing.
<bsm1175321>
Bitcoin's "total order" is due to synchronicity: everyone must have seen everything.
<bsm1175321>
Taek: Ok so I create a txn with a parent before your txn and release it after your txn has been "confirmed", what happens?
<Taek>
Bitcoin can have 2 nodes that have seen everything yet have different total orders: the case where the two most recent blocks are buidling of a common parent, and some set of nodes saw 1 block first and the other set of nodes saw the other block first
<Taek>
those nodes will remain inconsistent about which block is the 'real' block until one of the blocks gets more confirmations
<Taek>
bsm1175321: I'm not 100% sure what graph setup you are describing?
<bsm1175321>
Taek: "confirmations" is a total-ordering concept. Can you redefine it in a partial-ordered world? What happens when two txns have the same number of confirmations?
jtimon has quit [Ping timeout: 240 seconds]
<Taek>
you mean two conflicting txns?
<bsm1175321>
no.
<bsm1175321>
mmmm maybe.
<bsm1175321>
Ok, yes.
<bsm1175321>
I've totally just discredited myself.
<Taek>
lol
<Taek>
so, if we're requiring a large number of confirmations, two conflicting transactions are unlikely to each get to that large number of confirmations because their respective chaintips will be diverging
<Taek>
one will get ahead of the other, and that chaintip will win the race
<bsm1175321>
Ok, define confirmations?
<Taek>
every descendant is a confirmation. So in the (a bc d) diamond, 'a' has 4 confirmations (abcd)
<Taek>
b and c each have 2 confirmations, and d has 1 confirmation
<bsm1175321>
The diamond, by assumption, has no conflicts.
<Taek>
right
<bsm1175321>
Here we're talking about double-spends, no?
<Taek>
ok
<Taek>
so in the case of (a bc) 'a' actually only has 2 confirmations
<Taek>
itself and one of 'b' or 'c', because 'b' and 'c' have not been merged
<Taek>
and therefore the node will only be considering one of the worldviews (a b) or (a c)
<bsm1175321>
So double spends define a fork. The UTXO set at the point of that fork is the (sub)set of parents of that txn. It doesn't have to be a full cohort...
<Taek>
digesting
<bsm1175321>
So at that point, "confirmations" on the two forks generally will disagree.
<Taek>
yeah I think that's right
<Taek>
but a node doesn't see the world in terms of forks
<bsm1175321>
There exists a point, that is a parent of both double-spends.
<Taek>
forks describe when two nodes have different worldviews
<bsm1175321>
Mmmm yes it does. A node has to decide which to mine on top of.
<Taek>
hmm I guess that's not true
<Taek>
damn I hate the work fork
<Taek>
lol
<Taek>
it's overloaded
<bsm1175321>
hahaahaa
<bsm1175321>
Yeah, go fork yourself. ;-)
<Taek>
ok, so a node sees multiple potential chaintips, each with the same work, and some of which might be incompatible, and it's trying to figure out which chaintip to mine on
<bsm1175321>
Title of a recent blog post with 0 readers...
<bsm1175321>
Exactly. AFAIK in the event of such a tie, it *does* use the hash value.
rusty has quit [Ping timeout: 264 seconds]
<Taek>
gwillen: node will prefer the chaintip it saw first, correct?
<Taek>
assuming same height + total work?
melvster has quit [Ping timeout: 244 seconds]
<bsm1175321>
checking...
<Taek>
regardless, as soon as one of the chaintips has more work, the node will switch to that chaintip
<bsm1175321>
Yes.
<bsm1175321>
In this respect, my description of braids is identical to bitcoin.
<Taek>
ok. So you are worried about the world where there are consistently several conflicting chaintips
<Taek>
unmergeable
<bsm1175321>
correct
<Taek>
as a brief aside
<bsm1175321>
And that happens at high txn rate.
<Taek>
because you have total ordering for any given universe of nodes, you can actually allow illegal nodes to be merged
<Taek>
if two nodes are in conflict, the one that is earlier in the total ordering is the one that is accepted
<Taek>
but that's less interesting because it breaks SPV
<bsm1175321>
I chose the word "bead" over "node" because I can't tell whether you're talking about Bitcoin AWS instances...
<Taek>
ah yeah
<Taek>
ok bead
<bsm1175321>
How can illegal beads be merged?
<Taek>
you add them as parents.
<bsm1175321>
Well...in your scheme a late-appearing bead could cause a reorg, no?
<Taek>
N late-appearing beads can cause a reorg as deep as N beads
<bsm1175321>
Well conflicting parents define different braids...
<bsm1175321>
And yes, braids can be reorged.
<Taek>
I'm debating whether to keep talking about the case where illegal beads can be merged, or switch back to the situation where illegal beads cannot be merged
<Taek>
if you allow illegal beads to be merged, it makes txn fees harder to reason about, becaues the illegal txn is going to have illegal inputs, which means the fee value changes
<bsm1175321>
I have an idea. Let me put out my paper and code as quickly as possible, and we can discuss algorithms and trade python code instead. ;-)
<Taek>
but if you don't allow illegal beads to be merged, you know the fee value of a txn immediately
<Taek>
ok. I plan on coding this up
<Taek>
well... that might not be ready until late summer though
<bsm1175321>
Sorry, very tired and losing coherence, but thanks for an interesting chat, and let's keep talking about this.
<Taek>
I'd like the idea to get more traction/confirmation from other researchers as something that's worth pursuing before I dump too much time into it
<bsm1175321>
If we're lucky, I'll have my paper/code out in a ~week.
<Taek>
so... June :P
<bsm1175321>
I'd be happy to comment, but define "worth pursuing" in your terms. ;-)
<bsm1175321>
June, yes, june.
<Taek>
"worth pursuing": people are convinced that the fundamentals of the idea could turn into something that would significantly improve *both* txn throughput and miner decentralization
<Taek>
even if they are not convinced that the current specification is complete (which it isn't)
<bsm1175321>
I'm convinced on both points, and will hopefully convince others with a paper and code. Let's keep talking. ;-)
melvster has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
<bsm1175321>
However as of tonight you convinced me that per-txn mining is not doable. :-/
<bsm1175321>
(with my definition of cohorts)
<bsm1175321>
... as analogous to blocks.
<bsm1175321>
I'm open to another interpretation.
<Taek>
and the reason you think it's not doable is because you believe that it would be too easy to cause reorgs
<Taek>
or beacuse you think that the network would be unable to converge on whether or not a transaction was confirmed?
<Taek>
I am currently convinced that neither would be a problem, but am not sure what approach to use to convince other people of this. Perhaps some sleep will help
RoboTeddy has quit [Ping timeout: 240 seconds]
<bsm1175321>
Taek: two reasons: two participants cannot compare UTXO sets, because there is never a common agreement point. Second, any method of imposing a total ordering on a partial ordered cohort/DAG can be gamed, because the block generation rate is much faster than the cohort/checkpoint/comparison size, so reordering is possible within the cohort.
<bsm1175321>
You're correct about your statement of "twice as much work" but with respect to what?
<bsm1175321>
If, within a cohort/checkpoint, 2x work is less than the total work, I can cause a reorg.
<Taek>
a reorg up to 2 deep
<Taek>
same is true with Bitcoin
<bsm1175321>
Yes.
<Taek>
so I don't see why it's a problem?
<bsm1175321>
If you slow everything down to the point that you total-order because the difficulty is so high that the propagation time is much less than the target time, you have a blockchain.
<bsm1175321>
The interesting point is when the target time is similar to or less than the propagation time across the network.
<Taek>
yeah. the whole idea here is that you'd have 10+ different transactions in flight at the same time
<Taek>
*non-conflicting transactions
<Taek>
in the ideal situation, we've brought the orphan rate close to zero
<bsm1175321>
All this is *defined* by who-sees-who-first. I'm defining a system in which I see *everyone* first and that defines a checkpoint/block
<bsm1175321>
But as the tx rate goes up, that's not possible.
<Taek>
if there's a large backlog of transactions, miners can safely mine different transactions, and a conflict will be rare. Far less than 0.5% of all mining will be wasted to conflicts
<Taek>
if there is not a large backlog of transactions, I'm not sure all the same properties hold
<bsm1175321>
So most reorgs today are due to the coinbase, not double-spends.
<bsm1175321>
We could totally eliminate that conflict by allocating the coinbase txn 100 blocks later, rather than having the miners write it themselves.
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
Logicwax has quit [Ping timeout: 240 seconds]
Logicwax has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
Alopex has quit [Remote host closed the connection]
<jonasschnelli>
maaku: UTXO-set dumps: yes. There might be some usecases, though, I understand the differencences in the (no)trust-model.
everyBloc has quit [Read error: Connection reset by peer]
everyBloc has joined #bitcoin-wizards
Alopex has joined #bitcoin-wizards
Don_John has quit [Read error: Connection reset by peer]
everyBloc has quit [Remote host closed the connection]
ThomasV has quit [Ping timeout: 244 seconds]
everyBloc has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 244 seconds]
CrazyTruthYakDDS has quit [Quit: Connection closed for inactivity]
everyBloc has quit [Remote host closed the connection]
Ylbam has joined #bitcoin-wizards
RedEmerald has quit [Ping timeout: 246 seconds]
adlai has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
CrazyTruthYakDDS has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Krellan has quit [Read error: Connection reset by peer]
Krellan has joined #bitcoin-wizards
zooko has quit [Ping timeout: 240 seconds]
mountaingoat has quit [Ping timeout: 268 seconds]
mountaingoat has joined #bitcoin-wizards
_rht has joined #bitcoin-wizards
ntivirus has joined #bitcoin-wizards
roconnor has quit [Ping timeout: 240 seconds]
RoboTeddy has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 240 seconds]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
everyBloc has joined #bitcoin-wizards
RedEmerald has joined #bitcoin-wizards
everyBloc has quit [Ping timeout: 260 seconds]
mrkent has quit []
MoALTz_ is now known as MoALTz
ndog_ has joined #bitcoin-wizards
<ndog_>
Is it possible to run a fork inside of a vpn restricted from internet?
<ndog_>
with custom seed servers
dEBRUYNE has joined #bitcoin-wizards
ndog_ has quit [Quit: Page closed]
wallet42 has joined #bitcoin-wizards
dEBRUYNE has quit [Read error: Connection reset by peer]
melvster has quit [Read error: Connection reset by peer]
dEBRUYNE has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
joesmoe has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 248 seconds]
ntivirus has quit []
sn0wmonster has left #bitcoin-wizards ["Leaving"]
proslogion has joined #bitcoin-wizards
CrazyTruthYakDDS has quit [Quit: Connection closed for inactivity]
jl2012 has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
everyBloc has joined #bitcoin-wizards
everyBloc has quit [Ping timeout: 244 seconds]
sneak has quit [Ping timeout: 268 seconds]
sneak has joined #bitcoin-wizards
sneak has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
andytoshi has quit [Ping timeout: 244 seconds]
phiche has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 240 seconds]
moa has quit [Quit: Leaving.]
dnaleor has quit [Quit: Leaving]
dnaleor has joined #bitcoin-wizards
phiche has quit [Ping timeout: 252 seconds]
phiche has joined #bitcoin-wizards
<wumpus>
yes, you could, there's no reason the code needs connection to the 'real' internet. Though for such an experiment it may make more sense to disable using the seed servers, and use addnode yourself.
teslax has quit [Ping timeout: 244 seconds]
AaronvanW has quit [Read error: Connection reset by peer]
everyBloc has joined #bitcoin-wizards
everyBloc has quit [Read error: Connection reset by peer]
everyBloc has joined #bitcoin-wizards
dEBRUYNE has quit [Quit: Leaving]
everyBloc has quit [Ping timeout: 240 seconds]
supasonic has quit [Ping timeout: 260 seconds]
crossing-styx has joined #bitcoin-wizards
testnet has joined #bitcoin-wizards
<testnet>
hello all can anyone help me with an issue I have mining using testnet
RoboTeddy has joined #bitcoin-wizards
phiche1 has joined #bitcoin-wizards
<wumpus>
testnet: wrong channel
phiche has quit [Ping timeout: 246 seconds]
<wumpus>
try #bitcoin
<testnet>
ok thanks
RoboTeddy has quit [Ping timeout: 276 seconds]
Burrito has joined #bitcoin-wizards
andytoshi has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 252 seconds]
jtimon has joined #bitcoin-wizards
everyBloc has joined #bitcoin-wizards
everyBlo_ has joined #bitcoin-wizards
everyBloc has quit [Read error: Connection reset by peer]
c-cex-yuriy has joined #bitcoin-wizards
everyBlo_ has quit [Ping timeout: 252 seconds]
crossing-styx has quit [Ping timeout: 246 seconds]
wallet42 has quit [Quit: Leaving.]
stevenroose_ has quit [Quit: ZNC 1.6.2 - http://znc.in]
stevenroose_ has joined #bitcoin-wizards
stevenroose_ has quit [Remote host closed the connection]
stevenroose_ has joined #bitcoin-wizards
stevenroose_ has quit [Client Quit]
stevenroose_ has joined #bitcoin-wizards
voxelot has joined #bitcoin-wizards
eudoxia has joined #bitcoin-wizards
<kanzure>
what was the result regarding prime numbers and the frequency of their first digits when looking at base 3? where did that paper go?
<proslogion>
christ there's such a thing?
stevenroose_ has quit [Quit: ZNC 1.6.2 - http://znc.in]
everyBloc has quit [Read error: Connection reset by peer]
_rht has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
veleiro has quit [Quit: Leaving.]
keus has quit [Ping timeout: 264 seconds]
voxelot has joined #bitcoin-wizards
voxelot has quit [Changing host]
voxelot has joined #bitcoin-wizards
keus has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 240 seconds]
Giszmo has joined #bitcoin-wizards
adlai has quit [Ping timeout: 244 seconds]
DougieBot5000 has joined #bitcoin-wizards
Aleph0 has quit [Ping timeout: 276 seconds]
Aleph0 has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
phiche1 has quit [Quit: Leaving.]
Guyver2 has quit [Ping timeout: 260 seconds]
Guyver2_ is now known as Guyver2
jps has joined #bitcoin-wizards
BitcoinErrorLog has joined #bitcoin-wizards
phiche has joined #bitcoin-wizards
phiche1 has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
phiche has quit [Ping timeout: 250 seconds]
<bramc>
Going back to the scroll from about a half day ago: Immediately after a work difficulty reset the harder chain will beat the easier chain. This gives an advantage to whoever makes their chain marginally harder to mine because it will tend to win tiebreaks, just so long as the marginal increase in difficulty they make is less than the orphan rate
<bramc>
If you can do a hard fork, a prudent thing to do would be to make the work difficulty reset not kick in until some number of blocks after it's measured.
markus-k_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
melvster has quit [Remote host closed the connection]
Guyver2 has quit [Ping timeout: 260 seconds]
melvster has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
mol11111 is now known as moli
dEBRUYNE has joined #bitcoin-wizards
supasonic has joined #bitcoin-wizards
jaekwon has joined #bitcoin-wizards
jaekwon has quit [Remote host closed the connection]
everyBloc has joined #bitcoin-wizards
everyBlo_ has quit [Read error: Connection reset by peer]
aknix has joined #bitcoin-wizards
grandmaster has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
RoboTeddy has quit [Ping timeout: 252 seconds]
ThomasV has quit [Ping timeout: 244 seconds]
hybridsole has quit []
huseby has joined #bitcoin-wizards
phiche1 has quit [Quit: Leaving.]
everyBloc has quit []
btcdrak has quit [Excess Flood]
btcdrak has joined #bitcoin-wizards
everyBloc has joined #bitcoin-wizards
<Taek>
bramc: or you could set up some threshold. e.g., you won't switch to a heavier chain unless it's at least X work heavier, where X is nontrivial (say, 3 minutes of network hashrate)
wallet42 has joined #bitcoin-wizards
catcow has quit [Excess Flood]
MrHodl has joined #bitcoin-wizards
catcow has joined #bitcoin-wizards
droark has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
droark has quit [Client Quit]
droark has joined #bitcoin-wizards
<maaku>
MoALTz people don't look where they don't expect to find anything