What do we stand for?

621 views
Skip to first unread message

Mike Hearn

unread,
Aug 15, 2015, 12:29:17 PM8/15/15
to bitcoin-xt
The new website has a short statement of project principles. It isn't set in stone and isn't meant to be comprehensive or a religious document: it's just there to guide decision making and make it more predictable. Feedback is welcome!


The XT Manifesto defines what the project believes is important: commitment to these principles are what differentiates us from Bitcoin Core. We try to follow Satoshi's original vision, as it is that vision which brought the Bitcoin community together.
  • Scaling the network up to handle user demand is important, even if that means the network changes along the way. It's what Satoshi wanted and the idea of a global system used by ordinary people is what motivated many of us to join him.
  • XT provides people with information they need, even if using it requires them to make risk based decisions. For example:
    • We believe unconfirmed transactions are important. Many merchants want or need to accept payments within seconds rather than minutes or hours. XT accepts this fact and does what it can to minimise the risk, then help sellers judge what remains. It is committed to the first seen rule. We will not adopt changes that make unconfirmed transactions riskier.
    • Lightweight wallets are important. Most users cannot or will not run a fully verifying node. Most of the world population does not even own a computer: they will experience the internet exclusively via smartphones. These users must sacrifice some security in order to participate, so XT supports whatever technical tradeoffs wallet developers wish to explore.
  • Decision making is quick and clear. Decisions are made according to a leadership hierarchy. The XT software encodes decisions that follow the above principles: people who disagree are welcome to use different software, or patch ours. We do not consider writing principled software with to be centralising and do not refuse to make technical decisions or select reasonable defaults.
  • The Bitcoin XT community is friendly, pragmatic, cares about app developers and considers the user experience in everything we do. We value professionalism in technical approach and communication. We run a moderated mailing list and do not tolerate troublemakers.

Kristov Atlas

unread,
Aug 15, 2015, 1:15:56 PM8/15/15
to bitcoin-xt
Hey Mike,

These are all really great goals. (I imagine the decision-making portion to be the most controversial.)

Concerning scaling the network -- I am not a network engineer at all, but trying to improve my understanding of network engineering so I can form more informed opinions about Bitcoin. Do you consider raising the block size limit to be an act of scaling the network? Based on my reading, it seems purely an act of increasing throughput, at the (difficult to quantify) cost of raising the minimum resource requirements for full nodes. Scaling in my amateur understanding is primarily about efficiency gains. If this fits at all with your understanding, what sorts of efficiency gains for the network are in the pipeline for Bitcoin-XT?

Thanks,
Kristov

Mike Hearn

unread,
Aug 15, 2015, 1:34:51 PM8/15/15
to bitcoin-xt
Do you consider raising the block size limit to be an act of scaling the network?

Yes. Normally the way you scale a system is:
  1. Push your system to its limits. Measure how much traffic you can handle.
  2. Identify the current bottleneck.
  3. Optimize.
  4. GOTO 1
Bitcoin is extremely weird in having this hard coded limit. I've never seen any other online system that has that. It's normally considered a no-brainer that you want as many users as possible, so scaling is normally just about finding the next inefficiency and making it more efficient before actual usage catches up with you.

Obviously a hard coded limit is a pretty bad "inefficiency", seen in a certain light.

With respect to what the next bottleneck is, I delegate to Gavin's wisdom. Likely candidates are
  • Block propagation. Matt's relay network is basically just an optimisation of the Bitcoin protocol. Apparently miners like it, so, those improvements should probably be a part of the standard protocol. Or at least something like them.

  • Disk usage. The protocol needs to support pruned nodes serving what they have. Otherwise people who could provide useful network services will drop out due to insufficient disk space. I had to move one of my nodes recently when the local data files went past 40 gigabytes.

  • getblocktemplate speed. Apparently some miners find this RPC to be too slow. Gavin knows more about this.

  • Upstream bandwidth. This isn't a bottleneck per se but better control of this would certainly let more people run nodes from home.

  • At some point Bloom filtering will become untenable. I posted a writeup about ideas for a better protocol here.

Aaron Voisine

unread,
Aug 15, 2015, 2:39:39 PM8/15/15
to bitcoin-xt
These are great principles. Having these stated clearly and prominently I think will gain XT a lot of support in the developer and user communities, and ease people's fears about a split.

There seems to be a common notion that a "contentious" hard fork would lead to two separate functioning chains, which while technically possible, would never happen in practice due to strong economic incentives. I think somehow addressing this worry would also go a long way to increasing XT support.

Aaron Voisine
co-founder and CEO
breadwallet.com

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mike Hearn

unread,
Aug 15, 2015, 4:01:55 PM8/15/15
to bitcoin-xt
Thanks Aaron!

The FAQ does have a question that talks about the possibility of a split currency. I agree it seems unlikely, but I don't know what else to say beyond what you said already. 

I'm a bit wary of making arguments based on incentives at the moment, because there's just been so much irrational activity lately. Censoring of user forums, DoS attacking nodes etc. Some people have turned this into an issue of emotion and identity, and that's when rationality goes out the window.

From a technical perspective it would be tricky to make transactions that move coins on one side of the chain but not the other, so that'd pose an issue to people who wanted to try and actually have two different currencies. Someone would have to either use newly mined coins, or try and double spend on either side of the fork, and then hand out or spam "taint coins" to try and make people start tagging their transactions so they're only valid on a single side. But that'd be very expensive and complicated. And people who didn't want that could use wallets that watch out for it and ignore the taint spam.


Jawad Yaqub

unread,
Aug 15, 2015, 7:17:28 PM8/15/15
to bitcoin-xt
Hi Mike

I would like to submit a patch to allow the BitCoin blockchain to act as a register in a decentralized computer. To whom would I speak about that please?

Kind Regards

Jawad Yaqub
Razormind

Mike Hearn

unread,
Aug 16, 2015, 9:05:04 AM8/16/15
to bitcoin-xt
I don't understand what you mean, but the way to submit patches is via github pull requests. Then I'll probably just kick it over to Gavin to look at, but he's on vacation this week.

Jawad Yaqub

unread,
Aug 16, 2015, 10:28:33 AM8/16/15
to bitcoin-xt
It's kind of a major change to the underlying functionality - I guess I'm just asking whether that is allowed in your roadmap?

On Sun, 16 Aug 2015 at 14:05 Mike Hearn <he...@vinumeris.com> wrote:
I don't understand what you mean, but the way to submit patches is via github pull requests. Then I'll probably just kick it over to Gavin to look at, but he's on vacation this week.

--
You received this message because you are subscribed to a topic in the Google Groups "bitcoin-xt" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoin-xt/irrzfMH_dfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoin-xt+...@googlegroups.com.

GGG 2014

unread,
Aug 16, 2015, 4:10:21 PM8/16/15
to bitcoin-xt
Jawad Yaqub,


I think that you are on the wrong page as bitcoin only transmits and does worldwide checking of bitcoin transactions of a quantity of bitcoin from one or more source addresses to one or more destination addresses.  Most of the content of each transaction turns out to be those addresses.   Now you seem to be asking about an arbitrary person being allowed to redefine the transmitted content as something
 unspecified.  Suppose for example that your nefarious twin brother wanted the body of a transaction to pass chmod +777 of a transaction description, and the description be "10 REM nefarious content in BBC BASIC \n20 PRINT "whoops"\n 30 GOTO 20\n".  Can you see any possible reason why that might be a bad idea to allow on the worldwide financial transaction system?  This particular example won't do anything unless you happen to have BBC BASIC but is, I hope, answering your question of whether and why arbitrary changes by anyone to the bitcoin core are allowed.


zerotechnology

Jawad Yaqub

unread,
Aug 16, 2015, 4:40:53 PM8/16/15
to bitcoin-xt
It's a blockchain, and we can use it to record pretty much whatever we want. If you can store and retrieve data reliably from the blockchain worldwide - why not update the block format to include more friendly and utilitarian classes of content?

Washington Sanchez

unread,
Aug 18, 2015, 6:18:01 PM8/18/15
to bitcoin-xt
I feel that one of the major reasons why this fork occurred in the first place is that a common vision wasn't specifically delineated... although one could argue that a 'peer-to-peer electronic cash system' was specific enough as Satoshi didn't use the word 'settlement'.

While I and my colleagues are 100% for larger blocks, fitting with Satoshi's vision, my concern now is that core features of the protocol that we take for granted will be up for grabs in the future *unless* we clearly spell them out.

The most pressing feature of the protocol I'm referring to is the 21 million cap. This needs to be set in stone as a constant and not a variable.

Unfortunately the XT fork have motivated some in the Bitcoin community to start pushing for raising that cap, which in my view is a deal-breaker.

Chris Wilmer

unread,
Aug 18, 2015, 6:59:15 PM8/18/15
to bitcoin-xt
I'm surprised by the amount of people that draw an equivalence between changing the maximum block size to changing the total supply of bitcoins. Those are *extremely* different changes. Just because the former can be changed (and not at all easily), doesn't mean the latter can be changed. It's like the difference between the Supreme Court of a country deciding that gay marriage is legal and deciding that murder is legal. If anything, the extraordinary effort and opposition people have put into preventing the block size from changing has given me a lot of confidence that the 21 million Bitcoin limit really will never change.

Kristov Atlas

unread,
Aug 18, 2015, 7:05:41 PM8/18/15
to bitco...@googlegroups.com

It should probably ease some minds if Mike publicly states that he will never touch the 21m limit, if he hasn't stated as much already. 

--

You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.

Ivan Brightly

unread,
Aug 18, 2015, 7:35:05 PM8/18/15
to bitco...@googlegroups.com
This statement is not necessary. As I believe the XT/Core split shows, no developers operate in a vacuum -  users/miners/merchants choose which software to run, give feedback and ultimately vote with their feet.

If bitcoin users are worried that a majority of users will push for a change to the 21m cap, no developer oaths will stop that. It only takes a few devs to fork software and offer it up to the community to choose. The answer is to not concern ourselves with this. There is no plausible incentive for the majority of users to push a change and thus it won't happen.

Washington Sanchez

unread,
Aug 18, 2015, 8:59:33 PM8/18/15
to bitcoin-xt
A statement is necessary and articulating exactly what we mean by 'following Satoshi's vision is explicitly required for controversial aspects of the protocol, namely the 21 million cap.

Thus won't prevent a protocol coup by the majority in the future, but it gives confidence to developers in the short and medium term that the cap will never be on the table.

Gavin Andresen

unread,
Aug 18, 2015, 9:08:58 PM8/18/15
to bitcoin-xt
I consider the money supply introduction schedule sacred-- not just the 21 million cap, but also the halves-every-four-years schedule.

Predictability is really important, it should let people make better-informed long-range plans. That's the main reason why I like the BIP101 predictable-for-the-next-20-years max block size....


On Tue, Aug 18, 2015 at 8:59 PM, Washington Sanchez <washingto...@gmail.com> wrote:
A statement is necessary and articulating exactly what we mean by 'following Satoshi's vision is explicitly required for controversial aspects of the protocol, namely the 21 million cap.

Thus won't prevent a protocol coup by the majority in the future, but it gives confidence to developers in the short and medium term that the cap will never be on the table.
--
--
Gavin Andresen  (still on vacation... reading email instead of relaxing....)

Dave Scotese

unread,
Aug 18, 2015, 9:43:45 PM8/18/15
to bitcoin-xt
Perhaps Washington will provide links to discussions where "some in the Bitcoin community [have started] pushing for raising that cap" so that the merits of their arguments can be illuminated.  Fitting with Chris' appropriate comparison of larger blocks vs more bitcoins to gay marriage vs murder, I'd like to point out that capital punishment has been debated in the past, and usually leaves many people with more certainty that murder is wrong and should remain illegal, even for authorities.  In other words, I think that objective evaluation of the "21M is not enough" arguments will strengthen the knowledge and awareness that protects that cap.

So how about it Washington, can you provide any links?

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
I like to provide some work at no charge to prove my value. Do you need a techie? 
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto

Washington Sanchez

unread,
Aug 18, 2015, 10:44:35 PM8/18/15
to bitcoin-xt
Like Gavin, I believe the 21 million cap is sacred, and I think 1 sentence statement to that effect in any sort of XT philosophical manifesto is relatively painless and potentially avoids any distracting arguments in the future.

Evidence:

Ryan Selkis: https://medium.com/crypto-brief/should-21-million-bitcoin-be-the-cap-755b7f02ac4e (note the date)
Jon Matonis: http://cointelegraph.com/news/114648/jon-matonis-the-bitcoin-ecosystem-will-soon-need-a-reference-interest-rate-similar-to-libor

Ryan is known for being controversial, and I don't have any personal issues against him or anything like, but given that he is actively investing into Bitcoin startups and is a vocal commentator in the Bitcoin space, this will not be the last time we hear his perspective on this issue. Jon Matonis needs no introduction.

Washington Sanchez

unread,
Aug 18, 2015, 10:53:31 PM8/18/15
to bitcoin-xt
Point of clarity:

"Of course, I don't want to change the 21 million Bitcoin cap; I'm just saying that in the not-too-distant future someone will attempt it."

If we give Jon the benefit of the doubt regarding the limit, his point in this quote is spot on. A controversial hard forks to change an aspect of the consensus protocol is a dangerous precedent, albeit a necessary one in this case. Larger blocks fits Satoshi's vision, which is why I'm on board. Enshrining what elements of the consensus protocol will never be changed as a guiding doc for XT development is just being philosophically prudent.

Codehalo

unread,
Aug 18, 2015, 11:17:14 PM8/18/15
to bitcoin-xt
Hi Gavin,

As I understand it, Bitcoin has "purely economic constants (as you mentioned below)" and "technical constants". 

As we have seen with the block size debate, it is not too difficult for devs to make technical constants become economical/political.

From your comment, I take it that there are no other pure economic constants, and it is understood that all of the other constants are subject to change to improve Bitcoin whenever the need arises.


-Randi

Dave Scotese

unread,
Aug 19, 2015, 2:11:02 AM8/19/15
to bitcoin-xt
Thanks, Washington.  I think statements are necessary from Jon Matonis and Ryan Selkis, that they have no relationship with any organization that is threatened by bitcoin.

Since they are discussing issues considered sacred by at least one core developer (and probably all of them), this would give confidence to their readers that they aren't planting seeds of discord.

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jerry Chan

unread,
Aug 19, 2015, 5:54:49 AM8/19/15
to bitcoin-xt

What if XT fork is triggered? Is the auto-schedule set off to double every 2 years and unstoppable after that?  If voting is by way of just running and mining on XT, how does one vote to stop the block limit increase AFTER a fork? ( you can't just downgrade after XT has split off)

Leith Marar

unread,
Aug 19, 2015, 7:04:44 AM8/19/15
to bitcoin-xt
Mike

I just wanted to take the opportunity to thank you and Gavin for moving forward with this.

These are great principles which I am sure will garner wide support. The principles go to heart of what the biggest challenge I suspect to bitcoin is,, which is governance and I am sure the block size debate will not be the last major dislocation.  It is going to be fascinating to see how a more open set of principles with, as you say a benevolent dictator evolves.  The beauty of the protocol is it's resistance to anti-democratic behaviour.

I hope yourself, Gavin and whatever other support you have can create a decision making process that reflects the community in general and is robust. 

Jawad Yaqub

unread,
Aug 19, 2015, 3:20:26 PM8/19/15
to bitco...@googlegroups.com
If we could stop the ring-kissing for a moment - this isn't the creation of some new dynastic realm - it's a litmus of whether alternative directions in the heart of bitcoin are acceptable behaviour.

Whatever principles we spray paint onto that are after the fact.

What I am seeing is an appetite for utilitarian changes to BitCoin which further match industry use-cases and make the currency easier to adapt to the mainstream market. 
tumblr_m5lr0vwb1C1qhttpto3_1280.jpg
If that's the case then in the words of Mao - let a hundred flowers bloom.

Jawad

--
You received this message because you are subscribed to a topic in the Google Groups "bitcoin-xt" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoin-xt/irrzfMH_dfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoin-xt+...@googlegroups.com.

Tom Harding

unread,
Aug 19, 2015, 6:40:06 PM8/19/15
to bitco...@googlegroups.com
Jerry --

BIP 101 specifies exactly 10 doublings of the maximum block size, ending
20 years from activation. There is no mechanism built in to allow
increases or decreases in that rate.

Also, another feature of the implementation is not commonly mentioned.
The max size is interpolated, which means that every block has a
slightly larger max size than the last. This way, there is no sudden
change in the max size when a doubling happens.
Reply all
Reply to author
Forward
0 new messages