Bitcoin Forum

It is hard work to rectify all the lies that XT shills keep spreading in this coordinated attack against Bitcoin.

Stop XT!

Obvious paid trolls are obvious. Let them spread their NSACoin shilling. Actually don't let them. I hate how they are trying to push XT. The 30 day spam attack is yet another obvious move of Hearncoin and friends.

BIP101 is what XT is all about. The point is, if Core does't implement BIP101 than XT is the way to go.

Besides BIP101, XT has shady features that help de-anonymizing people. Why didn't you mention this fact as well ?

It seems knight22 and a few new alts are the only people who push XT fork on the forum.
The most of hero/legendary people are against.

I'm pushing for BIP101. XT or Core I don't give a damn. I want bitcoin to scale. The blacklisting thing is just an OPTIONAL Ddos protection. Stop with all that paranoid FUD.

The blacklisting thing is just an OPTIONAL Ddos protection. Stop with all that paranoid FUD.

So please stop mentioning XP in your topics. BIP101 is not equal to XT.

Yes, this leaves an option for NSA/CIA to start attack in order to de-anonymize all the Tor users.

BIP101 is what XT is all about. The point is, if Core does't implement BIP101 than XT is the way to go.

The point is why bitcoin core is not making the necessary changes to make this more efficient

XT is the only implementation that support BIP101 right now so be it.

How so?

Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime metrics
from bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will
cause them to make a new request to the blacklist endpoint via the
clearnet on relaunch at the same time their P2P connections are made
through a proxy. Requests to the blacklisting URL also use a custom
Bitcoin XT user agent which makes users distinct from other internet
traffic if you have access to the endpoints logs.

It is hard work to rectify all the lies that XT shills keep spreading in this coordinated attack against Bitcoin.

Stop XT!

Already have there been dubious code segments detected in XT's code base. XT is a trojan horse that plans to base it's hostile takeover of Bitcoin on manipulating the notoriously stupid masses.

I for one will dump ALL my Bitcoins immediately on the XT chain, should it ever be tradeable, which will certainly not be without effect. Bitcoin simply cannot be in control of two people with very questionable motives and tactics. It is a tool of the cypherpunks

How are developers responding to this severe limitation of Bitcoin's usage. There are currently 72000 (!) unconfirmed transactions but it seems they don't really want to acknowledge it.

Perhaps set a limit of tx/s to discourage spamming the mempool and block malicious nodes.

BIP101 is what XT is all about. The point is, if Core does't implement BIP101 than XT is the way to go.

There will not be a hard fork until January 2016 at the earliest. BIP 101 patch can be implemented in Bitcoin Core as well, and I hope it is and soon. What bothers me is that Mike Hearn used his commit privileges to publish Bitcoin XT with only a 75% adoption threshold by miners. Hard forks are dangerous, and the threshold for adoption should have been 90% or even safer 95%. I suspect he set the threshold too low because he realized chances of 90% consensus approval for Bitcoin XT was slim.

Yet... They released it without waiting for consensus. It can be treated as just another altcoin fork.



This:
source: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010379.html

So I checked, and the code described *does not* run when behind a
proxy of any kind, including tor:

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23#diff-11780fa178b655146cb414161c635219R265

At least based on my admittedly weak understanding of how the internal works.

Hopefully I save the next reader of your post from also having to dig
around to find the code and realize this is a false alert.

On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Jumping from 1mb to 8mb wont solve the problem. It'll just delay it. After a few years, the controversy will pop again, but with increased adoption, it'd be harder to control. In my opinion, the most logical solution so far to the block size controversy is BIP 106 (https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki).

BIP106 does not solve a simple solution, network tx capacity. Its a complex solution with uncertainty. If the blocksize limit can be set dynamically in an efficient way. We should not have the limit at all.

Ppl generally confuse between the network difficulty which is a "target" and blocksize limit which is a "capacity". The BIP106 is a perfect example of this misunderstanding.
 

Jumping from 1mb to 8mb wont solve the problem. It'll just delay it. After a few years, the controversy will pop again, but with increased adoption, it'd be harder to control. In my opinion, the most logical solution so far to the block size controversy is BIP 106 (https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki).

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

OpenSSL has been open source for years and years and years...

This is a good point. The simple fact that anyone CAN check the source code and find critical bugs is, as the openssl clusterfuck showed, not a sufficient guarantee that enough competent people WILL check the source code and find critical bugs.

Of course, that caveat applies equally well to both XT and Core.

Your mempool limiting technique creates a cheap network bandwidth DoS attack.

The problem is Gavin's patch evicts random transactions (and their descendants) from the mempool without regard to what fees anything paid; in Bitcoin we use paying fees to limit DoS attacks, so anytime a transaction can be broadcast without having a high probability of eventually paying the fee is very bad. Evicted transactions aren't recorded, so if a peer rebroadcasts them to you you'll redownload them. Equally that makes up a bunch of space for different rebroadcasted transactions respending UTXO's that were previously spent. Either way, bandwidth is being used that isn't being paid for.

This is all very well known stuff, and dealing with it is most of the reason why Core is actively working towards implementing a mempool sorted by fees. That you quickly merged Gavin's patch is a sign you don't have much peer review, given that a multiple simpler, working, alternatives exist if you just want something fast to implement. (e.g. the feerate tier idea discussed on IRC/github)

Because raising the blocksize while there is a huuge gap of unused mb's raises tons of exploits and problems, thats why raising the blocksize is such an huge debate.
Bitpay fucked up big time  anyway, im not taking these guys serious anymore and I don't like a third party to deal with my transactions.

This is a good point. The simple fact that anyone CAN check the source code and find critical bugs is, as the openssl clusterfuck showed, not a sufficient guarantee that enough competent people WILL check the source code and find critical bugs.

Of course, that caveat applies equally well to both XT and Core.

Bitpay's opinion may no longer be relevant pretty soon.

Gavin has said repeatedly that Bitpay's opinion is paramount and takes precedence over the mining majority and users. In his mind, Bitpay (along with Coinbase) IS God.