Gold collapsing. Bitcoin UP.

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
Eventually, I guess lead programmers will have to become more like central bankers (I know, I'll dip my head in holy water), weighing their words very carefully in order to not send out unintended signals to the market. This might tone down some of the drama in the community as well.... maybe, possibly.
If there are multiple competing implementations, we won't have to hang on every word of some central devs.
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
The more I think about it the more I like the bitcoin unlimited idea. Block size is simply not a consensus issue... but nodes can choose to discourage certain sizes by not relaying.

Note that this works on the low end too. You can not relay a small block if your mempool is huge to encourage miners to build bigger blocks.

So I'm thinking working on it. If I fork will you run it? What should be the baseline? Core or XT?
@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:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
 

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.
 
  • Like
Reactions: solex and Peter R

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
One thing that continues to baffle me about how BitcoinXT was received was/is the broad lack of miner support. It feels like BIP101 has "popular" support(the kind that theymos believes are just upvoting bot armies), and business/merchant support... and some angry/upset developers... but what's the deal with the miners? Especially 21 Inc and KnC Miner... what's their deal?
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:
  • Like
Reactions: AdrianX and bitsko

Aquent

Active Member
Aug 19, 2015
252
667
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.
 
  • Like
Reactions: rocks

sickpig

Active Member
Aug 28, 2015
926
2,541
One thing that continues to baffle me about how BitcoinXT was received was/is the broad lack of miner support. It feels like BIP101 has "popular" support(the kind that theymos believes are just upvoting bot armies), and business/merchant support... and some angry/upset developers... but what's the deal with the miners? Especially 21 Inc and KnC Miner... what's their deal?
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
 
  • Like
Reactions: bitsko

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
@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...
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
Recent response to Adam Back:

[doublepost=1444946436,1444945644][/doublepost]
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).
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)
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
@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...
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.:p 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.
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
Recent response to Adam Back:
2. Replace with user-configurable variable max_block_size
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?
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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?
since they are the one's not getting paid for doing work, maybe that will create balance with miners.
 
  • Like
Reactions: AdrianX

yrral86

Active Member
Sep 4, 2015
148
271
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:
  • Like
Reactions: AdrianX

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
@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?
 
  • Like
Reactions: AdrianX

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
@Peter R

can you explain this in more detail and how it would be implemented?:

by flagging support for BIP101, BIP100, etc.
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
@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?
 

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
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.