POW is by design the voting mechanism for the valid chain continuation.
Many rightfully dislike that the same voting mechanism is used on the validity
rules, since ideally
validators (non-mining full nodes), SPV user and even those having an
investment in their cold wallet
would all have a vote.
Security is provided via POW.
POW is only one aspect of security and that algorithm was created by
developers and adopted by miners. Developers provide security by
creating an algorithm and miners provide security by adopting it. If
the developers and miners decided to do something insecure
Security is provided via POW. If you want the chains to stop attacking
each other, change the POW algorithms.
Then it wouldn't matter if one chain was longer than another, each
fork would select the best chain according to their valid version of
POW algorithm.
If Bitcoin Core loses miner majority t
The same with -XT, nobody should be able to affect the entire bitcoin
ecosystem regardless how many miners or bitcoin companies you can lobby.
If this is possible, then Bitcoin is not as secure as we thought.
Bitcoin is only as secure as the developers, users, and miners allow it
to be. If you
On 8/20/2015 1:28 AM, Jorge Timón wrote:
[snip]
>> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
>> just by 2 people forking the software and submitting a consensus rule to
>> a vote, it means Bitcoin is dead already and it should be worthless! We
>> can't go around and p
On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
> Wouldnt the experience for SPV nodes be chaotic? If the full nodes
> are 50:50 XT and bitcoin core, then SPV clients would connect at
> random and because XT and core will diverge immediately after
> activation.
Actually
Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.
Adam
On 19 August 2015 at 15:28, Jorge Timón
wrote:
> On Wed, Aug 19, 2015 at 5:41 PM, s
On Wed, Aug 19, 2015 at 5:41 PM, s7r wrote:
> Hello Jorge, Eric,
>
> With all this noise on the -dev mail list I had to implement application
> level filters so I can treat with priority posts from certain people,
> you are on that list. While I agree with your arguments, I think it is
> _very_ im
Hello Jorge, Eric,
With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
b
On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
wrote:
> I think that it is important to note that Bitcoin XT faces a natural
> uphill battle.
>
> Since it is possible to setup atomic inter-fork coin trades. I do not
> see how Bitcoin XT could possibly win if Satoshi decides to se
On 08/16/15 23:22, Andrew LeCody via bitcoin-dev wrote:
> Cam, your scenario makes no sense.
>
>> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
> string.
>> 2. Encourage all miners to false vote for the Bitcoin XT fork.
>
> This would obliterate any confidence in Bitco
Or can’t you create a transaction that’s still within the op count and sig ops
limits but is larger than 1MB?
> On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev
> wrote:
>
> Wouldn't that require a fork that lasts for more than 100 blocks?
>
> On Mon, Aug 17, 2015, 01:43 Peter Todd
Wouldn't that require a fork that lasts for more than 100 blocks?
On Mon, Aug 17, 2015, 01:43 Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev
wrote:
>There are a few ways: here is my favorite (for the moment).
>
>1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
>'BitcoinXT'
Even more direct: use coin
Since it was a game theory analysis. I will not address your other comments.
On 17/8/2015 7:22 AM, Andrew LeCody wrote:
>> 4. Setup a fork of Bitcoin XT that allows people to easily make a
> transaction only on the XT fork (while leaving the original BTC coins
> untouched).
>
> I doubt this is e
Cam, your scenario makes no sense.
> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
> 2. Encourage all miners to false vote for the Bitcoin XT fork.
This would obliterate any confidence in Bitcoin Core. I seriously doubt
anyone would actually be ok with a pull req
I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 1
XTBTC for BTC everyday for the first 100 days after the fork.
In many wa
[cross-posted to libbitcoin]
I applaud this effort not for the merits of the hard fork but on the
effects of the code fork. We have been witnessing the self-destruction
of Bitcoin's central authority. This is a necessary outcome.
Understandably, many are concerned that if consensus settles on a l
> PS: I consider this attempt at takeover about as foul as it gets. The
equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBer
Hi Adam,
I welcomed XT for its declared focus on usability with current means.
I think there is also more room for non-consenus relevant P2P protocol flavors
than a single code base can accommodate.
XT is also as Jeff just tweeted a relief valve.
It became important, that Bitcoin is able to evol
Hi Tamas
Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
deserving of equal consideration? Just curious because of your post.
Will you be interested to participate in the BIP review process and
perhaps attend the workshop on Bitcoin scaling announced here
recently?
Adam
On 16 Au
Hear hear Tamas,
I agree. I personally prefer to use the "only-bigblocks" branch and not XT
with all its features - but as I am not mining that doesn't mean much
anyhow. Nevertheless I am happy to be able to publicly proclaim my opinion
that the block size should be raised asap.
Thank you for goi
Being a bitcoin software developer an entrepreneur for years I learned that
success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto)
should resonate with many fellow entrepreneurs.
I applaud Mike and Gav
On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Sorry you feel that way. I devoted a big part of the article to trying to
> fairly represent the top 3 arguments made, but ultimately I can't link to a
> clear statement of what Bitcoin Core th
Hi Eric,
Sorry you feel that way. I devoted a big part of the article to trying to
fairly represent the top 3 arguments made, but ultimately I can't link to a
clear statement of what Bitcoin Core thinks because there isn't one. Some
people think the block size should increase, but not now, or not
If someone is surprised with Mike Hearn's antics, I recommend taking a few
minutes to watch this video from 2 months ago:
https://www.youtube.com/watch?v=DB9goUDBAR0
Mike Hearn's "Worst Case" XT Fork Scenario: Checkpoints, Ignore Longest
Chain.
___
bitc
Baseless accusations also have no place on this mailing list. They are
unprofessional, and poisonous to the consensus-building process we all
seek to engage in.
I didn't see any baseless accusations in the message. I saw a
discussion of possible conflicts of interest. Your reply seems to
ind
Let's start with the definition of a conflict of interest before we go any
further:
A *conflict of interest* (COI) is a situation in which a person or
organization is involved in multiple interests (financial, emotional, or
otherwise), one of which could possibly corrupt the motivation of the
indiv
Baseless accusations also have no place on this mailing list. They are
unprofessional, and poisonous to the consensus-building process we all seek
to engage in.
The Lightning Network effort at Blockstream is purposefully structured to
avoid any conflict of interest. ALL code related to lightning i
Bitcoin has no elections; it has no courts. If not through attempting a
hard-fork, how should we properly resolve irreconcilable disagreements?
On Sat, Aug 15, 2015 at 6:07 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Please take the lightning 101 discussion
Please take the lightning 101 discussion to another thread.
The main point I was trying to make was that Mike is clearly misrepresenting
the views of a great number of people who have deep, intimate knowledge of how
things work and are almost certainly not primarily motivated by their own
poten
Being an early hub provider would be an obvious place to start capitalizing
on lightning. Early lightning adopters would be in the best position to do
this.
Long term, Bitcoin needs to scale the blockchain in a reasonable manner and
implement things like lightning.
Limiting the blocksize is a bla
I would like very much to know how it is that we're supposed to be making
money off of lightning, and therefore how it represents a conflict of
interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.
We are working on lightning b
I posted this to /r/BitcoinMarkets but I thought I might post it here as
well.
---
Currently 0 mined blocks have voted for XT.
If it ever gets close to even 50%, many things can happen that would
reshape the game completely.
For instance:
- Core could start boycotting XT by not relying to them
I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological in
"I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic."
As a developer on the side lines, bitcoin holder, bitcoin entrepreneur, and
someone who thinks block size limits should be dynam
> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev
> wrote:
>
> What are you so afraid of, Eric? If Mike's fork is successful, consensus is
> reached around larger blocks. If it is rejected, the status quo will remain
> for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the o
What are you so afraid of, Eric? If Mike's fork is successful, consensus is
reached around larger blocks. If it is rejected, the status quo will remain
for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the only thing
that matters, and those that go against network consensus will be sever
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from a
great number of people who have published and posted a number of articles
detailing an explaining in-depth technical concerns…you also seem to fancy
yourself more capable of reading into
You may be misremembering; nobody has ever disagreed that you can fork a
source code repository. Perhaps you are thinking instead about the
concerns regarding "asymmetric" rule incompatibilities?
I am not "misremembering" anything. Some people have claimed for years
that Bitcoin development is
If this proposal has less than half of the total hashpower (or is it even
less than 75%? Haven't quite thought it through completely) supporting it,
I can see the following happening if the sum of supporters and people who
want to screw the supporters out of money is at least 75%:
Non-supporters cr
On Sat, Aug 15, 2015 at 3:36 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> These are the people who used to run around saying that Bitcoin
> development is "decentralized" because anyone can fork the code and now
> many of the same people claim a fork will des
So if you want a user vote, that's an issue that'd have to be tackled:
the people who admin the main communication channels Bitcoin users have
vowed to censor any program that doesn't slavishly follow 51%+ hash
power. That attempt to control the conversation is certainly not
libertarian or democra
>
> I use bitcoin heavily (not from time to time) but I don't mine - can I
> vote? The way I see it I cannot, and I am not saying it is a bad thing,
> but I missed the argument explaining why users don't matter and only
> miners do.
>
It is a reasonable question. Let me try and explain why it's do
Fair enough, this is what open source is all about. Good things
sometimes come out of controversial actions. I briefly read the
manifesto, saw the migration plan, it is not that greedy and in theory
it is possible to migrate safely with no (big) incidents.
What seams a little bit unfair is that on
On 8/15/2015 8:02 PM, Mike Hearn via bitcoin-dev wrote:
>
> I say to all developers on this list: if you also feel that Core is no
> longer serving the interests of Bitcoin users, come join us. We don't bite.
>
Bwhahahahahahahhahahahahah
___
bitcoin-de
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many oth
47 matches
Mail list logo
