If there are multiple competing implementations, we won't have to hang on every word of some central devs.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
It is indeed an entirely self-inflicted problem on the developers' part.
They can't both discourage a diversity in implementations and also avoid the inconvenient consequences of being in a monologue position.
@theZerg
I'll back you unconditionally under the right conditions. I'd run you node for a while no matter what.
Before you commit youre time there's a lot to think about.
The problem with Core is not small block. It's the governance process that prevents large blocks.
I think Gavin is doing a great job trying to decentralizes the process, he,s doing it the long way which I think will build trust and it may mean we all abandon Core to depreciate to the Blockstream implementation.
I'm less fond of Mike's benevolent dictator model as a lead - I'd like to see a few of this type of implementation in the mix but no one dominant version.
My idea solutions would be to have developers sitting at a multidisciplinary table with economies cryptographers computer scientists and even sociologists.
The idea is every discipline would have a say. There would be some form of chart that's agreed it would be based on the original design as proposed by Satoshi. It would not be hostile to forks.
Developers will lead the execution of the vision but not dominate the process. I'd even invite some of the existing Core developers provided they agree to the charter and a diminished role.
Have you heard of Edward de Bono's Six Thinking Hats. It's something I'd including in there.
Core developers at the moment are stuck in black hat thinking - to move forward a multidisciplinary team needs to contribute acknowledge and discuss from the perspective of each hat.
With a governance system that is optimal I think it'd gain support but without that it'll be vulnerable to attack form the existing power holders.
If it gained a dominant position the first thing I'd do is an audit of Cores code.
Last edited:
molecular
Active Member
- Aug 31, 2015
- 372
- 1,391
been away for 2 weeks. Has rootstock been discussed here? Seems to be an implementation of the ethereum VM as a bitcoin sidechain. http://www.rootstock.io/
Melbustus
Active Member
- Aug 28, 2015
- 237
- 884
Regarding Bitcoin Unlimited, I posted a version of the below idea a few pages back, and have been back and forth with a few of you on it. Here's what I'm thinking:
1) It's time there's a mining pool that many people and businesses could enthusiastically support. Such a pool would need to be a non-profit, registered and based in the US (where most bitcoin businesses are), and professionally and transparently run. No such pool currently exists, and consequently, bitcoin businesses, VCs, many users, etc, don't have a real outlet through which to voice opinion via hashpower.
2) This pool should openly and aggressively support larger blocks. Bitcoin Unlimited specifically. Peter R has some comments on details. I propose it be forked from Core (too much personal-brand liability on XT).
3) The pool would accept financial support from businesses, maybe large holders, VCs, etc, and therefore hopefully be able to offer 0% fees or even overlay payouts to miners. This would organically attract hashpower to the pool, in addition to whatever hashpower would do it purely for the vision (all of us in this thread?).
4) To alleviate fears of the pool gaining >50% hashpower, perhaps the charter should contain a clause that if it holds >30% hashpower for more than 1 month, it must split into two completely separate entities, with zero management overlap.
5) A lot of us have been saying for a while that eventually non-profit pools would exist....blocksize seems the perfect catalyst to drive initial support.
6) But this entity should be built for the long-term, with more than the hopefully-temporary issue of blocksize in mind. So how should this be chartered specifically for the health and growth of the ecosystem overall in mind, over the long-term?
If anyone thinks this idea has legs, let's work out some details. Peter suggested putting together a short doc as an outline of the project, and presenting it to various businesses and individuals to get a sense for how well it would be received and whether it makes sense to pursue it more seriously.
1) It's time there's a mining pool that many people and businesses could enthusiastically support. Such a pool would need to be a non-profit, registered and based in the US (where most bitcoin businesses are), and professionally and transparently run. No such pool currently exists, and consequently, bitcoin businesses, VCs, many users, etc, don't have a real outlet through which to voice opinion via hashpower.
2) This pool should openly and aggressively support larger blocks. Bitcoin Unlimited specifically. Peter R has some comments on details. I propose it be forked from Core (too much personal-brand liability on XT).
3) The pool would accept financial support from businesses, maybe large holders, VCs, etc, and therefore hopefully be able to offer 0% fees or even overlay payouts to miners. This would organically attract hashpower to the pool, in addition to whatever hashpower would do it purely for the vision (all of us in this thread?).
4) To alleviate fears of the pool gaining >50% hashpower, perhaps the charter should contain a clause that if it holds >30% hashpower for more than 1 month, it must split into two completely separate entities, with zero management overlap.
5) A lot of us have been saying for a while that eventually non-profit pools would exist....blocksize seems the perfect catalyst to drive initial support.
6) But this entity should be built for the long-term, with more than the hopefully-temporary issue of blocksize in mind. So how should this be chartered specifically for the health and growth of the ecosystem overall in mind, over the long-term?
If anyone thinks this idea has legs, let's work out some details. Peter suggested putting together a short doc as an outline of the project, and presenting it to various businesses and individuals to get a sense for how well it would be received and whether it makes sense to pursue it more seriously.
I think this is a really good point that no one has been able to provide a convincing answer to yet.
My hunch is that the answer is incredibly simple: miners understood how to flag support for BIP100 (it just required writing a ASCII string in the coinbase TX) by themselves but they didn't know how to flag support for BIP101 (it required a change in the version number and probably recompiling source code) without running XT.
Last edited:
I think I figured out how lightning solves the double spending problem without proof of work and in a seemingly decentralised fashion. It seems to be based on some sort of game theory whereby if you try to double spend me I'll be able to double spend you first. That is, from my understanding, once a transaction is redeemed then the private keys for that transaction are shared with new keys used for each transaction. If someone tries to claim an older balance then the other side can spend all his bitcoins :
"We can revoke the old transaction: you simply give me the temporary private key you used for that transaction. Weird, I know (and that’s why you had to generate a temporary address for it). Now, if you were ever to sign and publish that old transaction, I can spend my $9.99 straight away, and create a transaction using your key and my key to spend your 1c. Your transaction (1a below) which could spend that 1c output is timelocked, so I’ll definitely get my 1c transaction into the blockchain first (and the paper uses a timelock of 40 days, not 1)." http://rusty.ozlabs.org/?p=450
However, for you to be able to double spend the attacker you must still have this private key which may have been shared quite some time ago, may have been lost, may have been corrupted, or indeed the victim may have died or the victim is technically illiterate to know how to double spend back, etc.
I'm a pretty big fan of building on bitcoin's inbuilt script system and lightning is pretty clever in many ways but I am not convinced it is in any way secure as the ugly solution to the double spend problem seems to me to be a pretty serious flaw.
"We can revoke the old transaction: you simply give me the temporary private key you used for that transaction. Weird, I know (and that’s why you had to generate a temporary address for it). Now, if you were ever to sign and publish that old transaction, I can spend my $9.99 straight away, and create a transaction using your key and my key to spend your 1c. Your transaction (1a below) which could spend that 1c output is timelocked, so I’ll definitely get my 1c transaction into the blockchain first (and the paper uses a timelock of 40 days, not 1)." http://rusty.ozlabs.org/?p=450
However, for you to be able to double spend the attacker you must still have this private key which may have been shared quite some time ago, may have been lost, may have been corrupted, or indeed the victim may have died or the victim is technically illiterate to know how to double spend back, etc.
I'm a pretty big fan of building on bitcoin's inbuilt script system and lightning is pretty clever in many ways but I am not convinced it is in any way secure as the ugly solution to the double spend problem seems to me to be a pretty serious flaw.
afaik knc miner signed a support letter in favour of bip 101 along with xapo, circle, bitpay and other 4 business. if memory serves knc was the only miner among the group, though.
look for a thread started yestetday by @theZerg for more details
@AdrianX I agree & you are right that devs have too much influence right now. A majority group of stakeholders should be able to decide (and fund) changes to the code without veto by someone with commit access, so long as that change does not run counter to the Bitcoin Unlimited vision statement (essentially the bill of rights, if you will -- protecting the individual against the majority).
But I'm just juggling around with the code right now and starting from relatively limited hands on experience. Why don't you propose something concrete for the governance? Start with a very concrete definition of what we envision a successful Bitcoin network is (Satoshi's vision in our opinion).
But at this time we may not want to scare people off (like XT did), but instead just be "Core without block limitations". After the block size issue is resolved, that is when Bitcoin Unlimited would really need to find a guiding philosophy.
@Melbustus I like your idea of an associated pool...
But I'm just juggling around with the code right now and starting from relatively limited hands on experience. Why don't you propose something concrete for the governance? Start with a very concrete definition of what we envision a successful Bitcoin network is (Satoshi's vision in our opinion).
But at this time we may not want to scare people off (like XT did), but instead just be "Core without block limitations". After the block size issue is resolved, that is when Bitcoin Unlimited would really need to find a guiding philosophy.
@Melbustus I like your idea of an associated pool...
Recent response to Adam Back:
[doublepost=1444946436,1444945644][/doublepost]
Protocol changes:
1. Remove hard-coded MAX_BLOCK_SIZE
2. Replace with user-configurable variable max_block_size
Mining changes:
3. Flag support for all proposals to increase the block size limit (e.g., build blocks with BIP101 version number and with BIP100 strings for larger blocks).
User interface changes:
4. Make max_block_size configurable in GUI somehow
5. Make max_block_size configurable as a run-time parameter
Defaults:
6. Use 8 MB as default for max_block_size?? (but keep setting for the largest blocks a node will build to < 1 MB)
[doublepost=1444946436,1444945644][/doublepost]
I think one of the first things to address is exactly how Bitcoin Unlimited should work. I am envisioning the following changes:
Protocol changes:
1. Remove hard-coded MAX_BLOCK_SIZE
2. Replace with user-configurable variable max_block_size
Mining changes:
3. Flag support for all proposals to increase the block size limit (e.g., build blocks with BIP101 version number and with BIP100 strings for larger blocks).
User interface changes:
4. Make max_block_size configurable in GUI somehow
5. Make max_block_size configurable as a run-time parameter
Defaults:
6. Use 8 MB as default for max_block_size?? (but keep setting for the largest blocks a node will build to < 1 MB)
I dont have a lot of experience doing that sort of thing - the majority of my experience on a keyboard typing words is splurged over bitcointalk.
I usually click and point and enter numbers on my computer. I'm going to think about it for now, and see if I can come up with something I consider innovative.
I've been thinking about this a bit in the light of some other comments in here earlier on.
Block size is not part of the consensus layer, this restriction is not in the original design or considered in the design intent as published in Satoshis paper. User-configurable max_block_size is a solution for the framework we have now that has a Max Block Size in the consensus layer.
In my view block size is effectively managed by the free market, as a side, I don't have a firm grasp on how IBLT will affect orphan rate as a deterrent for large blocks yet.
Ideally we wouldn't have a block size limit, and we wouldn't think of adding it, I like the idea of supporting many ideas as a flag as you proposed and I'd support that one too. But I'm just concerned it opens up the Bitcoin node network to fragmentation, in a similar vain to BIP100, it gives nodes powers over miners that may not be in the best interests of the network.
Node hosts are the keepers of the protocol, they vote by either hosting or not hosting the protocol collectively they have a veto power over the entire protocol. Do they need more power, thinking much further down the line when we get to the stage where you need a warehouse not just a server rack to host a bitcoin node?
I don'the think you'll ever need a warehouse. CPU wise, a desktop can handle 4k tps. Network is the biggest bottleneck, but more hardware won't help that. Storage (HD and memory) is also a bit of a concern, and I don't have solid numbers at my disposal at the moment, but with pruning, only archive nodes would need large storage arrays.
Last edited:
@AdrianX
I'm not sure I'm following: are you in favor of forcing "no limit" rather than having a user-selectable limit? I like the user-selectable limit because I think it is the most politically palatable (people like choice) but I think the network will behave as though there is really no limit (i.e., the block size will be set by the market).
I'm also not sure I understand your concern regarding fragmentation: I was thinking that by flagging support for BIP101, BIP100, etc., that Bitcoin-Unlimited would reduce fragmentation. For example, it would allow people who don't really care how we get bigger blocks to vote for several credible proposals at the same time. Can you explain your concern here in more detail?
I'm not sure I'm following: are you in favor of forcing "no limit" rather than having a user-selectable limit? I like the user-selectable limit because I think it is the most politically palatable (people like choice) but I think the network will behave as though there is really no limit (i.e., the block size will be set by the market).
I'm also not sure I understand your concern regarding fragmentation: I was thinking that by flagging support for BIP101, BIP100, etc., that Bitcoin-Unlimited would reduce fragmentation. For example, it would allow people who don't really care how we get bigger blocks to vote for several credible proposals at the same time. Can you explain your concern here in more detail?
@cypherdoc
Sure. Right now, when an XT node mines a block the block header's version number is set to a value that indicates support for BIP101. I am imagining that Bitcoin Unlimited would show support for BIP101 in this way too. Similarly, miners are showing support for BIP100 by writing some special string in the coinbase transaction of each block mined. I am imagining that Bitcoin Unlimited would write a similar string to show support for larger blocks in this way too.
The difference, though, is that the block size limit of Bitcoin-Unlimited would not be directly affected by what the other miners do (e.g., we wouldn't directly pay attention to the flags in the block headers). Bitcoin Unlimited's block size limit would only be affected by what the user chooses for their node.
The purpose of flagging support is only to help raise the block size limit for other nodes and miners. In other words, to help with cohesion (reduce fragmentation across multiple BIPs).
Does that make sense?
Sure. Right now, when an XT node mines a block the block header's version number is set to a value that indicates support for BIP101. I am imagining that Bitcoin Unlimited would show support for BIP101 in this way too. Similarly, miners are showing support for BIP100 by writing some special string in the coinbase transaction of each block mined. I am imagining that Bitcoin Unlimited would write a similar string to show support for larger blocks in this way too.
The difference, though, is that the block size limit of Bitcoin-Unlimited would not be directly affected by what the other miners do (e.g., we wouldn't directly pay attention to the flags in the block headers). Bitcoin Unlimited's block size limit would only be affected by what the user chooses for their node.
The purpose of flagging support is only to help raise the block size limit for other nodes and miners. In other words, to help with cohesion (reduce fragmentation across multiple BIPs).
Does that make sense?
Let us be very clear about the max block size logic. How about this:
The max block size will be user configurable. Let's call a block that exceeds this user-configurable size an "excessive block".
The node can receive excessive blocks. But it will not relay them (or mine on top of them) until the chain containing the excessive block is N blocks longer than the best alternate chain which has not had an excessive block for M blocks. N (and maybe M) is user configurable.
This is what is meant by block size being part of the protocol layer not the consensus layer.
The max block size will be user configurable. Let's call a block that exceeds this user-configurable size an "excessive block".
The node can receive excessive blocks. But it will not relay them (or mine on top of them) until the chain containing the excessive block is N blocks longer than the best alternate chain which has not had an excessive block for M blocks. N (and maybe M) is user configurable.
This is what is meant by block size being part of the protocol layer not the consensus layer.