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
HastaJun has quit [Ping timeout: 260 seconds]
domwoe has joined #bitcoin-wizards
Piper-Off has quit [Ping timeout: 264 seconds]
coup_de_shitlord has quit [Ping timeout: 250 seconds]
Guest14615 has quit [Ping timeout: 264 seconds]
zwischenzug2 has joined #bitcoin-wizards
coup_de_shitlord has joined #bitcoin-wizards
s1w has joined #bitcoin-wizards
[7] has quit [Ping timeout: 258 seconds]
s1w is now known as Guest58370
TheSeven has joined #bitcoin-wizards
Piper-Off has joined #bitcoin-wizards
zwischenzug has quit [Ping timeout: 276 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
Noldorin has joined #bitcoin-wizards
Noldorin has quit [Max SendQ exceeded]
Ylbam has quit [Quit: Connection closed for inactivity]
<bsm117532>
This will be in my upcoming paper "Braiding the Blockchain" which will be submitted to Ledger, but comments welcome here before the paper appears...
moa has joined #bitcoin-wizards
<smooth>
bsm117532: how do you know the bitcoin orphan rate? can't some of them just die without being reported?
* bsm117532
awaits with trepidation a new era of scamcoins using the Lambert W function for blahblahblah...
<bsm117532>
smooth: I got it from blockchain.info
King_Rex has quit [Remote host closed the connection]
<bsm117532>
You think there are orphaned blocks that Blockchain.info never saw?
<smooth>
do you have a sensitivity analysis of your results
<bsm117532>
Not yet, but I might make one for the paper. What are you interested in?
<smooth>
its certainly possible there are blocks they never saw
<smooth>
how important is that you know the true orphan rate, since you don't
<bsm117532>
Well if you're interested in using those numbers in a retarget algorithm, as I showed at the bottom, the sensitivity is easy to calculate from the analytic formulas.
moa has quit [Ping timeout: 276 seconds]
Tiraspol has quit [Remote host closed the connection]
Tiraspol has joined #bitcoin-wizards
<bsm117532>
In a braid there would be no reason to not publish a block -- you'd still get rewards for it. In Bitcoin I can see that orphans might get dumped or not relayed.
<smooth>
oh i didn't click your link, i was just was reading your comments here. Thanks
<bsm117532>
Yeah click the link. Lots of meat in there. :-)
<smooth>
in bitcoin the standard algorithm is to not relay them
Noldorin has joined #bitcoin-wizards
<bsm117532>
But you won't know they're an orphan until several blocks later...how can it choose to not relay?
Chris_Stewart_5 has joined #bitcoin-wizards
<smooth>
only first seen is relayed
<smooth>
now if a later seen block becomes part of a longer chain then both will be relayed by that node, but some fraction of the time that wont happen
<bsm117532>
That doesn't make sense.
<smooth>
If a node receive A then B at the same height, it will only relay A
<bsm117532>
That's a bizarre weirdness right there. What's the justification for that?
p15 has joined #bitcoin-wizards
<smooth>
there is one, but i dont remember it
Noldorin has quit [Read error: Connection reset by peer]
<bsm117532>
If I'm a miner, I want to receive both, so I can choose to mine on the one with the lower hash (I thought)...
<smooth>
there's not particular reason to favor the lower hash, although conventions like that have been proposed
<bsm117532>
The rule you cite explicitly favors miners with better connectivity.
<smooth>
the selfish mining paper said the same, but there is indeed some tradeoff, i just dont remember it
<smooth>
world is full of those annoying things
p15 has left #bitcoin-wizards [#bitcoin-wizards]
<bsm117532>
This braid business explicitly kills the selfish mining attack, by delaying rewards until well after a cohort has formed.
<bsm117532>
The orphan race is a design flaw and is not necessary.
Chris_Stewart_5 has quit [Ping timeout: 244 seconds]
ThomasV has joined #bitcoin-wizards
<smooth>
braids are complicated. design flaw is a bit extreme. it might be necessary if you want a simple algorithm
<bsm117532>
smooth: Yeah they are complicated. But I did all the work for you. :-P
moa has joined #bitcoin-wizards
<bsm117532>
My cohort-finding algorithm is only about 15 lines in python, and that's the meat of it. A retarget algorithm is presented in the formulas at the above link. Again only a couple of lines.
<bsm117532>
Took me 5 or 6 tries to get that algorithm right though...
alpalp has joined #bitcoin-wizards
<smooth>
im pulling for you, i just hope you can get buy-in
<smooth>
there's a lot of inertia and competing interests
<bsm117532>
Heh, thanks. I've gotten what I wanted out of this, at this point. I'll polish up my draft this week and submit it.
alpalp has quit [Ping timeout: 276 seconds]
<smooth>
you'll get a nice paper out of it for sure, but in terms of adoption and improving bitcoin, well...
<bsm117532>
I don't know really where is best to try to put this into production. I've thought about modifying p2pool, or making a sidechain and add it to the Elements project, or convincing the Zcash folks... dunno.
<smooth>
do you think asset creation proportional to difficulty can possibly work?
<smooth>
it seems problematic in having no understanding of what the supply is going to be
<bsm117532>
It's the only thing that works. Anything else rewards early miners at the expense of later miners (who invest more energy) and is a scam.
<bsm117532>
Bitcoin is a direct representation of asset expenditure (hashcash) with added transactional properties.
<smooth>
improving efficiency means later miner invest less energy
<bsm117532>
It's not a perfect representation of asset expenditure, but it's the only cryptographic one I know of. Every other form of "asset" in computers is actually an IOU that through <insert magic> gets tied to real-world assets.
<smooth>
if you said creation proportional to energy...that would be different, but seems unimplementable
<smooth>
actaully satoshi retargeting given non-cartel mining means that asset issuance is equal value to resources consumed
<bsm117532>
The retargeting gives a time-based schedule. It's only an accident if it's proportional to energy expended.
<smooth>
yes but the value of tokens is another independent variable
<smooth>
if mining is even reasonably competitive then value in = value out
<bsm117532>
Anyway...you asked about allocation proportional to difficulty. This is required to decide how to merge competing chains which do not contain double spends.
<smooth>
yeah
<smooth>
unless you can rescale it somehow
<bsm117532>
The row of a database has zero value. PoW has value.
<bsm117532>
Yes, if you chose some schedule for coin allocation, you'd have to recompute everything in order to merge a network split.
<smooth>
i think in your split case you are assuming the tokens on both sides must have the same value
moa has quit [Ping timeout: 258 seconds]
<bsm117532>
Well you have to compare something in order to merge. The one cryptographically representable value that can be decided, in the absence of communication between the chains, is the difficulty itself.
<smooth>
you can compare time
<bsm117532>
Nope. Clocks on one side of the split can't be compared to the other.
<bsm117532>
You'll give me a great timewarp net split attack...
<smooth>
if you are igoring time altogether then maybe but otherwise if you are merging them you are imposing some time reference, if only for retargeting going forwarrd
<bsm117532>
So, the notion of a "cohort" in the above worksheet is a time reference which all participants in the network agree upon. It's where you define the UTXO set.
<bsm117532>
In network protocols we desire to remove time altogether. Assumptions about time find ways of failing, or being gamed.
<smooth>
yes i agree with your statements if time is removed altogether
<bsm117532>
I'd say that's outside my scope of analyzing the graph structure of the braid.
<bsm117532>
I've started talking with zokoo about merging a long-running net split, but that's a different ball of yarn.
<bsm117532>
Though, I'd like net splits to be resolved in exactly the same way as orphans/uncles: quickly, fairly, and robustly.
<bsm117532>
Like a git merge...
<smooth>
that was mostly what i was talking about, and considering your comment on the issue about not having a cutoff between "short" and "long"
pro has quit [Quit: Leaving]
<smooth>
i do think that proportional to difficulty makes a lot of sense but it is odd from the perspective of how we think about bitcoin now, because it isn't clear
<smooth>
what issuance you received until much later
<smooth>
which i guess is what your braids mechanism does (iirc from the earlier writeup i saw)
<bsm117532>
It requires more work. I think rewards proportional to difficulty is a requirement, but I worry about resolving chains of dependent spends, which becomes a double-spend in the merge.
<smooth>
so no one really knows what they own?
<bsm117532>
This line of thought seems to move transaction conflicts to be forks, rather than forks being defined by blocks.
<bsm117532>
smooth: Why do you say that? I would own exactly sum(difficulty) of what I've mined.
<smooth>
so issuance is no longer time-controlled?
<bsm117532>
That you mine 10,000 times more because you have a hydroelectric plant...