Gold collapsing. Bitcoin UP.

[79b79aa8]

@freetrader:

to problems that undermine trust in today's financial systems, i would add (echoing @bluemoon):

- monetary policy carried out by central banks on the basis of economic theory that is ideologized, poorly understood, and amended casuistically with every new cyclic crisis, certainly distorting market forces

- TBTF financial institutions

- bail outs that favor the very institutions at the root of financial crises (primarily their management, which tends to have a revolving door relationship with central banks and economic ministries)

- demonetization policies like the one just carried out in india​

also, note that:

- the world bank has little to do with monetary policy or global finances. they lend money for infrastructure and "development" projects. you should substitute that for the IFC.​

 

[Norway]

@79b79aa8 Ah yes, but memories nothing as glorious as the C-beams at Tannhauser Gate.

 

[adamstgbit]

Gavin has another solution for the concern you bring up with Xthin. His header first proposal solved this problem and provides a limit to the block size that is constrained by the technology deployed on the network. I can't recall how it worked exactly but the gist of it is, he used a time limit of 30 seconds to validating a block, so while you get the header very fast and can mine on top of it, a miner then has 30 seconds to confirm and validate the block. Blocks that could not be validated withing 30 seconds of receiving the header are orphaned. The clever thing is as technology improves bigger and more complicated blocks become viable, so while his proposal maintains a limit based on a magic number, the limit is governed by technology and the block size grows as technology improves, unlike our existing 1MB limit that becomes outdated as technology improves.

I think, there is already a time limit a block must validate within, thanks to parallel validation.

if a miner mines a block which takes 1min to validate and another miner finds a child block which takes a few seconds to validate... that 1min block will get orphen because the child block validated faster?

with the current Xthin (not "header first"), does bigger blocks take longer to validate?

 

[jbreher]

Gavin has another solution for the concern you bring up with Xthin. His header first proposal solved this problem and provides a limit to the block size that is constrained by the technology deployed on the network. I can't recall how it worked exactly but the gist of it is, he used a time limit of 30 seconds to validating a block, so while you get the header very fast and can mine on top of it, a miner then has 30 seconds to confirm and validate the block. Blocks that could not be validated withing 30 seconds of receiving the header are orphaned.

I've not read the source material, so I don't know if this was pointed out. But the astute reader will note that this is also an obvious solution to the oh-so-scary quadratic hashing issue.

 

[ascedorf]

I am sure it's been noted before,

Doesn't Xthin makes 0 conf safer,

As now there would be a marginal cost to a mining pool to directly take a tx and more importantly the more it takes the worse it gets, which is the only practical way for a rogue pool to perform double spends, helping to close the "miners could already do this" argument against 0 conf.

bringing us back to the "vending machine model" for 0 conf.

 

[freetrader]

I don't know of a better thread in this forum to post this at, so here goes, addressed to the fine scientific minds here.

Can we take the premises of this paper to establish under which assumptions for an Emergent Consensus model Bitcoin still converges with negligible or at least well-quantified impacts?

If we could do so, we would be able to present formal proof that EC is not so fundamentally different (in a meaningfully bad sense) from the "simple" Bitcoin's consensus model.

In essence, the ideal outcome I would envision is a paper building on the linked one but adapted to quantify the consensus under EC assumptions.

Ideas, thoughts?

 

[AdrianX]

I think, there is already a time limit a block must validate within, thanks to parallel validation.

if a miner mines a block which takes 1min to validate and another miner finds a child block which takes a few seconds to validate... that 1min block will get orphen because the child block validated faster?

with the current Xthin (not "header first"), does bigger blocks take longer to validate?

I don't know if it works like that but why we have SPV mining in the first place is to increase the odds of finding a block and minimizing downtime, so having some time out would be good.

The way you described it, would increase orphan risk, one can not validate a child block as it has tx dependents from the parent, and therefor wouldn't be a valid block as it would have spent, unspent outputs. it would make sense to discard the bigger of 2 blocks with a similar time stamp built on the same parent.

 

[lunar]

Sorry for shilling Shilbert but it seems this time he might have the scoop?

 

[albin]

@adamstgbit

I feel like the parallel validation material exposes a really pernicious hypocrisy in the Core position, because on the one hand they're willing to make very substantive changes on the auspices that "we're just changing miner policy", where on the other hand they want to defend relying on miner policy in a futile attempt to make the chain tip more stable than Bitcoin actually guarantees it to be. You see our favorite resident concern troll constantly jackhammering the former on reddit lately.

 

[79b79aa8]

@lunar, you mean you haven't already put your life savings into bitcoin?

 

[awemany]

@ascedorf: Yes, agreed, I think stepping out of xthin-lock is in this regard a smaller cost along an incentive line (let me hereby coin the term surprise cost ) and e.g. ignoring @Peter R 's subchains would be a bigger cost.

And that incentive line makes 0-conf possible. It is a relatively weak incentive in some regards, so 0-conf will always stay the second class citizen and you shouldn't buy a house with it. But vending machine? Sure thing.

In that sense, surprise cost would be a variant of entropy cost would be a variant of orphan cost.

Transactions that are not synced across mempools (or pre-committed with subchains) would have a relatively high surprise cost.

Note that this also concerns transactions that are not relayed by nodes, for example transactions with a fee below the minimum relay fee. Note also that nodes can implement whatever scheme they want to exclude transactions from mempools or (not) relaying certain transactions.

In that sense, all full nodes already have the dials available to influence the surprise cost landscape, relative to the economic importance that they have in the network.

It is like a variant of the emergent consensus for bigger blocks.

Further: Note the fact stated above that transactions that are not synchronized across mempools have a relatively high surprise cost.

In other words, a fee market also forms simply because fresh transactions will have not propagated widely across the network, and thus fresh transactions will have a high surprise cost. You can thus motivate the miner to include it earlier by attaching a larger fee to it.

I think implementation of @Peter R 's subchains will make this picture a lot more clear, as the provide a scale on which 0-conf transaction demand can be measured in a finer-grained way, for times below average block time of 600s.

@Gavin Andresen has a nice blog article on this, showing that this effect already occured years ago, and that the market indeed did this prioritization even back then.

 

[adamstgbit]

I don't know if it works like that but why we have SPV mining in the first place is to increase the odds of finding a block and minimizing downtime, so having some time out would be good.

The way you described it, would increase orphan risk, one can not validate a child block as it has tx dependents from the parent, and therefor wouldn't be a valid block as it would have spent, unspent outputs. it would make sense to discard the bigger of 2 blocks with a similar time stamp built on the same parent.

ops. i meant sibling not child.

so we agree with parallel validation the bigger the block is, the more likely a smaller sibling will orphen it?

i'm not sure i could ever like a specific time out, some nodes will time out others won't, because one node could be 10X more powerful than another. also if there is no sibling and the big block is orphaned because of "30sec" validation time, we end up waiting for a sibling anyway...

if there truly is a risk that "the bigger the block is, the more likely a smaller sibling will orphen it" then this will definitely have an effect on block size miners are willing to produce, and that limit is free floating with the avg speed node's can validate. good enough? or should we throw in a hardcoded limit? probably not...

the "validation time cut off" is an emergent property of the network.

it does create a bit of a problem tho...

it will incentivize miners to create empty blocks when they find a sibling and a large block is being validated. maybe at one point, BU will need to define another node parameter, somthing that allows the nodes to favor large blocks over empty blocks to a certain degree.

maybe somthing like "IB" Inadequate Blocksize, and VT Validation timeout

the logic behind IB/VT could be somthing like: "if the fast-to-validate-sibling which comes in to orphen a block which is still validating is < IB allow the bigger block VT to complete before using the sibling"

doubtful this would be useful anytime soon, but maybe when blocks get much bigger..

 

[adamstgbit]

@adamstgbit

I feel like the parallel validation material exposes a really pernicious hypocrisy in the Core position, because on the one hand they're willing to make very substantive changes on the auspices that "we're just changing miner policy", where on the other hand they want to defend relying on miner policy in a futile attempt to make the chain tip more stable than Bitcoin actually guarantees it to be. You see our favorite resident concern troll constantly jackhammering the former on reddit lately.

core believes its job is to control miners through software updates, they believe their role is "benevolent dictator of consensus". to them miners are there simply to enforce their consensus. core logic "if the network does not upgrade to 13.2 there somthing wrong with the network"

all the things they do and say, prove this point. they add in things to the code like sig discounts, and they enforce a static block size limit, because they believe they are here to dictate consensus. they call BU an alt coin because they do not believe in letting the network define itself, core logic: "without us telling miners what software to run bitcoin would be doomed."

 

[jbreher]

it will incentivize miners to create empty blocks when they find a sibling and a large block is being validated. maybe at one point, BU will need to define another node parameter, somthing that allows the nodes to favor large blocks over empty blocks to a certain degree.

This issue is self-rectifying. No additional parameter is needed. There is no incentive to create blocks smaller than the size where the marginal orphan risk cost is equal to the marginal miner's fee. A block that avoids orphaning is a benefit to the miner only to the extent that it generates revenue. As fixed block subsidy tends toward zero, the incentive to mine a zero transaction bock decreases toward zero.

 

[_mr_e]

@ascedorf:
I think implementation of @Peter R 's subchains will make this picture a lot more clear, as the provide a scale on which 0-conf transaction demand can be measured in a finer-grained way, for times below average block time of 600s.

Is anybody actively working on a subchains implementation? I remember getting really excited about Bitcoin's potential when I read that paper, I hope we see some progress on it!

 

[adamstgbit]

@jbreher
right i hadn't thought of that, the less the subsidy the more self-rectifying this "problem" is.
but the orphan risk is HUGE when your block is a 10 sec late sibling, you know for a fact if you create the same size block as the early sibling you'll lose the parallel validation race. if we come to a point where the block takes 30secs to validate and a 10sec late sibling is found, if the miner wants to win the validation race he'll simply cut out half the TX he would normally include...

but this is fine, this is the dynamic that makes huge blocks which take all the fees in mempool and 2mins to validate, not worth it. some math can probably prove that its retarded to create a block which takes 5mins to validate .. and some good math with guesstimation can arrive at a figure which is "most profitable risk/reward ratio"

A block that avoids orphaning is a benefit to the miner only to the extent that it generates revenue

right and nodes which considers the risk that a sibling might be found before his block completes its validation, and adjusts generation size appropriately ( or more to the point fee/byte ?), will be more profitable.
and i know for a fact that a validation time of >10mins is going to be very unprofitable

...

now i'm thinking continuing to mine the parent block trying to find a sibling you could sneak in, is never worth it, why not just go ahead and start minning a child??

and now... i'm thinking all this somehow ties into what EB and AD a miner should use.
lol oh BU you're so fun to think about.

 

[awemany]

@_mr_e: Not that I know of, not yet. I finally found the time (and the potential bounty is certainly motivation) to work on the voting system on the website, so at least I am getting more productive. That said, back to work

 

[AdrianX]

Someone asked an interesting question on Reddit.

It's relevant to the scaling debate and quit polarizing. I see my position with regarding bitcoin as somewhat conservative however this scaling debate makes me look ultra progressive.
I'd be interested to know how others feel about the reddit question.

 

[79b79aa8]

@cypherdoc @rocks @cliff your input is missed.

 

[adamstgbit]

@AdrianX

relating this to the scaling debate.
LN is very desirable for scaling bitcoin, so P2SH is also desirable.
the blockchain is ultimately a "settlement layer", I disagree with the idea of self imposed limits like centrally limiting blocksize, and for similar reasoning, i disagree with the idea of self imposed limits like forbidding the adoption of things like P2SH side chains and LN.
is it a mistake?
do the unknown rewards outweigh the unknown risks.
thats up to the market to decide, and us to debate about.
but pretty sure we'll see LN sooner or soon after, it feels inevitable, safe, and goooood!

BTW i view your statements as ultra-conservative.