Gold collapsing. Bitcoin UP.

[Justus Ranvier]

I'd rather the pertinent part I want to respond to show up in a quote box rather than inside "" or some "re" statement.

The way around this is to right-click on any quote button and copy the link to the clipboard. Then hover over the comment number of the last post (just above the Like button) and look at the end of the url for a "#post-xxxx" value. Paste the link you copied earlier and change its "#post-" value to the one matching the comment you want to quote.

 

[AdrianX]

@cypherdoc: don't worry--hardly anyone gets it. When I tried to explain it to Gmax he unsubscribed from the dev mailing list. I don't believe any of the Core devs understand how it works and in fact they seem vehemently opposed to even trying to understand. But the reality is that it does work--@theZerg has proved that it works on testnet.

@Peter R but does it actually encourage bigger blocks, BIP101 at least allows some miners to inch up with bigger blocks without risking an orphan. But BU punishes those who mine bigger blocks until more than 51% all agree to mine bigger blocks together.
[doublepost=1449794046][/doublepost]

The way around this is to right-click on any quote button and copy the link to the clipboard.

@Justus Ranvier you cant "quote" above if you are the last poster. no quote button or link.

I dont post much but use: [ quote ] the quote [ /quote ] I prefer that to the "quoted text" like this.
[doublepost=1449794268][/doublepost]

to the one matching the comment you want to quote.

funny now I get a little yellow quote box to just quote the highlighted text.

 

[lunar]

@theZerg

@theZerg

what if you have the excessive block setting at 4 blocks deep before accepting it and along comes a 5 block deep fork that eventually should get reorg'd like what happened in BIP66?

"is BU capable of switching over beyond the accept depth (4 blocks in this case)?" The answer is absolutely. After "accept depth" is passed, the fork with the most work is chosen. So if you had 2 forks with 50% hash power each BU would switch between them.

I haven't really understood the need for the increased complexity of choosing an 'accept depth'.

eg: As far as I understand BU talks to the network. 'I am a node, and I will not relay a block over, 16MB until obliged to do so, (in this case 4 blocks deep)'.

Seems this process effectively works as a voting mechanism, decreasing the likelyhood of >16MB block propagating through the network faster than a smaller block.

presuming you never really want to be forked then, why is it necessary to have variable 'accept depths', seems like additional complexity for no gain?

 

[solex]

@AdrianX
does it actually encourage bigger blocks?

I think it doesn't. BU strongly discourages blocks which are bigger than what the majority of the network is comfortable handling.

acoindr mentioned in his objection to BU that the capacity (max actual block size) of the network is unknown. This is true, we don't really know if it is 2MB or 20MB because of a failure in the current design. It is not only masked by the 1MB, but we have a sub-network (Corallo's relay) which allows miners to distribute blocks that they are happy with but most full nodes have no say as a new block is propagated among the miners first. The relay network needs replacing with IBLT so that all nodes have an equal approval or veto on size.

BU is the only solution which actually finds the capacity limit. Once the network has stabilized at a consensus block limit which only creeps up slowly, then we can say that the largest block hitherto seen is the network's capacity per 10 minutes. This is a major benefit as true capacity planning becomes possible. The max seen block size can be plotted over time for the rate of change, and projected forwards. Similarly, the average block size which will be smaller, and the ratio gives a measure of peak demand vs normal demand.

 

[theZerg]

@theZerg
I haven't really understood the need for the increased complexity of choosing an 'accept depth'.

eg: As far as I understand BU talks to the network. 'I am a node, and I will not relay a block over, 16MB until obliged to do so, (in this case 4 blocks deep)'.

In the case above your "accept depth" is 4. The node is never "obliged" to do so -- except as defined by the accept depth.

You could set it to 8 instead of 4 and then your BU node would "resist" excessive blocks for longer... does that make sense?


Maybe I should make a video...

 

[Zangelbert Bingledack]

@theZerg

I've found that video or any kind of visual is, as a rule, guaranteed to help people understand way more than it seems like it would.

 

[AdrianX]

In the case above your "accept depth" is 4. The node is never "obliged" to do so -- except as defined by the accept depth.

You could set it to 8 instead of 4 and then your BU node would "resist" excessive blocks for longer... does that make sense?


Maybe I should make a video...

So as a rational market big block limit proponent I can set my limit at double the average peek block size and my accept depth to 0?

That way I support bigger blocks if miners choose to make them.

 

[Zangelbert Bingledack]

@AdrianX

Yeah, but in that case why not set it at quadruple the average peak blocksize and with an accept depth of, say, 4?

 

[cypherdoc]

Gold collapsing. Bitcoin UP.

 

[theZerg]

@AdrianX I don't understand what you are trying to do...

If you want to create a hard limit (like Core and XT have) -- say 8MB, set your excessive block limit to 8MB and your "accept depth" to 10000000 (a really large number). This way if someone creates a 9MB block, BU will be aware of that block but reject it (until 10000000 blocks have been mined on top of it).


Setting AcceptDepth to 0 is basically saying I'll take any block size

 

[cypherdoc]

what the heck just happened?

did anybody else see all the Chinese splattered over this entire Economic & Policy forum?

 

[davecgh]

Yes. It seems that past couple of nights there has been quite a bit of Chinese spam showing up.

 

[cypherdoc]

Chinese miners not liking the conversation?
[doublepost=1449806305,1449805632][/doublepost]Ahem:

[doublepost=1449806571][/doublepost]Litecoin is going to die:

 

[AdrianX]

Thanks, so as I understand it, BU will accept any valid block up to the user defined limit?

And any block over the limit after I've set the depth at which a block above my limit become valid?

So if I set a size limit of 4MB and the depth limit as 0, blocks then BU will what? @theZerg got it thanks

Is my 4MB size limit known to anyone but me? And if my depth set to 0 would my 4MB size limit be largely ineffective as it would have no effect?

 

[cypherdoc]

 

[cypherdoc]

GBTC ends up 4.98% today:

 

[Melbustus]

Litecoin is going to die:

Not until blocksize/scaling is *actually* resolved in Bitcoin.

 

[chriswilmer]

If there was ever an opportunity to go all out marketing an altcoin, now would be the time. The stalled progress in Bitcoin scaling is a once-in-a-lifetime opportunity for Ripple/Litecoin/Ethereum/Monero to gain marketshare.

Incidentally, back when altcoins like NuBits and others were discussing ways to stay pegged to the US dollar I remember thinking "that will never work," and yet so far it hasn't broken down for them (my analysis is very superficial... I am basing this observation entirely on what Shapeshift tells me of the exchange rate of NuBits/Tether (which are always pretty close to 1 USD).

 

[cypherdoc]

Looks like one of core devs major supporters just went looney on Wuille and SW:

http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

 

[Justus Ranvier]

Looks like one of core devs major supporters just went looney on Wuille and SW:

Looney, sure.

I don't think he's never been a "major supporter" of the Bitcoin Core developers:

https://bitcointalk.org/index.php?topic=152027.msg1617246#msg1617246