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
Erik_dc has quit [Remote host closed the connection]
rdponticelli has joined #bitcoin-wizards
rdponticelli has quit [Client Quit]
pozitrono has quit [Ping timeout: 245 seconds]
oldbrew has left #bitcoin-wizards [#bitcoin-wizards]
dstadulis has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
<instagibbs>
I think the soft-fork strat is to stick it outside the regular block?
<instagibbs>
You may find out soon.
dstadulis has quit [Quit: ZZZzzz…]
nanasho has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 260 seconds]
lamza has joined #bitcoin-wizards
mrkent has quit []
sdaftuar has quit [Ping timeout: 260 seconds]
morcos has quit [Ping timeout: 245 seconds]
zxzzt has quit [Ping timeout: 260 seconds]
sdaftuar has joined #bitcoin-wizards
morcos has joined #bitcoin-wizards
zxzzt has joined #bitcoin-wizards
dstadulis has joined #bitcoin-wizards
Yoghur114_2 has quit [Remote host closed the connection]
dstadulis has quit [Client Quit]
dstadulis has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
lamza has quit [Ping timeout: 252 seconds]
zxzzt has quit [Ping timeout: 245 seconds]
morcos has quit [Ping timeout: 246 seconds]
sdaftuar has quit [Ping timeout: 245 seconds]
nanasho has quit [Ping timeout: 246 seconds]
zxzzt has joined #bitcoin-wizards
sdaftuar has joined #bitcoin-wizards
nanasho has joined #bitcoin-wizards
morcos has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
Casper- has quit [Ping timeout: 260 seconds]
zxzzt has quit [Ping timeout: 260 seconds]
sdaftuar has quit [Ping timeout: 245 seconds]
zxzzt has joined #bitcoin-wizards
sdaftuar has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
taek-web has joined #bitcoin-wizards
jgarzik has quit [Quit: This computer has gone to sleep]
Casper- has joined #bitcoin-wizards
nubbins` has quit [Quit: Quit]
phyl729 is now known as phy1729
zooko has quit [Read error: Connection reset by peer]
zooko has joined #bitcoin-wizards
throughnothing has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
memymo has joined #bitcoin-wizards
Burrito has quit [Remote host closed the connection]
Burrito has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
zookolaptop has joined #bitcoin-wizards
taek-web has quit [Ping timeout: 252 seconds]
Guest84304 has joined #bitcoin-wizards
zooko has quit [Read error: Connection reset by peer]
zooko has joined #bitcoin-wizards
nanasho has quit [Remote host closed the connection]
pozitron has joined #bitcoin-wizards
memymo has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
memymo has joined #bitcoin-wizards
mrkent has quit []
belcher has quit [Quit: Leaving]
wallet42 has joined #bitcoin-wizards
sdaftuar has quit [Ping timeout: 245 seconds]
zxzzt has quit [Ping timeout: 260 seconds]
morcos has quit [Ping timeout: 246 seconds]
throughnothing has quit [Remote host closed the connection]
sdaftuar has joined #bitcoin-wizards
zxzzt has joined #bitcoin-wizards
morcos has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
GGuyZ has joined #bitcoin-wizards
zxzzt has quit [Ping timeout: 245 seconds]
sdaftuar has quit [Ping timeout: 260 seconds]
morcos has quit [Ping timeout: 246 seconds]
sdaftuar has joined #bitcoin-wizards
zxzzt has joined #bitcoin-wizards
memymo has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dstadulis has quit [Quit: ZZZzzz…]
morcos has joined #bitcoin-wizards
zookolaptop has quit [Ping timeout: 245 seconds]
GGuyZ has quit [Quit: GGuyZ]
Guest84304 has quit [Ping timeout: 260 seconds]
memymo has joined #bitcoin-wizards
dstadulis has joined #bitcoin-wizards
memymo has quit [Client Quit]
user has joined #bitcoin-wizards
user is now known as Guest64177
NLNico has joined #bitcoin-wizards
memymo has joined #bitcoin-wizards
Guest64177 has left #bitcoin-wizards [#bitcoin-wizards]
zooko has quit [Read error: Connection reset by peer]
zooko has joined #bitcoin-wizards
ibrightly_ is now known as ibrightly
liteIRC_ has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
zooko has quit [Ping timeout: 260 seconds]
liteIRC_ is now known as zooko
rgrant has joined #bitcoin-wizards
zookolaptop has joined #bitcoin-wizards
p15x has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
GGuyZ has joined #bitcoin-wizards
GGuyZ has quit [Client Quit]
GGuyZ has joined #bitcoin-wizards
<gmaxwell>
petertodd: sort of interesting to see signmessage 'voting' playing out: http://bitcoinocracy.com/
kyluke has quit [Read error: Connection reset by peer]
eudoxia has joined #bitcoin-wizards
koshii has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
dEBRUYNE has quit [Quit: Leaving]
SgtStroopwafel has quit [Read error: Connection reset by peer]
SgtStroopwafel has joined #bitcoin-wizards
<kanzure>
08:32 < jl2012> by the way, as the witness data is only about 60% of the current tx size, a softfork would only allow 1/(1-0.6)=2.5MB at maximum. How could that be 4MB?
jl2012 has joined #bitcoin-wizards
<jl2012>
sipa: as the witness data is only about 60% of the current tx size, a softfork would only allow 1/(1-0.6)=2.5MB at maximum. How could that be 4MB? Do you mean 4MB is the ceiling but it is impossible to reach (in a normal situation)?
brg444 has joined #bitcoin-wizards
<tromp__>
is 75% the max fraction of sig size in a tx?
<jl2012>
i think in theory it could approach 100%, as it is possible to include extra push in the scriptSig while the tx is still valid
digitalmagus8 has quit []
<instagibbs>
jl2012, right in the talk: "This is my proposal that we do right now. We implement segregated witness right now, soon. What we do is discount the witness data by 75% for block size. So this enables us to say we allow 4x as many signatures in the chain. What this normally corresponds to, with a difficult transaction load, this is around 75% capacity increase for transactions that choose to use it. Another way of looking at it, is that we
<instagibbs>
raise the block size to 4 MB for the witness part, but the non-witness has same size. The reason for doing the discount, last slide, the reason for doing this discount is that it disincentivizes UTXO impact. A signature that doesn't go into the UTXO set, can be pruned."
Casper- has quit [Read error: Connection reset by peer]
<jl2012>
this 75% figure contradicts with the graph in the slide
<tromp__>
leaving out witness data is clear. not sure what "discount by 75%" means though
<jl2012>
it shows the actual blockchain size is ~50GB, while blockchain without witness is ~20GB. That's why I say "witness" takes about 60%
<oldbrew>
and with indexing ?
<instagibbs>
jl2012, he's talking about a soft fork increase of blocksize, essentially. Not what is there now.
<instagibbs>
I gtg but im assuming he'll pop in sometime
<jl2012>
instagibbs: if I understand correctly, he means to have a new script lang. People will send to a new version of scriptPubKey, which looks like an "anyone-can-spend" script in current script lang.
<jl2012>
old nodes will allow spending of such output with an empty scriptSig. upgraded will will require extra data (ie. witness)
<oldbrew>
and the timestamp issue ?
<jl2012>
old nodes will not see the winess. But it will still see the rest, including version, sequence, outputs, and locktime
<jl2012>
and the total size of these components must not be bigger than 1MB or that will be a hardfork
<oldbrew>
At 06:28:15 UTC on Sunday, 7 February 2106, the Unix time will reach FFFFFFFF16 or 4,294,967,295 seconds which, for systems that hold the time on 32 bit unsigned numbers, is the maximum attainable. For these systems, the next second will be incorrectly interpreted as 00:00:00 Thursday 1 January 1970 UTC.
<maaku>
brg444: I disagree with Pieter's accounting methodology in his segwitness branch
<wallet42>
so the witnesses will also be in a shadow block referenced via a merkle tree comitted to coinbase?
<maaku>
wallet42: yes, essentially
<instagibbs>
jl2012, Yes. You have to hard cap the segwit size too, which I'm assuming is where he comes up with 4MB
<maaku>
my preference would be to not count the witness size at all -- except for some very high engineering limit, e.g. combined 32MB block+witness size
<wallet42>
is there a datastructure for these witnesses?
<brg444>
interesting
<instagibbs>
merkle tree, like any good crypto system
<wallet42>
i mean, it must reference a transaction id and stuff
<maaku>
but impose a new cap which uses the validation-cost metric as described by jonas
pozitron has joined #bitcoin-wizards
<instagibbs>
wallet42, 2 parallel merkle trees
<jl2012>
maaku: so people may fill the block up to 32MB by putting ignorable pushes in the witness?
<maaku>
and have that validation-cost limit scale over time ... a fixed schedule for the next few years
<wallet42>
so whats the average transaction size then?
<maaku>
then switch from fixed schedule to flexcap when the hard fork is finally instituted for >1MB old-block size
<maaku>
(we'd be closer to fee market dominated by then)
<maaku>
jl2012: jonas' work counts size as a cost, because of relay costs. you would not be able to fill 32MB at first
<brg444>
what's your take on the suggested 4mb increase with regards to bandwidth? lukejr seemed not to be sold on the idea?
<wallet42>
the blocksize w/o the whiness will be 1 mb afaiu
<wallet42>
the witness data will be stored in 3 mb
<brg444>
I understand that certainly makes it more efficient but witness data still has to be relayed by all full nodes..?
<maaku>
brg444: I would prefer a smaller validation-cost metric, which would result in ~1MB blocks or smaller
<maaku>
but with a growth schedule for that limit
<maaku>
brg444: in other words I agree with Luke-Jr
<brg444>
I see. I'll have to watch Jonas talk. It was getting late over here.
<maaku>
i believe that sipa thinks 4MB is something on the very high end of what we could support, and that is probably right
<maaku>
but IMHO we should keep more buffer room. so impose a separate, smaller limit that grows
<brg444>
Right. From where I stand the ability to softfork the limit allows us some flexibility with regards to making the first increase more conservative
<brg444>
+1
<instagibbs>
Question: If/when hardfork happens, will thinks like softfork SW be re-drawn up using "obvious" hardfork design?
<instagibbs>
or will this depend on how much PITA it is for wallets
<maaku>
first on fixed schedule, because there is no fee market, then flexcap in a few years (when we have to do the hard fork)
<jl2012>
I actually prefer a hardfork for segwit, as we may need a hardfork anyway (e.g. fix for timewarp)
<maaku>
brg444: going the way I suggest also means that we could support witnesses larger than 3MB
<maaku>
something like CT would h ave a very large witness, for example, so maybe we want the ability to have 20MB witness with a 1MB non-witness block
<maaku>
we can't support that now (effectively a 21MB block), but we could leave the capability to grow in that way, rather than impose a new hard-limit at 4MB
bramc has joined #bitcoin-wizards
<jl2012>
maaku: what is CT?
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
paveljanik has joined #bitcoin-wizards
<wallet42>
confidential transactions?
<maaku>
yes, confidential transactions
bendavenport has joined #bitcoin-wizards
<jl2012>
instagibbs: I guess if we impletemented it as softfork at the begining, we will never change the design even if we have a hardfork in the future. As that invloves extra work and risk
bhollan has joined #bitcoin-wizards
aem has quit [Ping timeout: 260 seconds]
bhollan has left #bitcoin-wizards [#bitcoin-wizards]
<maaku>
jl2012: the commitment location would almost certainly be moved in a hard fork the minimize and remove variance from hard fork size
<maaku>
with some clever work you could still keep the commitment in the old location as well so it is less disruptive, but the benefit from moving the location is well worth it
wangchun has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
aem has joined #bitcoin-wizards
opitka has quit [Quit: Leaving]
<morcos>
maaku: Aren't you worried that very large witness sizes will make it hard to run a full node?
<oldbrew>
or invalid der signature with leap second issue
GfxdjGFhgF has joined #bitcoin-wizards
<tromp__>
i thought full nodes would verify new SW blocks by reconstructing the witness merkle tree from their memory pool
btcdrak has quit [Quit: Connection closed for inactivity]
bramc has quit [Ping timeout: 240 seconds]
wangchun has quit [Quit: leaving]
wangchun has joined #bitcoin-wizards
wangchun has quit [Client Quit]
wangchun has joined #bitcoin-wizards
SgtStroopwafel has quit [Read error: Connection reset by peer]
SgtStroopwafel has joined #bitcoin-wizards
SgtStroopwafel has quit [Read error: Connection reset by peer]
SgtStroopwafel has joined #bitcoin-wizards
aem is now known as aem
SgtStroopwafel has quit [Read error: Connection reset by peer]
CubicEar_ has joined #bitcoin-wizards
SgtStroopwafel has joined #bitcoin-wizards
priidu has quit [Ping timeout: 250 seconds]
SgtStroopwafel has quit [Read error: Connection reset by peer]
CubicEarth has joined #bitcoin-wizards
CubicEar_ has quit [Ping timeout: 250 seconds]
TBI_ has joined #bitcoin-wizards
SgtStroopwafel has joined #bitcoin-wizards
melvster has quit [Ping timeout: 246 seconds]
TBI has quit [Ping timeout: 240 seconds]
bramc has joined #bitcoin-wizards
matsjj has quit [Remote host closed the connection]
btcdrak has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
dEBRUYNE has joined #bitcoin-wizards
mariorz__ is now known as mariorz
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
CubicEarth has joined #bitcoin-wizards
justanotheruser has quit [Quit: Lost terminal]
OneFixt has quit [Remote host closed the connection]
GfxdjGFhgF has quit [Quit: Leaving]
eudoxia has joined #bitcoin-wizards
Burrito has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
chmod755 has quit [Quit: Ex-Chat]
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
davec has quit [Read error: Connection reset by peer]
davec has joined #bitcoin-wizards
<sipa>
tromp__: you can't rely on mempool consistency
bramc has quit [Quit: This computer has gone to sleep]
<kanzure>
mempool should be renamed to anticonsistency-accumulator
nubbins` has quit [Quit: Quit]
pozitron has quit [Ping timeout: 240 seconds]
paveljanik has quit [Quit: Leaving]
ThomasV has quit [Ping timeout: 272 seconds]
<tromp__>
my suggestion requires some method like IBLT to resolve tx discrepancies
<tromp__>
the ultimate savings would be a single zero knowledge proof that the whole merkle tree of witnesses exists
JackH has quit [Ping timeout: 245 seconds]
<sipa>
jl2012, instagibbs, tromp__: i had to be brief in the talk at that time, but the proposal is to define the block and transaction size as 4*nonwitness + 1*witness, and constrain that value to 4MB. that is a softfork, is easy to optimize for (just a single metric), anf corresponds to around a 75% growth if the ratio witness/nonwitness remains the same while everyone upgrades to witness
<tromp__>
sipa: how is redefininf block size a softfork?
atgreen_ has quit [Ping timeout: 246 seconds]
<kanzure>
tromp__: everyone else just sees ANYONECANSPEND stuff
<tromp__>
when 4*nonwitness can exceed 1MB?
<tromp__>
oh, i see
<kanzure>
sipa: more than 50% of all the views of the transcripts have been (>6k) views of segwit.
<sipa>
tromp__: yes, but nonwitness cannot exceed 1MB :)
<tromp__>
segwit always reminds me of segway's
<sipa>
kanzure: awesome job with those transacripts... i have to say it weird to barely feel you've gone back to your seat after the talk, and see someone on the other side of the world done a writeup already of what you spoke about :)
bendavenport has quit [Quit: bendavenport]
<kanzure>
sipa: thank you. yeah mostly i think it is useful to have written text that people can read at their leisure, compared to disruptions of trying to watch/play video.
<kanzure>
sipa: next time i will endeavor to finish the writeup before you are half-way done with the talk. i think i know you well enough to guess what you are going to say anyway.
<kanzure>
((this is essentially a gmaxwell-patented method of transcribing talks))
Guest89112 has joined #bitcoin-wizards
<sipa>
kanzure: i fully agree, i'm very reluctant myself to go watch videos... they require such a long exclusive lock on your attention span, and my english understanding isn't that good that i can speed things by a signigicant factor :)
<sipa>
kanzure: ha, i'll try to send you the slides beforehand then; i believe non-causality in transcripts is worth encouraging
ebfull has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
darmou has joined #bitcoin-wizards
myeagleflies has joined #bitcoin-wizards
matsjj has quit [Remote host closed the connection]
<morcos>
sipa: i was trying to understand yesterday what disadvantages the structure we arrive at via softforking in seg wit has over a from scratch design and maaku mentioned to me the merkle header being in the coinbase makes fraud proofs bigger
<morcos>
i thought i understood that at the time, but now i don't think i do. in what case are you needing the merkle path to the witness and not already needing the merkle path to the tx
<morcos>
oh, i suppose its a differnt merkle path to the coinbase.. but still how much extra data are we talkign about, and why does it matter how big fraud proofs are
<morcos>
not that anyway was saying it was a problem i guess.. just trying to understand how much we should care about later hardforking it in more cleanly
<sipa>
morcos: indeed, i actually don't think it matters much
<sipa>
morcos: it's a factor 2 in the size of fee fraud proofs or invalid utxo spend proofs
<gmaxwell>
It doesn't really matter all that much; though if you're doing fractional verification; where you check 1 in N witnesses at random; it's a little bloaty.
<sipa>
or invalid script execution proof, i fuess
<gmaxwell>
In general having to always have additional commitments in the coinbase is subpotimal; it's a really bad hit for sublinear cumulative proof of work proofs.
<gmaxwell>
but for segwit it's no biggie.
<morcos>
so is the idea that a lite client doesnt even get the witness data for the tx they are receiving?
<sipa>
indeed
<gmaxwell>
morcos: correct; today existing SPV clients don't verify signatures for tx paying them: they _can't_ without a lot of extra bandwidth, because they'd need the whole input transactions.
<morcos>
ok i guess i was imagining fraud proofs for spending non-existing utxo's, when it seems like you had to deliver the entire merkle tree for the block with the input anyway right?
Guyver2 has quit [Quit: :)]
<gmaxwell>
For a non-existing input, you show the witness for the spend; which commits to the block with the input and which transaction in it is being spent from-- and then show that transaction.
<morcos>
oh commits to the block and the tx, how does it commit to the tx
<morcos>
i'm imagining you have to show that tx doesn't exist in that block, so need to show all the txs that do exist in that blcok (their hashes at least)
<gmaxwell>
e.g. block 12345 txindex 5.
<gmaxwell>
So we'd need to add those indexes to the chainstate.
<gmaxwell>
(height is already there)
<gmaxwell>
and the index is just which tx in the block is involved, saving having to send the whole thing.
moa has joined #bitcoin-wizards
<morcos>
ok so bear with me one sec. the attacker has created a block with valid PoW but a tx without a valid sig (back to the first case). who is going to be able to give you a fraud proof, won't no fully validating node even have the witness data for that block (or wouldn't the attacker never publish it). or am i analyzing the wrong thing?
Yoghur114 has joined #bitcoin-wizards
darmou has quit [Ping timeout: 272 seconds]
<sipa>
morcos: they can show the data at the position/height claimed they are spending from
<sipa>
and show that it either mismatches the txin:prevhash, or fails script evaluation
<morcos>
sipa: but isnt that data in the seg wit associated with the bad blcok.. who has that data?
MoALTz has joined #bitcoin-wizards
<arubi>
sorry for barging, reading a bit back, why is "bad blocks" even a term?
<sipa>
morcos: what exactly is invalid onnthe block?
<sipa>
invalid in the blocl
<morcos>
sipa: ha, you tell me. presumably something right. either the signature is invalid, it's a double spend, or it spends a non-existent utxo.
<morcos>
to know which if any of those things it is, you need the sw data right?
<morcos>
but why would the attacker ever publish the sw data?
<morcos>
if any fully validating node is going to reject the block anyway
CubicEar_ has joined #bitcoin-wizards
<morcos>
arubi: i'm probably just having some basic misconception of the purpose of fraud proofs, as its never something i've sat down to try and understand.
<sipa>
morcos: right, after the SW fork a block wothout witness data is invalid.(in the same way as a block whose merkle root mismatches transactions)
<morcos>
sipa: so i coudl see how if a lite client accepted the whole block first, then it would be easy for a full node to present them a short proof of why something in that block is invalid
<arubi>
morcos, then I'm guessing, for double spends at least, bad blocks are only valid if the block tries to replaces a current block (and it's children)
<sipa>
morcos: so fraud proofs don't work for what we currently call light clients
<sipa>
morcos: only for nodes who still download all block data, but perhaps only maintain a partial utxo set
CubicEarth has quit [Ping timeout: 240 seconds]
<morcos>
sipa: ok, that makes sense to me then. and it doesn't even have to be all block data right. they just need the blocks for txs they care about, and the fraud proof can deliver the other block if need be
<morcos>
sorry, maybe thats what you meant by all block data. all of a block when they need soemthing from that block.
<yoleaux>
[bitcoin-dev] Capacity increases for the Bitcoin system.
brg444 has quit [Quit: Page closed]
<morcos>
gmaxwell: you're welcome for my time
<morcos>
wow, awesome didn't realize you had it coded up for bitcoin already, assumed it was just in elements
<gmaxwell>
It doesn't have the fraud proofs yet; so not the more subtle parts; but indeed; the design needed implementation to validate it.
<kanzure>
very characteristic of him to forget to finish the last sentence of an email
<kanzure>
but end is least interesting part so doesn't matter :P
<gmaxwell>
kanzure: the rest of the story is for you to write.
<CubicEar_>
question about soft v hard forks -> can softforks be undone, or rolled-back with another soft fork? Or would a hard fork be required to do so?
<gmaxwell>
CubicEar_: a succesfully deployed soft-fork requires a hardfork to undo.
<gmaxwell>
(though many of them you can 'just not use' or soft-fork deactivate without actually undoing)
<gmaxwell>
e.g. CLTV. People could just stop using it. Or soft-fork out any further use of it.. but it wouldn't be undone; e.g. even with soft-forking it out that opcode would become undoable.
<CubicEar_>
gmaxwell: that is so interesting. That concept seems to have major implications for the power balance of the network, it's sort of a ratchet-mechanism, where the threshold for moving things in a soft-forkable direction is significantly lower than the threshold for moving the other way.
bendavenport has quit [Quit: bendavenport]
<gmaxwell>
I like to think of the network rules as a big block of marble. We can chip things out of the marble to make a beautiful system; but adding marble back is very hard.
<gmaxwell>
If an error is made, we can chip out further to correct it; but it imposes limitations.
bendavenport has joined #bitcoin-wizards
<gmaxwell>
And this means that people can have high confidence that missing things will stay missing; but we're not unable to adapt and improve.
<CubicEar_>
Excellent metaphor. In a sense it opens up a new attack vector, albeit a very high level one, if someone can make some soft-fork that alters the network functionality in a direction they find favorable, and unrecognized at the time is that it is detrimental to others, it can be hard to undo! (I just hadn't realized this before). Although a hard fork can fix anything, if I am understanding correctly.
<kanzure>
a successful hard-fork, at least. depending on what success means.
<CubicEar_>
Or if there are two mutually exclusive soft-fork routes to solve a problem, choosing one locks out the other, unless hard fork.
<gmaxwell>
Yes... soft-forks are also a vulnerability; but we don't really know how to prohibit them. Some day I'd like to prohibit them.
<gmaxwell>
Or constrain their nature, e.g. softforks can only effect transactions with a new version number.
<gmaxwell>
After like.. years.. of thinking about it, I think I do finally have a method to strongly discourage them.
<gmaxwell>
well "strongly".
<gmaxwell>
By strongly I mean not very strongly. :)
<nsh>
oh?
<gmaxwell>
I'll be posting about something else based on it soon, but want to get that implemented.
<nsh>
okay :)
<nsh>
(is there a clippy that pops up and says "it looks like you're trying to fork the consensus...")
<coinoperated_rob>
@gmaxwell: at the risk of overextending a metaphor, we also assume the marble block is large enough to start with, that it could contain within its initial dimensions sufficient material needed for the final masterpiece to be realized, and that unlike working with, say, wood, the material has no unexpected internal defects or knots that would force the matieral to be worked in a suboptimal way to navigate around
<coinoperated_rob>
them. It's a good mental tool though, will add to my kit :)
<gmaxwell>
But the basic idea is that full nodes, at least, can keep track of transactions which should be getting confirmed but aren't, e.g. higher feerate than the things actually getting confirmed.
<gmaxwell>
And if there is too much of this, they enter a safe mode, where they stop counting confirmations.
<gmaxwell>
This turns the suppression of transactions into a widescale denial of service attack; which would discourage it and position the network in a safe(er) place to work on changing the POW to fire the miners.
<CubicEar_>
gmaxwell: "changing the POW to fire the miners" - another great quote
<nsh>
ah so everyone gets a toys-out-of-the-pram button. got it
<tromp__>
no need to change the pow, just phase in a second one:)
<gmaxwell>
tromp__: yea, I meant change expansively.
frankenmint has joined #bitcoin-wizards
<coinoperated_rob>
is it possible to fire miners? as i undertsand things, their entrenchment is based only in part on possesion of a lotta SHA256 ASICs.
dEBRUYNE has quit [Ping timeout: 256 seconds]
<CubicEar_>
what else you think it is based on?
<coinoperated_rob>
access to ideal cost basis for infrastructure
<CubicEar_>
as in near cheap power, and decent bandwidth?
<coinoperated_rob>
they have to cycle hardware every 12 months or so regardless, to stay ahead of diff
<coinoperated_rob>
@CubicEar_ yes
<CubicEar_>
If it moved to another PoW that was primarily energy constrained... you are probably right
<tromp__>
i saw some discussion of the 21 miner chip on reddit where they ponder the goal of putting them in so many consumer devices that mining for profit becomes impossible
<CubicEar_>
(and yes, I understand the "W" in PoW is largely about energy
<coinoperated_rob>
i think all PoW is ultimtely energy constrained
<gmaxwell>
coinoperated_rob: A fair number of miners now have effectively free power; they are using surplus hydro (or industrial peak load) power that is in excess of demand.
Erik_dc has quit [Remote host closed the connection]
<coinoperated_rob>
because it's all ultimately time constrained, and energy is time purchased in bulk.
pandabearit has joined #bitcoin-wizards
<moa>
gmaxwell: I like that you have broadly used the concept of capacity and eschewed the now-overloaded "scaling" term in your email
<gmaxwell>
point being the credible threat is part of the incentive structure; and it doesn't have to be complete to have weight.
<gmaxwell>
moa: Thank you.
<coinoperated_rob>
@gmaxwell, indeed. I remember /r/bitcoinmarkets debates on this 2 years ago where that assumption was generally scoffed at. but how could it be otherwise
<moa>
because we can then have a spectrum of different types of capcity ... low-trust TX capacity, high-trust TX capicity, private TX capacity, etc ... it makes for a more formal definition of the technical problems
<gmaxwell>
coinoperated_rob: a lot of those miners are already on outdated hardware; .. the only reason to update is to get more hash for the available, very large amount of MWH available... and I expect those miners will almost always use hand-me-downs and cheaper, more mature tech.
<gmaxwell>
moa: I would have liked to talk about that more; but I was already over long.
<coinoperated_rob>
signal coherence capacity in general. what's the minimum bound on maintaining a coherent state among a planetwide grid of nodes
<coinoperated_rob>
@gmaxwell, i see - so you are saying that many miners are not positioned to leap to another gen or algo of PoW without going underwater
<coinoperated_rob>
they stay afloat solely by undercutting the energy-to-btc market price with shenanigans
<gmaxwell>
My view of the bitcoin blockchain is that it's a court with a trustworthy AI judge and perfect enforcement power within its domain. You can transact safely without trusting third parties because you can transact in front of the judge... or because you can setup your contracts so that if there is a dispute you can later take them before the judge and get justice.
<gmaxwell>
coinoperated_rob: there are free variables in your equation: how much resources will mankind spend on it? How long of a time till coherence can we tolerate? etc.
vaalbara has joined #bitcoin-wizards
pandabearit has quit [Quit: Leaving]
vaalbara has quit [Client Quit]
pandabearit has joined #bitcoin-wizards
<coinoperated_rob>
@gmaxwell: mankind is bitcoin's sole patron. Thus Bitcoin's most fundamental boundaries are defined by human factors. Patience is a biggie.
<gmaxwell>
Sure. and as a result physical limits aren't what we need to be concerned about; physically driven _trade-offs_ yes... But no one is going to fund the reactor based neutrino communication system to lower the latency of blocks between NYC and Japan by 50ms... so that it would be perhaps physically possible to do so, isn't so important. :)
<coinoperated_rob>
@gmaxwell, but for the sake of a starting point, if mankind's quirks wrt spending resources and waiting for coherence were not considered relevant, and only physical limitations of propagation of global state were evaluated, how many times per second could the entire planet confirm a single state. assume everyone plays fair, no censorship attempted, but all nodes must agree (and know they agree) before a new
<coinoperated_rob>
state change can be issued. Would this be an absolute upper limit on TPS?
<coinoperated_rob>
apologies if this question has been done to death in here
<coinoperated_rob>
@gmaxwell: I understand. We can only improve the Bitcoin we actually have right now.
<CubicEar_>
coinoperated_rob: I think it would still be probabilistic
<gmaxwell>
depends on the consensus model. for a plain paxos like consensus it's a small multiple of the broadcast communication time between all participants (and quadratic communications cost). For blockchain consensus there is really no such thing as settlement; at 'best' we get is exponentially increasing confidence that the past history won't change.
<gmaxwell>
(even absent attackers)
<coinoperated_rob>
@CubicEar_ even so the domain of prability has to be hard bound somewhere
<gmaxwell>
no, there is actually no bound within the bitcoin consensus itself, though the probablities become negligible and at some point external processes would take over, to override the consensus if it reorged too deep; but thats a social quesiton.
<coinoperated_rob>
I'm never going to get used to this macbook kbd :p
<yoleaux>
[bitcoin-dev] Capacity increases for the Bitcoin system.
<CubicEar_>
coinoperated_rob: Speed of light? One way trip time. If you wanted to hear back.. double that. Or were you thinking of a way it could be less?
smk has joined #bitcoin-wizards
<coinoperated_rob>
@gmaxwell: where does probability start to definitively lose to external factors, or rather what moderates this change - confirmation depth?
<coinoperated_rob>
@CubicEar_: No I basically agree that the speed of light is the one resource that can't be moore's law-ed away
<gmaxwell>
well the speed of light can be centeralized away.
<coinoperated_rob>
@gmaxwell: Right, VISA
<kanzure>
visa is probably not best example, ultimate example is local dictionary updates per sec, no external io
<coinoperated_rob>
@gmaxwell and probably others but i guess VISA's the target
<kanzure>
visa is not necessarily the target- they have different goals and operating requirements, widely-deployed bitcoin might look different to meet so many conflicting goals and tradeoffs
memymo has joined #bitcoin-wizards
<coinoperated_rob>
@kanzure: sure, just picking it because it's the counterexample most often brought up in casual conversation
<coinoperated_rob>
on the scalability issue
<docl>
Will we be moving close to the surface of the sun to maximize energy expenditure while minimizing time delay?
<kanzure>
time delay across surface of sun is significant
<kanzure>
would require significant sharding in certain convex hulls over the surface, plus some global consensus mechanism which might be much more delayed for the whole surface
<docl>
Seems like 1/300th of a second is a small enough fraction of 10 minutes to be handwaved away given a significant advantage in energy availability.
<coinoperated_rob>
global consensus mechanisms subject to global consensus on using global consensus meechanism. is consensus all the way up
<kanzure>
astronomical distances require more latency
<coinoperated_rob>
@doc1 1/300th is diameter or 1/2 circumference?
<docl>
Oops, it's more than that. 1 billion meters, so about 3 seconds.
<moa>
consensus networks on a Dyson sphere would be how slow then?
<docl>
coinoperated_rob: That was referring to the diameter of the sun.
Quanttek has quit [Ping timeout: 246 seconds]
memymo has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<docl>
moa: depends on the size of the DS. The smallest possible kind would be on the surface of the sun, so they would transmit signals that reach all other nodes of the same distance in about 3 seconds (assuming neutrino beams that can slice through the Sun). That would not perceptibly slow the 10 minute algorithm used by bitcoin. One at 1.0 AU would take 16 minutes at a minimum to reach all nodes, so it
<docl>
would be constantly forking.
DougieBot5000 has quit [Quit: Leaving]
dEBRUYNE has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
<kanzure>
i posted some thoughts re: a "revenue share" model of (almost) open-source software development. bitcoin can definitely solve some of the payment pieces of the puzzle, but unfortunately there's still some issues around group negotiation around software costs- can't have 100k library authors negotiate with acme corp just for acme corp to get to use some ubuntu-equivalent system. https://news.ycombinator.com/item?id=10693598