Gold collapsing. Bitcoin UP.

[yrral86]

note how Blythe blithely refers to negative interest rates as "a legtimate tool of monetary policy" as opposed to "financial oppression".

Disgusting. If your rates go negative, you should lose control. You've done a terrible job managing the currency.

 

[rocks]

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.

Yes, transmission of a "block solution" is the correct terminology, thanks. What I have been kicking around and described are ideas on how to pre-transmit the contents of the next block in a manner that is verifiable to participating nodes and constantly adds new transactions over time until the next block solution is found.

In the end, what we really want is for found blocks to be transmitted in as close to an instantaneous manner as possible.

One method to achieve that is to compress blocks as much as possible (i.e. thin blocks and IBLT). Another method is to pre-send or agree on the block's contents to include prior to finding a block, and then just transmit the block solution once it is found. What I described is a way to do both.

 

[Epilido]

Thank you all for continuing this thread and for the highest signal to noise ratio of all the threads I read.

 

[cypherdoc]

note how Blythe blithely refers to negative interest rates as "a legtimate tool of monetary policy" as opposed to "financial oppression".

you guys need to watch this video.

note the female CB who outlines all the crazy forms of loans/liquidity they hand out to a much larger array of speculators these days.

also, Blythe Masters is truly the devil who wears prada. she outlines her vision of the blockchain enabling regulators to watch every single tx going on in the economy. all Bitcoiners should boycott her business as she is up to no good.

note the buffoon moderator who also flippantly says outrageous things aligned with big gvt and regulation. listening to him you know that the banking system relies heavily on it's crony partner big gvt to control the masses so they can make profits.

how sickening.
[doublepost=1447374586][/doublepost]lol.

Blythe: "if you suggest that we should educate the public about how to use Bitcoin? i suggest we not do that".

 

[Peter R]

I have been kicking around scaling ideas for a while and think there is a method that can achieve the following benefits:

1) Smooths block transmission evenly over the period between blocks
2) Achieves a true O(1) block transmission (that consists of just a header packet)
3) Improves the security of 0 confirm transactions
4) Economically incentivizes miners to include every fee paying transaction, and eliminates the current economic incentive to issue zero transaction blocks
5) Aligns mempools between nodes in a verifiable manner
6) Does not fork or change bitcoin in anyway

Here is the proposal I've been thinking on, feel free to tell me why this wouldn't work or why I'm crazy.

What if miners created mini-blocks between themselves, similar to how P2Pool functions, and used a chain of these mini-blocks to pre-transmit transactions to include in the next block. Here miners would agree to merge mine a lower difficultly mini-block chain that issues blocks at smaller intervals (let's say every 20 seconds on average). These mini-blocks would contain new transactions seen since the last block or mini-block. As mini-blocks are found, miners would build succeeding mini-blocks of new transactions on top of the previous mini-block, and through that process build a chain of mini-blocks that contain new transactions received since the last real main chain block. To speed transmission of mini-blocks, they would be transmitted using an IBLT of thin block headers to compress transmission the same as how real blocks can be compressed.

What this does is build a chain of mini-blocks that contain transactions to be included in the next real block. Now when a real block is found, the winning miner would only have to transmit the block header and the latest mini-block hash. Receiving nodes would reconstruct the block's transactions from the chain of mini-blocks that were built since the last block was found. If the receiving node did not have the very latest mini-block, it would only have to request the mini-blocks it hadn't received yet, which should just be 1 or 2 at the most out of the many found since the previous real block.

Such a method would provide the following properties:

1) No fork is required and there are no changes to bitcoin. The mini-block chain is just an informal method for nodes to communicate transactions to include in the next block between themselves. Any non-participating miner could still issue standard blocks not using the mini-block chain method
2) Transmission of agreed transactions to include would occur at regular intervals throughout the 10 minute average window, smoothing block propagation
3) Zero-confirm transactions could see if they are included in the next mini-block, and once they are be reasonably confident the next real block will contain the transaction. This would improve confidence in zero-confirm transactions, and be quoted as 0.1 confirmations or 0.2 or 0.3 etc. as the mini-chain builds.
4) The cost to transmit a real block is reduced to O(1). Since the winning miner is simply identifying the mini-block chain it decided to include (with it's hash), all that needs to be transmitted is the new real block header and the hash identifier of the mini-block chain to use.
5) Because of #4 above, the economic incentive to produce 0-transaction blocks is eliminated. The pre-sent mini-block chain contains fees available to claim, and the cost of claiming those transactions is zero compared to issuing a 0-transaction block.
6) Because of #5 above, miners are now economically incentivized to include as many transactions as possible.
7) The transmission of the next block is sent evenly over the period between blocks
8) All block compression techniques currently being discussed can also be used with mini-blocks.

If you assume 10 minute average real blocks, 20 second mini-blocks, a thin block header compression ratio of 14x and an IBLT compression ratio of 10x; then to support a transaction volume of 100MB every 10 minutes (i.e. 100MB blocks) nodes would only have to send 23KB every 20 seconds. By sending 23KB every 20 seconds, 100MB's of pre-broadcast transactions to include in the next block could be acknowledged by the network.

An advantage of using mini-blocks as a communication mechanism only, and not as a confirmation mechanism, is it removes many of the downsides of having smaller block time windows. Moving to less than 10 minute blocks increases orphan risk and requires users to need multiple block confirmations to be confident. Here the block time window is still 10 minutes, the mini-blocks are simply a method for miners to communicate the blocks they intend to include in the next block among each other. There is however no confirmation promise on them.

So are their reasons why this won't work? It seems as if it should to me but I'm not sure what I'm missing here.

Great post!

@rocks, this is the direction that I think we should (and will) head. I've spent some time trying to work out its effect on the fee market, but haven't made much progress yet. But yes, we can even show that this will add objectively measurable security for zero-confirm transactions!

Did you know that this is essentially the "weak block" proposal that Gavin was talking about a month or so ago?

Note that this is only true O(1) transmission for mini/weak blocks that have already propagated. If your block solution announcement contains any transactions that are not in a mini-block, then you'll have to transmit a bit more information than just the information needed to reference the mini/weak block. Since adding this extra information adds orphaning cost, then you'll only do it if the added fee revenue offset the added orphan risk. In other words, a fee market based on orphaning risk will still exist.

 

[cypherdoc]

@Peter R

weak blocks is actually Rusty's idea.

 

[rocks]

Did you know that this is essentially the "weak block" proposal that Gavin was talking about a month or so ago?

No haven't seen that. Do you have any links to his weak block thoughts. It's quite likely others have been looking at this already, I just hadn't seen this discussed yet.

Note that this is only true O(1) transmission for mini/weak blocks that have already propagated. If your block solution announcement contains any transactions that are not in a mini-block, then you'll have to transmit a bit more information than just the information needed to reference the mini/weak block. Since adding this extra information adds orphaning cost, then you'll only do it if the added fee revenue offset the added orphan risk. In other words, a fee market based on orphaning risk will still exist.

Yes, this is right. Miners in such a system have two choices:
1) They could send a solution for a chain of mini-blocks that have already been transmitted, this would require <1KB to be transmitted and the miner would be guaranteed of near instantaneous propagation.
2) They could send a solution for a chain of mini-blocks already sent PLUS a set of new transactions to add. This would have the benefit of including more fee paying transactions, but cost longer propagation times with greater risk of orphaning.

My guess is miners would only use #2 for high fee paying transactions, while more normal fee paying transactions would only be included through the mini-block pre-propagate mechanisms.

A great thing about pre-propagating transactions to include is it removes the propagation delay cost as a factor for the miner. Any minimum fee transaction now becomes worthwhile to include. The only cost is now long term storage, but I'm guessing miners would be economically incentivized to take the fee for themselves since the storage cost is shared and they will highly likely have to pay it anyway once another miner claims the transaction.

 

[Justus Ranvier]

Those trendlines could probably be drawn in better ways, but still an interesting image:

https://www.reddit.com/r/bitcoin_uncensored/comments/3sltkx/bitcoin_doomsday_timeline/

 

[Byzantine Lover]

also, Blythe Masters is truly the devil who wears prada. she outlines her vision of the blockchain enabling regulators to watch every single tx going on in the economy. all Bitcoiners should boycott her business as she is up to no good..

She might be evil, but damn I think she's sexy. I have a recurring fantasy about meeting up with her in a dark corner at a Bitcoin conference After Party.

 

[cypherdoc]

listen to these 2 idiots:

 

[Peter R]

No haven't seen that. Do you have any links to his weak block thoughts. It's quite likely others have been looking at this already, I just hadn't seen this discussed yet.

As far as I know, there are no comprehensive papers yet, but there are a few references in the top post in the reddit link:

https://www.reddit.com/r/Bitcoin/comments/3m2wpf/bitcoindev_weak_block_thoughts/

And here are some of Gavin's thoughts:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011157.html

Yes, this is right. Miners in such a system have two choices:
1) They could send a solution for a chain of mini-blocks that have already been transmitted, this would require <1KB to be transmitted and the miner would be guaranteed of near instantaneous propagation.
2) They could send a solution for a chain of mini-blocks already sent PLUS a set of new transactions to add. This would have the benefit of including more fee paying transactions, but cost longer propagation times with greater risk of orphaning.

Agreed.

A great thing about pre-propagating transactions to include is it removes the propagation delay cost as a factor for the miner. Any minimum fee transaction now becomes worthwhile to include. The only cost is now long term storage, but I'm guessing miners would be economically incentivized to take the fee for themselves since the storage cost is shared and they will highly likely have to pay it anyway once another miner claims the transaction.

I think it's a bit more subtle than that. For example, the only way a weak block gets created in the first place is if someone risks creating it. Since that person may get lucky and find a regular block, they still need to consider propagation delay (in case their weak block ends up being a strong block!)

I spent the better part of a day trying to figure out how the math would work out but I kept getting stuck.

 

[Kupsi]

Google Trends for 'bitcoin' is looking good again. Prepare for the storm.

 

[Mengerian]

@rocks

I think that your proposal is a good idea. As @Peter R mentioned, it has many similarities to the "weak block" proposal. In that scheme, the miners publish lower difficulty versions of blocks they are working on, called weak blocks. This gives the network a heads-up on "candidates" of what could be in the body of the next solved block. It's a neat idea that miners could basically just transmit a block header along with a hash identifying pre-transmitted block contents. Combined with IBLT and thin blocks, this could basically eliminate most of the burstiness and bandwidth needed for block solution propagation.

I hadn't thought of the added benefit of increased confidence for unconfirmed transactions! That could turn out to be a huge improvement to Bitcoin, and basically eliminates arguments for reducing the block interval!

One advantage I see with weak blocks, compared to your proposal, is that the miners are not wasting any hashing effort. The proof of work accompanying the weak block comes from the same hashing effort they devote to trying to solve the full blocks. In your scheme, if I understand, the miners would have to do some extra small proof of work for the "mini blocks" they send out.

 

[Norway]

@cypherdoc
Not all goldbugs are that stupid. Mike Maloney is getting it. I would love a new and updated video on bitcoin from him.
PS. That clip of Blythe was very telling. She has obviously taken the side of the old system. She will get her "reward" of failing. Karma kicking in. After all, her credit swap invention made US house owners trailer park people.

 

[Melbustus]

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

Wow...

So. What's going to happen when Zerocoin is released? I'm convinced that it's going to be a solid project, and that the key technical issues will be resolved. So that leaves politics. Governments are going to *hate* it. My thesis is that govs may start to actively *promote* bitcoin (effectively, probably not directly) in order to make sure bitcoin's network effect (and blockchain analytics) reigns in light of forthcoming truly anonymous digital cash.

Jamie Dimon's scornful comments and Blythe's blithe endorsement thereof make me think the reaction to the new stuff may very well be extreme compared to what we've seen with Bitcoin.

 

[rocks]

As far as I know, there are no comprehensive papers yet, but there are a few references in the top post in the reddit link:

https://www.reddit.com/r/Bitcoin/comments/3m2wpf/bitcoindev_weak_block_thoughts/

And here are some of Gavin's thoughts:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011157.html

Thanks for the links.

The concepts are similar in terms of pre-announcing transactions a miner is working on, but different in terms of how the pre-announcement works and more importantly how pre-announced blocks change over time and are coordinated between miners.

My understanding from the links, is with weak blocks a miner will pre-send the block they are working on and then when a block solution is found all they have to do is send the solution. The problems with this seem to be:
1) After a period of time (30 seconds or 1 min) the pre-sent block becomes stale and does not contain new transactions. The miner is then incentivized to re-send a new block out to everyone every X number of seconds. This might speed the final block solution propagation, but the cost is many duplication blocks being sent, which might increase total bandwidth used.
2) There is no method for miners to coordinate which weak block to work on. They might end up each announcing their own weak blocks to everyone else (every 30 seconds), which is both inefficient and requires miners to validate many weak blocks that would never become real blocks.

The mini-block chain described is different in that:
1) It coordinates miners (in a decentralized manner) to work on a single set of transactions to include in the next block. As each next mini-block is found only one miner will broadcast the mini-block out which contains the latest transactions to add.
2) Each mini-block builds on the chain and adds new transactions to the mini-chain. New transactions only need to be included in a single mini-block to be part of the chain, and as time goes on new transactions are simply added to the mini-chain. This means that new transactions should only be pre-announced once across all miners. For example, if 2 minutes passed since the last real block was found there should be a 6 mini-block chain containing 2 minutes worth of transactions. After 20 seconds a new mini-block is found with 20 more seconds worth of transactions and added to the chain to make it a 7 mini-block chain with 2 min 20 sec worth of transactions.
3) Because mini-blocks are added to the mini-chain at regular intervals, miners can normally mine just on the previously found mini-block. For example, mini-blocks are found every 20 seconds and a miner always mines on the last mini-block found, on average that miner will only lose 10 seconds of new transactions to include in the real block while always being guaranteed that only a block solution needs to be sent.
[doublepost=1447388582][/doublepost]

One advantage I see with weak blocks, compared to your proposal, is that the miners are not wasting any hashing effort. The proof of work accompanying the weak block comes from the same hashing effort they devote to trying to solve the full blocks. In your scheme, if I understand, the miners would have to do some extra small proof of work for the "mini blocks" they send out.

It should be possible to construct the mini-block chain to be merged mined with the next real block, just as Namecoin is merged mined with Bitcoin. This means that there is no extra hashing effort.

Miners would simultaneously merge mine the following:
a) The next real Bitcoin full block. This is the set of transactions in the latest complete mini-block chain that all miners should already have (enabling a block solution to be sent)
b) The next mini-block to add to the mini-block chain. This is a set of new transactions to add to the mini-block chain.

From a mining perspective there should be no extra hashing effort. Merged mining takes care of working on two separate blocks.

 

[theZerg]

@blythe: So for international trading whose govt/central bank controlled currency do we all agree to use? Also, I'm not sure about England and other places but over in the USA we have freedoms and rights which might interfere with Dimon's plan to get govts to simply declare Bitcoin et.al illegal. After all, its simply a form of speech.

On another note, Bitcoin Unlimited is handling large blocks! I am now working on the "excessive" block behavior and testing block chain forks and rejoins.

To do that, I'm creating multi-megabyte piles of txns in a single wallet. It was all looking good until I reorg-ed about 100 blocks. Millions of outputs are getting their balance wiped to 0. CPU is pinned at 100% for a half hour and still going. I doubt its a BU problem; its probably in all clients. But I'm guessing that this will only happen if your wallet is responsible for the entire economic activity in multiple blocks. Not really a likely scenario.

EDIT: PAGE 100!!!!

 

[Peter R]

"On another note, Bitcoin Unlimited is handling large blocks! I am now working on the "excessive" block behavior and testing block chain forks and rejoins." -- @theZerg

Awesome! Keep up the great work!!
[doublepost=1447391025,1447390107][/doublepost]

Thanks for the links.

The concepts are similar in terms of pre-announcing transactions a miner is working on, but different in terms of how the pre-announcement works and more importantly how pre-announced blocks change over time and are coordinated between miners.

My understanding from the links, is with weak blocks a miner will pre-send the block they are working on and then when a block solution is found all they have to do is send the solution. The problems with this seem to be:
1) After a period of time (30 seconds or 1 min) the pre-sent block becomes stale and does not contain new transactions. The miner is then incentivized to re-send a new block out to everyone every X number of seconds. This might speed the final block solution propagation, but the cost is many duplication blocks being sent, which might increase total bandwidth used.
2) There is no method for miners to coordinate which weak block to work on. They might end up each announcing their own weak blocks to everyone else (every 30 seconds), which is both inefficient and requires miners to validate many weak blocks that would never become real blocks.

The mini-block chain described is different in that:
1) It coordinates miners (in a decentralized manner) to work on a single set of transactions to include in the next block. As each next mini-block is found only one miner will broadcast the mini-block out which contains the latest transactions to add.
2) Each mini-block builds on the chain and adds new transactions to the mini-chain. New transactions only need to be included in a single mini-block to be part of the chain, and as time goes on new transactions are simply added to the mini-chain. This means that new transactions should only be pre-announced once across all miners. For example, if 2 minutes passed since the last real block was found there should be a 6 mini-block chain containing 2 minutes worth of transactions. After 20 seconds a new mini-block is found with 20 more seconds worth of transactions and added to the chain to make it a 7 mini-block chain with 2 min 20 sec worth of transactions.
3) Because mini-blocks are added to the mini-chain at regular intervals, miners can normally mine just on the previously found mini-block. For example, mini-blocks are found every 20 seconds and a miner always mines on the last mini-block found, on average that miner will only lose 10 seconds of new transactions to include in the real block while always being guaranteed that only a block solution needs to be sent.
[doublepost=1447388582][/doublepost]
It should be possible to construct the mini-block chain to be merged mined with the next real block, just as Namecoin is merged mined with Bitcoin. This means that there is no extra hashing effort.

Miners would simultaneously merge mine the following:
a) The next real Bitcoin full block. This is the set of transactions in the latest complete mini-block chain that all miners should already have (enabling a block solution to be sent)
b) The next mini-block to add to the mini-block chain. This is a set of new transactions to add to the mini-block chain.

From a mining perspective there should be no extra hashing effort. Merged mining takes care of working on two separate blocks.

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.

 

[Peter R]

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?

 

[AdrianX]

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

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.