Gold collapsing. Bitcoin UP.

[cypherdoc]

@AdrianX

that's a good point.

who's to say Blockstream isn't working with these gvt forces right now in secret?

 

[awemany]

There's a tiny semantic error in this statement that is nevertheless a source of a huge amount of non-productive argument.

There is no such thing as O(1) block transmission.

What you're talking about is constant-time transmission of block solutions.

Transmitting a block solution is only helpful if the recipient of your transmission already has the block it solves, either because you transmitted the block itself prior to the solution or (more likely) the information needed for the recipient to assemble the block himself.

The reason it's important to pay attention to the difference between blocks and block solutions is that when you talk about constant-time block propagation people forget about the cost associated with pre-broadcasting the block which allowed the miner to use constant-time block solution transmission in the first place.

@Justus Ranvier, @rocks, @Peter R.

Although we certainly agree on the fundamentals of the blocksize debate, I would actually locate the problem in another place. Much like the Bitcoin protocol is used to come to agreement, to consensus on the state of the chain, natural language is used between us (among other things) to come to agreement, to consensus on matters. When our language fails, we get fights, when the protocol fails, we get forks. (And now it looks like we might get both)

I would argue that an IBLT-transmitted block, which is somewhere between O(1) and O(n) in bandwidth, or also a 'true O(1) block' is still a block in the Bitcoin system according to common parlance. On one hand.

On the other hand, I think the problem lies in the realm of language and the connotations that speaking of a 'Bitcoin block' evokes. Think about it:

A block is solid, hard, big, heavy, cumbersome & in the way (think roadblock).


I think it might be helpful if we start to instead speak about agreement points or consensus points when talking about more efficient network protocols for Bitcoin - ?

I think e.g. point would be a much better-fitting word than blocks.

Or are there better suggestions for a name?


@rocks

Your proposal of mini-blocks would basically clamp the diamond-shaped uncertainties in Peter R.'s graph and I like the idea. I think it is an overall much healthier way to look at 'the blocksize issue' (or rather, the totality of Bitcoin transaction transmission behavior) - and it is also much more in line with a view as Bitcoin as a time stamping system producing a series of consensus points (formely blocks)

EDIT: And I am not sure how much the more clueless and easily swayed people in Bitcoin get hung up or scared by 'big blocks' given the above connotations a block has. This might actually be quite an effect in the 'block'size (rather: transaction rate) debate.

 

[solex]

Thought experiment:

Imagine that both the block reward schedule and the block size limit could be adjusted with a command-line option in Bitcoin Core. Assume the block reward schedule defaults to the current schedule. What would happen?

While thought experiments are useful, I really think that going any further on the path of this one is unwise. It is the kiss of death to any block limit changing proposal to link it with a change in the reward schedule. The reason is that changing the schedule makes people uneasy about the sanctity of the 21M cap. Just maybe, if the schedule can be changed the cap becomes a bit more flexible.

This is similar to how many people will accept Core+BIP101, but not XT+BIP101 even though it has only a few differences that are very reasonable. We should strive not to muddy the waters around the block limit.

 

[awemany]

@solex:

You're in the political mode of swaying the masses. I think you are (unfortunately) right in that being the right approach.

But I think there is also a set of people who are capable and willing to think clearly in principle, but haven't still grasped @Peter R.'s point yet...

 

[Peter R]

@solex: yes, that's why I only posted the thought experiment here. Of course, there is zero demand or reason to do such a thing in reality. But from an academic perspective it is interesting because the answer--assuming the theory that Bitcoin is governed by the market is correct--is that it wouldn't make a difference. The market is happy with the inflation schedule so it doesn't matter whether me make it easy or hard for people to change in their own client--it won't happen.

 

[Justus Ranvier]

I would argue that an IBLT-transmitted block, which is somewhere between O(1) and O(n) in bandwidth, or also a 'true O(1) block' is still a block in the Bitcoin system according to common parlance.

A block is defined as a header plus a merkle tree of transactions. This definition will never change, and is not in question.

The distinction to be made is that when thin blocks or IBLT is used the network creates blocks, but does not transmit blocks.

What miners do instead is transmit instructions for creating blocks, rather than the blocks themselves.

The difference between thin blocks and IBLT is that while thin blocks have a small set of instructions (compared to the size of the block itself) those instructions are not broadcast at all until a block solution is found.

With IBLT, the instructions are broadcast continually throughout the process of searching for a block solution, so they make better use of bandwidth.

 

[awemany]

A block is defined as a header plus a merkle tree of transactions. This definition will never change, and is not in question.

Agreed.

he distinction to be made is that when thin blocks or IBLT is used the network creates blocks, but does not transmit blocks.

What miners do instead is transmit instructions for creating blocks, rather than the blocks themselves.

Yes. I am suggesting that there should be a better name than 'transmission of instructions for creating blocks' or 'O(1) blocks' or similar.

That's why I suggested consensus points.

The difference between thin blocks and IBLT is that while thin blocks have a small set of instructions (compared to the size of the block itself) those instructions are not broadcast at all until a block solution is found.

With IBLT, the instructions are broadcast continually throughout the process of searching for a block solution, so they make better use of bandwidth.

Absolutely (Though there are other uses for thin blocks besides as a bandwidth saving scheme. Such as converting zero-conf to tentative-0.x-conf, as @rocks mentioned)

But again, I think we need a distinct name (distinct from block) for any agreement on the tip of the chain.

Blocks are rather what comes out of this agreement.

 

[cypherdoc]

Once gold crosses below 1000, we should see a surge in Bitcoin.
[doublepost=1447425905][/doublepost]

Wow and my jaw drops.

It looks like Blockstream have a long list of customer waiting in the winds to use their blockchain tech. Adam Back's vision to move national currencies on sidechains seems to be closer that I thought. Blythe and Dimon speak as though it's being worked on and it's not going to be Bitcoin.

One positive thing to take away from this video is that if they're that worried about Bitcoin, we must be on the right path.

 

[Justus Ranvier]

But again, I think we need a distinct name (distinct from block) for any agreement on the tip of the chain.

Is it valid to say that anything except for a block is an agreement on the tip of the chain?

 

[cypherdoc]

Yo Baby:

[doublepost=1447427498][/doublepost]it's early but continuing to catch down:

[doublepost=1447427792][/doublepost]the jaws continuing to close. will you be sucked into the black hole?:

[doublepost=1447428078,1447427225][/doublepost]

@solex: yes, that's why I only posted the thought experiment here. Of course, there is zero demand or reason to do such a thing in reality. But from an academic perspective it is interesting because the answer--assuming the theory that Bitcoin is governed by the market is correct--is that it wouldn't make a difference. The market is happy with the inflation schedule so it doesn't matter whether me make it easy or hard for people to change in their own client--it won't happen.

the problem is, those miniblockheads will link you here and twist then beat you over the head with an obfuscation.
[doublepost=1447428429][/doublepost]lol, i open up the ZSL chart and i see it's price cut in half thus silver must've quadrupled, right?

no, Proshares decided to split the share price b/c it was getting too expensive. in other words, they do this from time to time to give the illusion to investors that they aren't buying an overpriced product:

[doublepost=1447428861][/doublepost]the sheer hypocrisy of gvt:

"New York State runs a $9 billion gambling operation known as the state lottery. It is deliberately designed to attract the worst kind of fast-money, quick-hit betting favored by the desperate, the gullible and the addicted. These range from instant scratch-off tickets, to daily games, to “MegaMillions” and “PowerBall.”"

http://www.marketwatch.com/story/fanduel-draftkings-how-bitcoin-will-beat-the-online-gambling-ban-2015-11-13?siteid=rss&rss=1

 

[Peter R]

Inspired by /u/ForkiusMaximus:

Forkology 201: Rationalism vs. Empiricism and the Epistemological Nature of Bitcoin

https://www.reddit.com/r/btc/comments/3so8k5/forkology_201_rationalism_vs_empiricism_and_the/

 

[Mengerian]

Interesting. Perhaps I misunderstood the weak-block proposal, but what I was imagining in my head was basically what you just proposed.

This is my understanding:

- After a real block is solved, all the miners start working on the next block (these will all be unique).

- Eventually, one of the miners finds a weak blocks (let's say a block at 1/10th difficulty) and broadcasts it to the network.

- The other miners give up on the block they are working on, and build a new block template with all the TXs from the weak block PLUS a bunch of new TXs.

- Eventually another miner finds a weak block. He broadcasts only the NEW transactions plus the hash of the previous weak block.

- This process continues until eventually one of them finds a full-difficult block.

At any point in time a miner could choose NOT to build off the previous weak block, but why would he because he can scoop up all the fees in that weak block without accruing any of the orphaning risk. However, he still has to consider the orphaning risk for the NEW transactions he includes.

I think the way it will all work out mathematically is that weak blocks drop the supply curve from my paper by the the expected number of weak blocks per strong block. For example, if we can synchronize 10 weak blocks per strong block (one every minute), then this would allow for 10X bigger blocks on average for a given orphaning rate. If we can get 100 weak blocks per strong block (one every six seconds), then this would allow 100X bigger blocks for a given orphaning rate.

Just to try to clarify my understanding here are a few thoughts.

I think the concept that miners are "building on top of" previous weak blocks is a bit misleading. I see it working like this:

- When a miner sees a new weak block, they keep working on the block they were working on, but calculate differences between their block and the weak block.

- When the miner finds a new weak block, he transmits the weak block solution, a hash pointing to another weak block, and a "diff" between the transactions in the weak block and his new block.

- This diff can add or remove transactions. At a minimum they would want to switch out the coinbase transaction.

- There is nothing forcing miners to build on previous weak blocks, or for weak block to form a chain. There could be many different weak blocks transmitted through the network that refer to other arbitrary weak blocks.

- In order to reduce their block solution propagation times, miners would have an incentive to reduce the differences between the blocks they are working on and previous weak blocks. They would also be incentivised to work on blocks that include the most transactions and fees. So it is likely that the weak blocks would end up forming a chain of mostly adding transactions.

 

[cypherdoc]

 

[cypherdoc]

Wall St up to their no good after hours tricks again. note to all: you had no chance

lastly, the XRT retail ETF selling off, thus, it is broad based:

[doublepost=1447434505,1447433852][/doublepost]and then there's industry aluminum leader, Alcoa. you should be getting alarmed by now with that sick top left to bottom right look on the yearly charts:

[doublepost=1447435159][/doublepost]i love this video:

Quantitative Easing Explained


[doublepost=1447435600][/doublepost]

 

[rocks]

Interesting. Perhaps I misunderstood the weak-block proposal, but what I was imagining in my head was basically what you just proposed.

This is my understanding:

- After a real block is solved, all the miners start working on the next block (these will all be unique).

- Eventually, one of the miners finds a weak blocks (let's say a block at 1/10th difficulty) and broadcasts it to the network.

- The other miners give up on the block they are working on, and build a new block template with all the TXs from the weak block PLUS a bunch of new TXs.

- Eventually another miner finds a weak block. He broadcasts only the NEW transactions plus the hash of the previous weak block.

- This process continues until eventually one of them finds a full-difficult block.

At any point in time a miner could choose NOT to build off the previous weak block, but why would he because he can scoop up all the fees in that weak block without accruing any of the orphaning risk. However, he still has to consider the orphaning risk for the NEW transactions he includes.

I think the way it will all work out mathematically is that weak blocks drop the supply curve from my paper by the the expected number of weak blocks per strong block. For example, if we can synchronize 10 weak blocks per strong block (one every minute), then this would allow for 10X bigger blocks on average for a given orphaning rate. If we can get 100 weak blocks per strong block (one every six seconds), then this would allow 100X bigger blocks for a given orphaning rate.

Only briefly looked at weak blocks, so it's quite likely I misunderstood them at first pass.

What you describe is very close to what I was thinking, so it seems it is already being considered which is great. It sounds that the only minor difference I was proposing (if there is one) is to structure the series of weak blocks as a block chain where each set of new transactions to include is a weak block. This might more easily handle race situations where 2 miners find the next weak block at near the same time, here one weak block gets orphaned and the other is built on.

I also thought it made sense to set the weak block difficultly to every several seconds. This way when the next real block is found only a short time has passed since the previous weak block was issued and the winning miner can send just a block solution for the previous weak block. If weak blocks are created a minute or so apart, then since the previous weak block is a bit stale the winning miner needs to send a block solution plus a set of new transactions to append.

Either way it sounds that this is already being looked at, so great.

@cypherdoc
I remember showing my wife that QE video in 2009 saying "see this is what is happening". It is because of those (many) rants that a few years later she showed me an article on Bitcoin in 2011 thinking I might be interested in it. So in a sense I'm here because of those bears...

Favorite quotes:
"It is clear the plumber is smarter than the Ben Bernank. Yes, that is why the plumber became a plumber and not an economist"

"So let me get this straight, if I want to buy the treasury bonds I can buy them directly from the treasury? Yes ... But if the Ben Bernank wants to buy the treasury bonds using the American's money, he does not buy them from the treasury he buys them from the Goldman Sacks. Exactly. And does the Goldman Sacks give him a good price? Of course not they are the Goldman Sacks."

"So the guy in charge of the American's money when dealing with the Goldman Sacks was a partner at the Goldman Sacks, and no one has a problem with this? Apparently not. Is this an episode of the twilight zone?"

 

[rocks]

Wow and my jaw drops.

It looks like Blockstream have a long list of customer waiting in the winds to use their blockchain tech. Adam Back's vision to move national currencies on sidechains seems to be closer that I thought. Blythe and Dimon speak as though it's being worked on and it's not going to be Bitcoin.

If Blockstream is working with Blythe and Dimon then that needs to be shown and highlighted to the community far and wide. It essentially means that they are working against the core principle's of the community.

And just today LukeJr posts that he believes the 1MB limit is too high.
https://www.reddit.com/r/btc/comments/3sngnu/lukejr_furthermore_1_mb_is_already_too_large_a/
The blockstream devs keep making technical reasons to keep the limit (really FUD), but the reason's are not technical, they are self driven financial interests.

 

[cypherdoc]

@rocks

Not only would it be customary for a SC customer, and in this hypothetical the gvt, to ask for a non-compete clause for any innovation developed for their SC, but it would also be customary to ask for an NDA.

all before one red cent gets exchanged.

This is why I argue so vociferously that BS is a financial conflict of interest within core dev. Bitcoin has evolved to the point of it being a public good to be protected against ANY corporate actors potentially in a position to be compromised.

 

[sickpig]

ok, Blythe Masters has revealed her hand. we're in for a fight:

wow, just wow. I've just managed to watch the video. her thinking of bitcoin "maximalists" as a bunch of naive folks prove her own naivite, IMHO.

further demonstration of her attitude is this continuous reference to blockchain-tech narrative in which all the transnational transactions inefficiencies will be magically whashed away.

tech to solve such problems existed well before bitcoin appearance, and they are called distributed databases, two phase commits, etc etc.

those mechanisms were not applied simply because banks and financial institutions had no incentives to do it.

now such institutions fear to loose their dominant position and they are slowly reacting, of course using the wrong paradigm.

 

[AdrianX]

Thought experiment:

Imagine that both the block reward schedule and the block size limit could be adjusted with a command-line option in Bitcoin Core. Assume the block reward schedule defaults to the current schedule. What would happen?

I fished out a quote from a year ago:
Ultimately it's the economic Majority that create the rules for Bitcoin. There are more Keynesians (the Blythe Masters and Jamie Dimonds) with economic energy, than there are people invested in Bitcoin. They will form the economic majority during the next growth stage. There are more of them than there are of us, so there is a lot of change that can happen. If we want the growth to happen in Bitcoin they have to buy in to the immutable rules and the blockchain needs to accommodate the economic majority. They'll then hold the fort. If the protocol facilitates off chain growth, the majority will put there economic energy there. They'll invest in blockchain-tech side chains and LN with rules that suite the Keynesians view.

Right now Bitcoin is under attack, where the growth happens is being fort over and decided by the Blockstream Core.

 

[cypherdoc]

this $DJI catchdown is happening pretty quick. once the $DJI gets down below that little red line, we shall have a reconfirmation of the already confirmed Dow Theory Primary Bear Trend. iow, both the $DJI and $DJT will be in gear. that's when the downdraft should go into overdrive, probably swifter than even in August: