EDIT: It vanished again from 'NEW'?! That is some serious misconfiguration of SPAM filters or something. Peter, can you try posting this?
Yup, I'm just modifying the post to go along with it and then will submit...
Cool, thank you!
Topic: Gold collapsing. Bitcoin UP. - page 9. (Read 2032247 times)
Yup, I'm just modifying the post to go along with it and then will submit...
Cool, thank you!
EDIT: It vanished again from 'NEW'?! That is some serious misconfiguration of SPAM filters or something. Peter, can you try posting this?
Yup, I'm just modifying the post to go along with it and then will submit...
In the meantime on another thread gmaxwell commented on, supposedly, Satoshi's last email sent to btc-dev mailing list(1)
He was referring to this particular Satoshi's (?) statement "I suspect we need a better incentive for users to run nodes instead of relying solely on altruism".
Maybe I'm too naive but I can't see why Justus' idea based on micropayment channels(2) shouldn't be "technically feasible".
Secondly, even if we found a way to decrease the cost of running a node to 0, this wouldn't remove pooled mining.
The main two factor that are limiting solo mining are: operational node cost and variance.
i.e. people join a pool to reduce variance rather than limit cost, especially if they represent a tiny fraction of the total hashing power.
(1) http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010238.html
(2) https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
The node incentives thing doesn't seem technically feasable. Or rather, the system had that built in but it was undermined by pooled mining. We now know how to avoid any _need_ to run pooled mining now, but it's always less costly to do so (due to the costs of running a node).
He was referring to this particular Satoshi's (?) statement "I suspect we need a better incentive for users to run nodes instead of relying solely on altruism".
Maybe I'm too naive but I can't see why Justus' idea based on micropayment channels(2) shouldn't be "technically feasible".
Secondly, even if we found a way to decrease the cost of running a node to 0, this wouldn't remove pooled mining.
The main two factor that are limiting solo mining are: operational node cost and variance.
i.e. people join a pool to reduce variance rather than limit cost, especially if they represent a tiny fraction of the total hashing power.
(1) http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010238.html
(2) https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
[...]
I think your second post got auto-modded because it was a repeat submission made quickly after your first. If you post it again now, I bet it will work. I experienced a similar problem yesterday.
I think your second post got auto-modded because it was a repeat submission made quickly after your first. If you post it again now, I bet it will work. I experienced a similar problem yesterday.
I hope you are right and I don't get banned from bitcoin_uncensored even for spamming
Reposted: https://www.reddit.com/r/bitcoin_uncensored/comments/3hd6rj/new_blocksize_bip_user_configurable_maximum_block/
EDIT: It vanished again from 'NEW'?! That is some serious misconfiguration of SPAM filters or something. Peter, can you try posting this?
The submission was rising for a while but it recently took a turn for the worse. We might need a compelling visual explanation of the proposal to plant the seed of the idea in the community's head.
your link goes to /r/bitcoin. you seriously shouldn't think it will go very far over there.
Our good guy theymos answered immediately. I also pushed it to /r/Bitcoin_uncensored. Interestingly, it completely disappeared from the 'new posts page' on Bitcoin_uncensored, and that page seems to be unordered. Is this a subreddit configuration issue?
Any post I did on /r/Bitcoin, I always could see slowly descending on the 'new' tab, and all of them were ordered by time there. Do you know how this new subreddit works?
I think your second post got auto-modded because it was a repeat submission made quickly after your first. If you post it again now, I bet it will work. I experienced a similar problem yesterday.
The submission was rising for a while but it recently took a turn for the worse. We might need a compelling visual explanation of the proposal to plant the seed of the idea in the community's head.
your link goes to /r/bitcoin. you seriously shouldn't think it will go very far over there.
Our good guy theymos answered immediately. I also pushed it to /r/Bitcoin_uncensored. Interestingly, it completely disappeared from the 'new posts page' on Bitcoin_uncensored, and that page seems to be unordered. Is this a subreddit configuration issue?
Any post I did on /r/Bitcoin, I always could see slowly descending on the 'new' tab, and all of them were ordered by time there. Do you know how this new subreddit works?
The submission was rising for a while but it recently took a turn for the worse. We might need a compelling visual explanation of the proposal to plant the seed of the idea in the community's head.
You are probably right: Except for a few who immediately understand it and are enthusiastic, it seems to invoke an 'odd feeling' for many so we have to sell this better. There might, of course, also be many legitimate concerns, but I want to try to get more than a 'no reaction' to this, eventually
More visuals are a great idea, though I think we still need to ponder about this and figure out how to do that exactly.
The submission was rising for a while but it recently took a turn for the worse. We might need a compelling visual explanation of the proposal to plant the seed of the idea in the community's head.
your link goes to /r/bitcoin. you seriously shouldn't think it will go very far over there.
As a market enthusiast, I don't care about nationality of miners or even what continent they are on, nobody has any rigt to a fair share or half a chance or whatever. We can live with all of Africa using only spv wallets, all miners in China and all nodes in Europe and USA.
If miners do not have access to the right bandwith, but everything else, they will have to get that bandwith, not? Or move, or let others do the job.
With bandwith, can they have a computer in the west to arrange the block, send only the header back to china for mining? Can a miner aquire some supercomputer, or use some special hardware to speed up verification of the previous block and generate the new? Can they use a modified mining box?
Can two or more miners cooperate? Is generating a new block a potential special service for miners?
It seems to me that the miners are the ones to have different software. Each miner probably already have his own version.
The verifying nodes have a simpler and less risky situation, so with blocksize I think the nodes always will verify larger blocks than the miners are willing to generate. In line with Peter R's thinking, they should only care about all transactions being valid, at most the risk the node is crashing. Unless an overwhelming majority refuses to accept a block, reducing block size for a node is equivalent to turning it off? Correct me if I am wrong.
If miners do not have access to the right bandwith, but everything else, they will have to get that bandwith, not? Or move, or let others do the job.
With bandwith, can they have a computer in the west to arrange the block, send only the header back to china for mining? Can a miner aquire some supercomputer, or use some special hardware to speed up verification of the previous block and generate the new? Can they use a modified mining box?
Can two or more miners cooperate? Is generating a new block a potential special service for miners?
It seems to me that the miners are the ones to have different software. Each miner probably already have his own version.
The verifying nodes have a simpler and less risky situation, so with blocksize I think the nodes always will verify larger blocks than the miners are willing to generate. In line with Peter R's thinking, they should only care about all transactions being valid, at most the risk the node is crashing. Unless an overwhelming majority refuses to accept a block, reducing block size for a node is equivalent to turning it off? Correct me if I am wrong.
The submission was rising for a while but it recently took a turn for the worse. We might need a compelling visual explanation of the proposal to plant the seed of the idea in the community's head.
There can not be disagreement on the protocol enforced limit, which is what your right hand graph shows. If there was then miners that issued larger blocks will get forked off of every miner with a lower limit.
I think the current situation is also more representative of the right hand side graph, than the left. Today all miners have a fixed protocol limit of 1MB, but many have preferences for smaller blocks. For example the stress tests showed just how many still had the 750KB soft limit in place. So we in practice have the right hand graph today.
I think the current situation is also more representative of the right hand side graph, than the left. Today all miners have a fixed protocol limit of 1MB, but many have preferences for smaller blocks. For example the stress tests showed just how many still had the 750KB soft limit in place. So we in practice have the right hand graph today.
EXACTLY!
What is needed instead is to get rid of the protocol limit in practice (maybe keep a high water anti-spam limit which is what the 1MB was/is), while letting the market show it's preferences.
NO! Christ, would you please read the line YOU wrote that I just quoted above?
Today all miners have a fixed protocol limit of 1MB, but many have preferences for smaller blocks. For example the stress tests showed just how many still had the 750KB soft limit in place. So we in practice have the right hand graph today.
This is exactly what we have today! A market of miners showing their preference under an healthy anti-spam limit. The bigbloaters would want you to believe there is urgency to ACT NOW. They support their stance with nothing more than coloured charts, failed spam tests, balloons of "future adoption" and "MOAR USERS".
The fact is we are now hovering around an average of 400kb per blocks. There is no such thing as "mainstream consumer retail adoption" anywhere in sight.
You people, you VCs and "entrepreneurs" with your "inclusion" bullshit and startup mentality. It's about time you consider maybe that is not how you build an economy.
This situation probably leads to a loose and dynamic form of market consensus on sizes. Miners that decided to only accept blocks well below most other miners' preference risk being orphaned at a higher rate and so are forced to up the size they accept to better match other miners. At the same time miners that issue blocks larger than what most other miners are willing to build on also risk being orphaned at a higher rate. The result is miners are forced by market pressures to move towards a consensus.
I'm sorry but that's absolutely broken thinking. It company ignores the fact that miners can always put more hash working for bigger blocks so that they force their big blocks down the throat of the network until smaller miners can only choke on them and die.
That is the true free-market operating. Not some "handwaving" blocksize equilibrium nonsense.
593
But to recognize his insight, I think we need to stop thinking in terms of "valid blocks" and start thinking in terms of "valid transactions." All blocks that are composed exclusively of valid transactions are valid.
I mentioned this, idk about a hundred pages back, in the form of talking about what mining is actually for.The only reason we need a P2P network and mining at all is to resolve double spending. Most of the work of validating transactions is stateless, except that two proofs are needed which require a mined blockchain to produce:
- The inputs to the transaction exist
- No transaction exists which spends the same inputs
There are really only two ways that mining can fail:
- A miner can perform a double spend
- A miner can execute a denial of service against valid transactions
The point of proof of work is to raise the cost of both of those attacks. Bitcoin never has made either of those attacks impossible in a mathmatical sense (and doing so is probably impossible) - all Bitcoin ever did was put a defined cost on those two attacks.
If people would stop arguing about undefined terms like "decentralization", then maybe instead we could talk about attacks in terms of ways an attacker might reduce the proof of work cost for performing double spending or DoS attacks.
It should be possible to stop worrying about miners and all the ways they might behave sub-optimally, as long as they don't have any way to avoid paying the specified PoW cost for any attacks they might perform.
View in these terms, having any protocol-mandated block size limit at all is a built-in denial of service attack and so should be removed as soon as possible.
Yes, you did mention this! I don't think I fully understood it though until sickpig made the comment about the "block size limit being a transport layer constraint that crept into the consensus layer."
i'm not worried about it. it's a stupid idea to begin with as it will just accelerate their own demise. of course, Cripplecoiner's have never been too smart to begin with.
I think Erdogan's insight into the game theory behind the block size limit was correct.
But to recognize his insight, I think we need to stop thinking in terms of "valid blocks" and start thinking in terms of "valid transactions." All blocks that are composed exclusively of valid transactions are valid.
Now instead of thinking that only Core and XT exist, imagine that there are dozens (and in the future possibly hundreds) of competing implementations of Bitcoin. Each implementation has its own rules for what block size it will build upon. From this viewpoint, the "effective limit" is the size of the largest block that's ever been included in the Blockchain. If a miner wants to create a larger block (e.g., to collect more fees), then he has to weigh the chances that his block is orphaned with his desire to create a larger block. If we imagine that the block size limit across the network forms some distribution as shown in the chart labelled "NEW THINKING" below, then, since the miner can't be 100% sure what this distribution is, it is rational for him to use the tip-toe method to minimize risk.
I think this is confusing a protocol enforced "limit" and market preferences.
There can not be disagreement on the protocol enforced limit, which is what your right hand graph shows. If there was then miners that issued larger blocks will get forked off of every miner with a lower limit.
I think the current situation is also more representative of the right hand side graph, than the left. Today all miners have a fixed protocol limit of 1MB, but many have preferences for smaller blocks. For example the stress tests showed just how many still had the 750KB soft limit in place. So we in practice have the right hand graph today.
What is needed instead is to get rid of the protocol limit in practice (maybe keep a high water anti-spam limit which is what the 1MB was/is), while letting the market show it's preferences. This would be like a combination of the two graphs where an anti-spam limit is far off to the right of the graph, and below that miners show a range of preferences on block sizes they are willing to both issue and accept, which looks like your graph on the right.
This situation probably leads to a loose and dynamic form of market consensus on sizes. Miners that decided to only accept blocks well below most other miners' preference risk being orphaned at a higher rate and so are forced to up the size they accept to better match other miners. At the same time miners that issue blocks larger than what most other miners are willing to build on also risk being orphaned at a higher rate. The result is miners are forced by market pressures to move towards a consensus.
This is where we should be and the hard protocol limit prevents the market from properly functioning.
i was thinking the same thing. but in practice, i think the graph on the right will be much more steep approaching the limit as drawn on the left graph. IOW, all miners will have to stay relatively close together to prevent the dynamic you just outlined of being forked off from multiple more variant block size limits. they then have to tip toe upwards.
I made those graphs quite quickly, and they are probably somewhat confusing. Think about the graph on the right as the max size of the block that a node will accept (not the max size they will attempt to mine). For example, I might set my node to accept 32 MB blocks. However, I won't attempt to mine anything larger than 1 MB until I'm reasonably confident that the majority of the hash power has made a decision similar to my own (to mine ontop of larger blocks).
Awemany took this even further by imagining that a miner could have a different policy for large blocks that are two or three blocks deep, for instance.
The block size limit does not need to be part of the consensus layer. We only need to agree on what constitutes valid transactions. The rest will work itself out because node operators have every incentive to follow the longest proof-of-work chain.
for anyone fearful of this MPEX short attack that iCE likes to BLOW up our asses, simply read this attack strategy and think a bit about it. it won't work and could represent a great opportunity for XT'ers to make some easy money:
http://qntra.net/2015/01/the-hard-fork-missile-crisis/
http://qntra.net/2015/01/the-hard-fork-missile-crisis/
Lest we forget, lead bitcoin devs Wladamir, Greg, and Pieter are opposed to GavinMikeCoin.
Why should we care?
590
Jump to: