Disgusting. If your rates go negative, you should lose control. You've done a terrible job managing the currency.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
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.
Thank you all for continuing this thread and for the highest signal to noise ratio of all the threads I read.
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".
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.
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.
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.
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/
https://www.reddit.com/r/bitcoin_uncensored/comments/3sltkx/bitcoin_doomsday_timeline/
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.
Last edited:
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
Agreed.
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.
Last edited:
- Aug 29, 2015
- 536
- 2,597
@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.
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
Well-Known Member
- Sep 29, 2015
- 2,424
- 6,410
@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.
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
Active Member
- Aug 28, 2015
- 237
- 884
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.
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.
@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!!!!
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!!!!
"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]
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.
Awesome! Keep up the great work!!
[doublepost=1447391025,1447390107][/doublepost]
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.
Last edited:
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?
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?
Last edited:
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.