-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
Thanks to mining centralization, such attempts won't be successful.
Asking mining pools to mine spoofing blocks in their real name is even
harder than asking them to run the real BitcoinXT
Node count is always manipulable, there is nothing new. People running
this will only be interpreted as X
Announcing Not-BitcoinXT
https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
-
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No b
The first question to answer here is simple:
What value would there be in requiring a minimum block size?
I see no value.
On 08/16/2015 05:30 PM, Jeff Garzik via bitcoin-dev wrote:
> "minimum" an interesting topic.
>
> - Traffic levels may not produce a minimum size block
> - Miners can always c
"minimum" an interesting topic.
- Traffic levels may not produce a minimum size block
- Miners can always collude to produce a lowered maximum block size, a sort
of minimum maximum
On Sun, Aug 16, 2015 at 12:41 PM, Levin Keller via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
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
Levin, it is a complicated issue for which there isn't an easy answer. Part
of the issue is that "block size" doesn't actually measure resource usage
very reliably. It is possible to support a much higher volume of typical
usage transactions than transactions specifically constructed to cause DoS
i
Hey everyone,
as with the current "max block size" debate I was wondering: Is anyone here
in favor of a minimum block size (say 2 MB or so)? If so I would be
interested in an exchange (maybe off-list) of ideas. I am in favor of a
lower limit and am giving it quite a bit of thought at the moment.
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
On Sun, Aug 16, 2015 at 9:46 AM, xor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hey folks,
>
> so you've been stressed with arguing about what to do with the block size
> for
> months now :(
>
> Why not realize that the unfruitful permanent need for administrators to
> tweak
Hey folks,
so you've been stressed with arguing about what to do with the block size for
months now :(
Why not realize that the unfruitful permanent need for administrators to tweak
a magical, god-given (= Satoshi-given) constant is a *strong* indicator for
something which should be delegated
20 matches
Mail list logo
