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
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
bitcoin-dev@lists.linuxfoundation.org
On Wed, Aug 19, 2015 at 5:41 PM, s7r s...@sky-ip.org 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
On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org 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
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 Bitcoin Core.
Wouldn't that require a fork that lasts for more than 100 blocks?
On Mon, Aug 17, 2015, 01:43 Peter Todd p...@petertodd.org 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
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
bitcoin-dev@lists.linuxfoundation.org wrote:
Wouldn't that require a fork that lasts for more than 100 blocks?
On Mon,
-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:
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
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
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 thinks
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
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
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
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
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 even
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
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 8MBers
[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
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
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
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
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.
___
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
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
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
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
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
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
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
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
32 matches
Mail list logo
