- Aug 19, 2015
- 510
- 803
Kicking off this thread to have a dedicated place for discussing Bitcoin Unlimited, since /r/bitcoin_unlimited is not seeing much activity yet and coverage elsewhere leaves much to be desired.
Bitcoin Unlimited - Ideas, arguments, and proposals
- Thread starter Bloomie
- Start date
I will keep using XT unless the people behind Unlimited manage to get dozens of developers, companies and mining pools to support their version.
I think it's not realistic right now and we should work together on XT.
If we ever need more than 8GB I'm all in favour of completely removing the limit (I think companies like Coinbase & Circle will make that unnecessary)
I think it's not realistic right now and we should work together on XT.
If we ever need more than 8GB I'm all in favour of completely removing the limit (I think companies like Coinbase & Circle will make that unnecessary)
- Aug 22, 2015
- 1,558
- 4,693
I described this in the gold collapsing thread, but want to record it here, as I feel that there is mileage in BU being responsive to the hardware quality of the node which it runs upon. Also because many users will not have much idea of the best limit to set, and further that the block limit should not be set by the miners alone, i.e. that non-mining nodes should have a say, and best if an informed choice. Non-mining nodes can have an effect by not relaying blocks which are over their individual limit, although large blocks are considered for determining the chain with the most PoW.
Node environment determined block limit
Why can't BU recognise that Bitcoin is a finite system with finite capacity? The trick is not to choose some arbitrary dev-defined limit (like Satoshi's fixed 1MB), but to let the software determine the capacity for each node it runs on and the effective block limit becomes an emergent property of the functioning network. The "real" block size limit for Bitcoin at any moment will actually be unknown and only able to be approximated!
It would require a fairly simple mathematical formula where the Bitcoin-BU software takes metrics for its environment at run-time: the available disk-storage, memory, cpu, broadband speed (send/receive), etc, and calculates a block limit to serve as a default which suits the particular node capacity. The calculated limit can be flexible, varying up or down based upon changing conditions, unless the user manually overrides it. This makes the transaction handling capacity of the network much more closely aligned to the computing technology used by all the nodes that comprise it, especially the non-mining nodes.
Node environment determined block limit
Why can't BU recognise that Bitcoin is a finite system with finite capacity? The trick is not to choose some arbitrary dev-defined limit (like Satoshi's fixed 1MB), but to let the software determine the capacity for each node it runs on and the effective block limit becomes an emergent property of the functioning network. The "real" block size limit for Bitcoin at any moment will actually be unknown and only able to be approximated!
It would require a fairly simple mathematical formula where the Bitcoin-BU software takes metrics for its environment at run-time: the available disk-storage, memory, cpu, broadband speed (send/receive), etc, and calculates a block limit to serve as a default which suits the particular node capacity. The calculated limit can be flexible, varying up or down based upon changing conditions, unless the user manually overrides it. This makes the transaction handling capacity of the network much more closely aligned to the computing technology used by all the nodes that comprise it, especially the non-mining nodes.
Last edited:
Bitcoin Unlimited: A Peer-to-Peer Electronic Cash System for Planet Earth
Satoshi's original vision--a scalable Bitcoin
Bitcoin Unlimited adheres to Satoshi Nakamoto’s vision for a system that could scale up to a worldwide payment network and a decentralized monetary system. Transactions are grouped into blocks and recorded on an unforgeable global ledger known as the Bitcoin blockchain. The Blockchain is accessible to anyone in the world, secured by cryptography, and maintained by the most powerful single-purpose computing network ever created.
Governed by the code we run
The guiding principle for Bitcoin Unlimited is that the evolution of the network should be decided by the code people freely choose to run. Consensus is then an emergent property, objectively represented by the longest proof-of-work chain.
What makes a valid block?
From the Bitcoin white paper, "nodes accept the block only if all transactions in it are valid and not already spent." A block cannot be invalid because of its size. Instead, excessively large blocks that would pose technical challenges to a node are dealt with in the transport layer, increasing the block's orphaning risk. Bitcoin Unlimited nodes can accept a chain with an excessive block, when needed, in order to track consensus.
Values and beliefs: adoption is paramount
- Bitcoin should freely scale with demand through a market-based process
- The user’s experience is important
- Low fees are desirable
- Instant (0-conf) transactions are useful
- Resistance to censorship and security against double spending improves with adoption
Technical: put the user in control
- Software fork of Bitcoin Core
- Bitcoin Unlimited can simultaneously flag support for multiple block size limit proposals (BIP100, BIP101, etc.)
- The block size limit is considered to be part of the transport layer rather than part of the consensus layer. The user can adjust his node's block size limit based on the technical limitations of his hardware, while still ensuring that his node follows the longest proof-of-work chain.
Politics: Bitcoin is interdisciplinary
The voices of scientists, developers, entrepreneurs, investors and users should all be heard and respected.
Satoshi's original vision--a scalable Bitcoin
Bitcoin Unlimited adheres to Satoshi Nakamoto’s vision for a system that could scale up to a worldwide payment network and a decentralized monetary system. Transactions are grouped into blocks and recorded on an unforgeable global ledger known as the Bitcoin blockchain. The Blockchain is accessible to anyone in the world, secured by cryptography, and maintained by the most powerful single-purpose computing network ever created.
Governed by the code we run
The guiding principle for Bitcoin Unlimited is that the evolution of the network should be decided by the code people freely choose to run. Consensus is then an emergent property, objectively represented by the longest proof-of-work chain.
What makes a valid block?
From the Bitcoin white paper, "nodes accept the block only if all transactions in it are valid and not already spent." A block cannot be invalid because of its size. Instead, excessively large blocks that would pose technical challenges to a node are dealt with in the transport layer, increasing the block's orphaning risk. Bitcoin Unlimited nodes can accept a chain with an excessive block, when needed, in order to track consensus.
Values and beliefs: adoption is paramount
- Bitcoin should freely scale with demand through a market-based process
- The user’s experience is important
- Low fees are desirable
- Instant (0-conf) transactions are useful
- Resistance to censorship and security against double spending improves with adoption
Technical: put the user in control
- Software fork of Bitcoin Core
- Bitcoin Unlimited can simultaneously flag support for multiple block size limit proposals (BIP100, BIP101, etc.)
- The block size limit is considered to be part of the transport layer rather than part of the consensus layer. The user can adjust his node's block size limit based on the technical limitations of his hardware, while still ensuring that his node follows the longest proof-of-work chain.
Politics: Bitcoin is interdisciplinary
The voices of scientists, developers, entrepreneurs, investors and users should all be heard and respected.
Last edited:
@Peter R , @cypherdoc, @seweso, @theZerg
BU discussion is now pretty hard to read on the gold thread, so that's why I am posting here.
Regarding configurability: It now sounds like you (@theZerg) are also not opposed to making the fixed constant a variable set through the command line?
As a compromise on the 'unlimited' vs. configurability of the client, I propose that we make it a GUI and command line option with default of 'infinity'. (To stay true to the name).
More specifically, set infinity to 2^30 (so a good amount away from maxint), accepting that there are still folks who run on 32 bit (RasPi's etc.), with a comment in the code that this should be changed to 2^62 as soon as 32-bit machines have been phased out.
IMO, there are also other use cases for limiting block size in the client software, for example in test scenarios.
@theZerg, @seweso: I think we should center activity on github as it is mostly about code. Could you give us commit access?
@theZerg: You said you dabbled with the Bitcoin/Core code - do you have any code that would be worthwhile to put into a github branch?
[doublepost=1446021899][/doublepost]I forgot to add: I think part of the manifesto for BU should be to exclude changes to Bitcoin that will slow down level-0 significantly for higher-level use-cases of Bitcoin, such as LN. I can imagine redefined opcodes that might prevent further optimization of the level-0 transaction processing.
Call me paranoid, but I am very sure that this will be the next angle of attack from the stream blockers: Make transaction processing in Bitcoin/level-0 intertwined enough so that it is basically impossible to scale Bitcoin further. This will be done by sneaking in various 'soft-forks' to further that goal.
BU discussion is now pretty hard to read on the gold thread, so that's why I am posting here.
Regarding configurability: It now sounds like you (@theZerg) are also not opposed to making the fixed constant a variable set through the command line?
As a compromise on the 'unlimited' vs. configurability of the client, I propose that we make it a GUI and command line option with default of 'infinity'. (To stay true to the name).
More specifically, set infinity to 2^30 (so a good amount away from maxint), accepting that there are still folks who run on 32 bit (RasPi's etc.), with a comment in the code that this should be changed to 2^62 as soon as 32-bit machines have been phased out.
IMO, there are also other use cases for limiting block size in the client software, for example in test scenarios.
@theZerg, @seweso: I think we should center activity on github as it is mostly about code. Could you give us commit access?
@theZerg: You said you dabbled with the Bitcoin/Core code - do you have any code that would be worthwhile to put into a github branch?
[doublepost=1446021899][/doublepost]I forgot to add: I think part of the manifesto for BU should be to exclude changes to Bitcoin that will slow down level-0 significantly for higher-level use-cases of Bitcoin, such as LN. I can imagine redefined opcodes that might prevent further optimization of the level-0 transaction processing.
Call me paranoid, but I am very sure that this will be the next angle of attack from the stream blockers: Make transaction processing in Bitcoin/level-0 intertwined enough so that it is basically impossible to scale Bitcoin further. This will be done by sneaking in various 'soft-forks' to further that goal.
Last edited:
seweso
Member
Like i said in the other thread, i'm willing to grant Github access. But it would be nice if we can agree on some core principles first.
For me personally the idea of Bitcoin unlimited started out from the absurd idea that BIP101 wasn't already a huge compromise. BIP101 is still being painted as some extreme and dangerous proposal. When in reality it still reintroduces a feature which no-one asked for.
The blockchain limit was created as a safety net against potential DDOS attacks. It makes me angry to see it being turned into something completely different, without any consensus.
Maybe bitcoin unlimited should stand for unlimited choice. Putting trust in the idea that market forces can help Bitcoin evolve by itself. That we defy the notion that Bitcoin is some fragile animal in desperate need of central command.
It would be nice if Bitcoin unlimited is truly better than bitcoin core and bitcoin xt by being configurable.
For me personally the idea of Bitcoin unlimited started out from the absurd idea that BIP101 wasn't already a huge compromise. BIP101 is still being painted as some extreme and dangerous proposal. When in reality it still reintroduces a feature which no-one asked for.
The blockchain limit was created as a safety net against potential DDOS attacks. It makes me angry to see it being turned into something completely different, without any consensus.
Maybe bitcoin unlimited should stand for unlimited choice. Putting trust in the idea that market forces can help Bitcoin evolve by itself. That we defy the notion that Bitcoin is some fragile animal in desperate need of central command.
It would be nice if Bitcoin unlimited is truly better than bitcoin core and bitcoin xt by being configurable.
I'm in the "unlimited choice" camp, rocks and cypherdoc prefer KISS. But I'd implement any of these if we can agree and more importantly create a framework for agreement.
Ok, a quick and hopefully painless proposal:
You are (of course) (benevolent) dictator for github.com/theZerg (or wherever your code is).
From all the accounts that ever participated (until the time of this post) in the gold thread here on bitco.in and want to participate, simple majority agreement (one account, one vote) for policies regarding common repository/wiki/etc.
This, is, of course, dependent upon agreement from people who are the respective owners of those common, centralized resources.
There is, of course, no guarantee that any single individual that holds centralized resources won't eventually instate another censorship regime or whatever - but I think and am optimistic that a purely goodwill agreement will take us quite far here.
Thoughts?
I like it. Looking at prior history will stop people jumping in who want BU to fail. We can also vote to admit new voting members via the same proposal mechanism described below.
In the technical side, I will agree to merge any proposal that:
0. Is formally submitted, has a discussion period not less than 1 week and
1. Has a majority vote
2. Has an implementation (ofc I may implement it myself)
3. Implementation passes code review. Review to be done or extension requested within one week of submission 1 or 2 (whichever happens later). Extension may be needed if its a big patch.
4. If it seems like code review is stalling the process, members can vote to commit "as is".
5. Think about and work towards a means to remove the benevolent dictator... can administrative control occur in a manner similar to bitcoin multisig?
In the technical side, I will agree to merge any proposal that:
0. Is formally submitted, has a discussion period not less than 1 week and
1. Has a majority vote
2. Has an implementation (ofc I may implement it myself)
3. Implementation passes code review. Review to be done or extension requested within one week of submission 1 or 2 (whichever happens later). Extension may be needed if its a big patch.
4. If it seems like code review is stalling the process, members can vote to commit "as is".
5. Think about and work towards a means to remove the benevolent dictator... can administrative control occur in a manner similar to bitcoin multisig?
Bitcoin Unlimited: Articles of Confederation
Article 1: A Peer-to-Peer Electronic Cash System for Planet Earth
Satoshi's original vision--a scalable Bitcoin
Bitcoin Unlimited adheres to Satoshi Nakamoto’s vision for a system that could scale up to a worldwide payment network and a decentralized monetary system. Transactions are grouped into blocks and recorded on an unforgeable global ledger known as the Bitcoin blockchain. The Blockchain is accessible to anyone in the world, secured by cryptography, and maintained by the most powerful single-purpose computing network ever created.
Governed by the code we run
The guiding principle for Bitcoin Unlimited is that the evolution of the network should be decided by the code people freely choose to run. Consensus is then an emergent property, objectively represented by the longest proof-of-work chain.
What makes a valid block?
From the Bitcoin white paperi, "nodes accept the block only if all transactions in it are valid and not already spent." A block cannot be invalid because of its size. Instead, excessively large blocks that would pose technical challenges to a node are dealt with in the transport layer, increasing the block's orphaning risk. Bitcoin Unlimited nodes can accept a chain with an excessive block, when needed, in order to track consensus.
Values and beliefs: adoption is paramount
- Bitcoin should freely scale with demand through a market-based process
- The user’s experience is important
- Low fees are desirable
- Instant (0-conf) transactions are useful
- Resistance to censorship and security against double spending improves with adoption
Technical: put the user in control
- Software fork of Bitcoin Core
- Bitcoin Unlimited can simultaneously flag support for multiple block size limit proposals (BIP100, BIP101, etc.)
- The block size limit is considered to be part of the transport layer rather than part of the consensus layer. The user can adjust his node's block size limit based on the technical limitations of his hardware, while still ensuring that his node follows the longest proof-of-work chain.
Politics: Bitcoin is interdisciplinary
The voices of scientists, developers, entrepreneurs, investors and users should all be heard and respected.
Article 2: Confederation
I. All Bitcoin Unlimited (henceforth BU) activities shall be recorded and be publicly accessible.
II. BU roles shall consist of:
President: a BU Member who is responsible for the ongoing activities of the confederation. The president shall assign BUIP numbers, organize BUIP discussion, and voting.
Secretary: a BU Member who is responsible for recording activities and vote results, and making this information publicly available. Responsible for creating, maintaining and moderating a public forum where discussion can be held. Moderation is exclusively limited to moving content with an indication of it being moved – no content may be deleted.
Developer: a BU Member who is responsible for maintaining the BU code repository, reviewing and merging patches, and periodically releasing BU software.
Member: an individual who is invited to join the Confederation, signs this document, and has voted within the last 1 year.
Officer term is for two years. For continuity elections shall be staggered by 6 months and take place 1 week prior to responsibility transfer. Beginning with the President on Jan 15, 2018, then secretary, then developer. This means that the initial officer term may exceed 2 years. An officer can be removed with a 75% majority of voters, with at least 33% of members voting. A removal BUIP may not be occur within 3 months of a prior unsuccessful proposal. Removal proposals will be managed by an Officer who is not affected by the BUIP (submit multiple officer removal BUIPs separately).
III. Decisions shall be made via the following procedure:
Any member can propose a “Bitcoin Unlimited Improvement Proposal” (the Proposer). The Proposer can submit a proposal on behalf of another non-member. The president or secretary shall assign this Proposal a number and make it publicly accessible.
The President, Secretary, or Developer has a 2 week opportunity to review the proposal, and suggest modifications, within their own domain. That is, the President reviews proposals related to the operation of the Bitcoin Unlimited Confederation, the Secretary reviews proposals for adherence to BUIP standards, and the Developer reviews proposals related the the Bitcoin Unlimited code. The Proposer may choose to extend this 2 week period as long as desired.
After this period, the officers may attach an opinion or counter BUIP to this BUIP. This package shall be presented to all members and opened for discussion for a 2 week period. At the end of the two week period, members shall vote whether to adopt the BUIP. A BUIP is adopted if accepted by a majority of voters (51%) with at least 50% of members voting, unless otherwise indicated in this document (BUIPs that change these articles or remove officers).
If a counter-BUIP is proposed, voting occurs in a twofold manner: first each member votes his preference, BUIP, counter, or none, with a 33% majority. Then if the BUIP or counter-BUIP wins, each member votes to accept it or not with the normal majority requirement. Note that members could make both votes simultaneously (I vote for the counter, but if BUIP wins I vote to accept it), depending on the Secretary's implementation of this process.
V. Additional BUIP requirements on patches.
If a BUIP contains a patch, the Developer may review the patch for acceptability (bugs and coding standards) AFTER BUIP acceptance. The developer may work with the Proposer or other party for as long as necessary to ensure the patch is acceptable.
If the Proposer believes that this process is taking too long, the President or Secretary may propose that the patch be included “as is”, and schedule a vote (normal BUIP majority rules) at any time (skipping the normal BUIP process). If the BUIP does NOT contain a patch but suggests technical changes, it is the responsibility of the Proposer or other party to produce this patch. After the patch is produced, the Developer reviews it as suggested in the preceding paragraph, except in the “as is” case, the normal BUIP schedule and process must be followed.
VI. This document can be modified via a greater than 66% majority vote on a BUIP with at least 75% of the members voting.
I, the undersigned, substantially agree with the Bitcoin Unlimited Vision as defined in Article 1 and agree to work towards the success of Bitcoin as defined by Article 1. I further recognize that becoming a member of the Bitcoin Unlimited Confederation and working to undermine the Bitcoin Unlimited Vision will inflict substantial harm on the other members of the Bitcoin Unlimited Confederation, including but not limited to, loss of Member's time quantified by the average hourly wage of a principal engineer in the USA, loss of member monetary donations, and loss of opportunity. I agree to abide by the rules dictated in Article 2 in all matters pertaining to Bitcoin Unlimited.
ihttps://bitcoin.org/bitcoin.pdf
Article 1: A Peer-to-Peer Electronic Cash System for Planet Earth
Satoshi's original vision--a scalable Bitcoin
Bitcoin Unlimited adheres to Satoshi Nakamoto’s vision for a system that could scale up to a worldwide payment network and a decentralized monetary system. Transactions are grouped into blocks and recorded on an unforgeable global ledger known as the Bitcoin blockchain. The Blockchain is accessible to anyone in the world, secured by cryptography, and maintained by the most powerful single-purpose computing network ever created.
Governed by the code we run
The guiding principle for Bitcoin Unlimited is that the evolution of the network should be decided by the code people freely choose to run. Consensus is then an emergent property, objectively represented by the longest proof-of-work chain.
What makes a valid block?
From the Bitcoin white paperi, "nodes accept the block only if all transactions in it are valid and not already spent." A block cannot be invalid because of its size. Instead, excessively large blocks that would pose technical challenges to a node are dealt with in the transport layer, increasing the block's orphaning risk. Bitcoin Unlimited nodes can accept a chain with an excessive block, when needed, in order to track consensus.
Values and beliefs: adoption is paramount
- Bitcoin should freely scale with demand through a market-based process
- The user’s experience is important
- Low fees are desirable
- Instant (0-conf) transactions are useful
- Resistance to censorship and security against double spending improves with adoption
Technical: put the user in control
- Software fork of Bitcoin Core
- Bitcoin Unlimited can simultaneously flag support for multiple block size limit proposals (BIP100, BIP101, etc.)
- The block size limit is considered to be part of the transport layer rather than part of the consensus layer. The user can adjust his node's block size limit based on the technical limitations of his hardware, while still ensuring that his node follows the longest proof-of-work chain.
Politics: Bitcoin is interdisciplinary
The voices of scientists, developers, entrepreneurs, investors and users should all be heard and respected.
Article 2: Confederation
I. All Bitcoin Unlimited (henceforth BU) activities shall be recorded and be publicly accessible.
II. BU roles shall consist of:
President: a BU Member who is responsible for the ongoing activities of the confederation. The president shall assign BUIP numbers, organize BUIP discussion, and voting.
Secretary: a BU Member who is responsible for recording activities and vote results, and making this information publicly available. Responsible for creating, maintaining and moderating a public forum where discussion can be held. Moderation is exclusively limited to moving content with an indication of it being moved – no content may be deleted.
Developer: a BU Member who is responsible for maintaining the BU code repository, reviewing and merging patches, and periodically releasing BU software.
Member: an individual who is invited to join the Confederation, signs this document, and has voted within the last 1 year.
Officer term is for two years. For continuity elections shall be staggered by 6 months and take place 1 week prior to responsibility transfer. Beginning with the President on Jan 15, 2018, then secretary, then developer. This means that the initial officer term may exceed 2 years. An officer can be removed with a 75% majority of voters, with at least 33% of members voting. A removal BUIP may not be occur within 3 months of a prior unsuccessful proposal. Removal proposals will be managed by an Officer who is not affected by the BUIP (submit multiple officer removal BUIPs separately).
III. Decisions shall be made via the following procedure:
Any member can propose a “Bitcoin Unlimited Improvement Proposal” (the Proposer). The Proposer can submit a proposal on behalf of another non-member. The president or secretary shall assign this Proposal a number and make it publicly accessible.
The President, Secretary, or Developer has a 2 week opportunity to review the proposal, and suggest modifications, within their own domain. That is, the President reviews proposals related to the operation of the Bitcoin Unlimited Confederation, the Secretary reviews proposals for adherence to BUIP standards, and the Developer reviews proposals related the the Bitcoin Unlimited code. The Proposer may choose to extend this 2 week period as long as desired.
After this period, the officers may attach an opinion or counter BUIP to this BUIP. This package shall be presented to all members and opened for discussion for a 2 week period. At the end of the two week period, members shall vote whether to adopt the BUIP. A BUIP is adopted if accepted by a majority of voters (51%) with at least 50% of members voting, unless otherwise indicated in this document (BUIPs that change these articles or remove officers).
If a counter-BUIP is proposed, voting occurs in a twofold manner: first each member votes his preference, BUIP, counter, or none, with a 33% majority. Then if the BUIP or counter-BUIP wins, each member votes to accept it or not with the normal majority requirement. Note that members could make both votes simultaneously (I vote for the counter, but if BUIP wins I vote to accept it), depending on the Secretary's implementation of this process.
V. Additional BUIP requirements on patches.
If a BUIP contains a patch, the Developer may review the patch for acceptability (bugs and coding standards) AFTER BUIP acceptance. The developer may work with the Proposer or other party for as long as necessary to ensure the patch is acceptable.
If the Proposer believes that this process is taking too long, the President or Secretary may propose that the patch be included “as is”, and schedule a vote (normal BUIP majority rules) at any time (skipping the normal BUIP process). If the BUIP does NOT contain a patch but suggests technical changes, it is the responsibility of the Proposer or other party to produce this patch. After the patch is produced, the Developer reviews it as suggested in the preceding paragraph, except in the “as is” case, the normal BUIP schedule and process must be followed.
VI. This document can be modified via a greater than 66% majority vote on a BUIP with at least 75% of the members voting.
I, the undersigned, substantially agree with the Bitcoin Unlimited Vision as defined in Article 1 and agree to work towards the success of Bitcoin as defined by Article 1. I further recognize that becoming a member of the Bitcoin Unlimited Confederation and working to undermine the Bitcoin Unlimited Vision will inflict substantial harm on the other members of the Bitcoin Unlimited Confederation, including but not limited to, loss of Member's time quantified by the average hourly wage of a principal engineer in the USA, loss of member monetary donations, and loss of opportunity. I agree to abide by the rules dictated in Article 2 in all matters pertaining to Bitcoin Unlimited.
ihttps://bitcoin.org/bitcoin.pdf
seweso
Member
Why would any miner run a client which allows uncertainty about whether a block is accepted by its peers? That sentence doesn't really sell BU to miners.
More important than knowing what guides BU's design and implementation is selling the idea of BU. What is the point if only a handful of people are invested in the idea?
You can't remove FUD with a technical solution only.
How would you sell BU to a miner?
BU represents a loosening of restrictions so miners could gain more revenue. That is the miner incentive. however some uncertainty may exist in the configurable case. Ofc this uncertainty is dwarfed by the question of how many core or XT nodes are running. And there is also inherent uncertainty caused by large block propagation times. long term we are considering having BU nodes advertise their limits. But short term it seems like the simplest soln works.
Sounds good! Aand we should IMO be careful not to bikeshed the 'constitution' too much.
Here would be two suggestions, but they might as well become my first BUIP:
- emphasize collection of cryptographic identities for voting (we should all exchange GPG keys, in case this forum becomes inoperable or similar)?
- more importantly: I think it might be nice to say sth. along the lines of the following in the above document:
'Bitcoin Unlimited perceives itself as an important element in the Bitcoin ecosystem. We believe or founding statutes are firmly based on Satoshi's original vision. However, we acknowledge that Bitcoin is at its core a decentralized system and thus we will not assert centralized ownership of the protocol.'
This latter part should address concerns like @sickpig 's.
EDIT: I think we should maybe add provisions for members stepping down? This is all very much only voluntary - and for example, I could imagine 'running for BU president' or 'developer', but should I be elected, I'd very much like to give at least the president post to another member within a couple months at most...
If this becomes very successful (let me be optimistic
, I could imagine a lot of work, and an eventual 501c3 or similar on the horizon...
Last edited by a moderator:
thanks. I was expecting the secretary to propose a cryptographic identity scheme and it be adopted as one of the first BUIPs but it may make sense to put something in there so the very first vote doesn't go awry. Instead of using GPG should we associate a bitcoin address with a member and sign using it?
Others have suggested some kind of preamble or reason d'etre so maybe your para can be integrated into that. I am hoping that these articles already address sickpig's concerns significantly in that sense that this structure does not allow a small group to co-opt the process. While I'd prefer a very technically sophisticated solution, tonight (time permitting) I am going to work on some operational guidelines for Article 4. These guidelines will attempt to distribute ownership of BU resources so that no one individual can co-opt it.
I agree that we shouldn't bikeshed this. It specifies a mechanism to modify itself and so any bikeshedding should be done in parallel with getting other stuff (BU code dev, and mining pool) underway.
Others have suggested some kind of preamble or reason d'etre so maybe your para can be integrated into that. I am hoping that these articles already address sickpig's concerns significantly in that sense that this structure does not allow a small group to co-opt the process. While I'd prefer a very technically sophisticated solution, tonight (time permitting) I am going to work on some operational guidelines for Article 4. These guidelines will attempt to distribute ownership of BU resources so that no one individual can co-opt it.
I agree that we shouldn't bikeshed this. It specifies a mechanism to modify itself and so any bikeshedding should be done in parallel with getting other stuff (BU code dev, and mining pool) underway.
@theZerg
Fully agreed @ bitcoin adress. In the founding document, maybe something like 'a list of cryptographically verifiable member identities will be kept' or something like that... However, there's no reason to not have both. I think as soon as we have a Wiki, a list of (real or pseudonymous) identities + their keys would suffice for the meantime. The advantage of GPG is that it supports mutual signing of keys - is there code for Bitcoin keys that does that, too?
What's left to ponder about (but maybe not right now) is public vs. secret voting and whether we want that and if so, whether the tools for that exist to do that properly. Right now, I think every vote should be completely public.
@cypherdoc
Regarding asking Gavin about BU from the Gold thread: At some point, yes, but I think we should first get to the point that we have running and gitian-built code + a presentable website before we start talking to outsiders. Until that point, I am sure that the whole thing is considered to be just a pretty diffuse and odd thing that started on some forum...
Fully agreed @ bitcoin adress. In the founding document, maybe something like 'a list of cryptographically verifiable member identities will be kept' or something like that... However, there's no reason to not have both. I think as soon as we have a Wiki, a list of (real or pseudonymous) identities + their keys would suffice for the meantime. The advantage of GPG is that it supports mutual signing of keys - is there code for Bitcoin keys that does that, too?
What's left to ponder about (but maybe not right now) is public vs. secret voting and whether we want that and if so, whether the tools for that exist to do that properly. Right now, I think every vote should be completely public.
@cypherdoc
Regarding asking Gavin about BU from the Gold thread: At some point, yes, but I think we should first get to the point that we have running and gitian-built code + a presentable website before we start talking to outsiders. Until that point, I am sure that the whole thing is considered to be just a pretty diffuse and odd thing that started on some forum...
Good point but this is how the network works now and has always worked. SPV mining being a hack allowing miners to mine on block headers befor the block has propagated.
I didn't like the wording because it used lingo (buzz words) and concepts the average bitcoiner may not fully grasp.
But yes I agree there is room for improvement.
Last edited:
Ok I think I have added all of your feedback and plugged a lot of holes. What do you think? Sorry I cannot include it directly -- its too long.
https://docs.google.com/document/d/1TpzpjV4ShpitjQ5NfrVS2C9qPQAKWRg-qjAb1_pmN-0/edit?usp=sharing
https://docs.google.com/document/d/1TpzpjV4ShpitjQ5NfrVS2C9qPQAKWRg-qjAb1_pmN-0/edit?usp=sharing
Latest threads
-
-
[ANN] Xi Jonpeng - Let’s make America Chinese Again
- cryptoxnft
- 0 replies
-