Pages:
Author

Topic: Competing nodes - List of BTC implementations in competition for the Blockchain - page 2. (Read 4499 times)

copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.

Any idea why they didnt enable the chainstate obfuscation? AFAIK its only used to avoid false positives from anti virus software.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
staff
Activity: 4270
Merit: 1209
I support freedom of choice
@Jet Cash

This site checks the number of nodes by counting many as only one per IP address
http://coin.dance/nodes
legendary
Activity: 2814
Merit: 2472
https://JetCash.com
The site NodeCounter.com shows some of the options and their growth.

That count increase for Classic seems to be counter-intuitive given that Core 0.12.0 has just been released, also the classic users in my (small) peer list seem to have dropped out. It leads me to believe that the stats are being manipulated to try to force a destructive change onto Bitcoin.
legendary
Activity: 2282
Merit: 1023
It seems like people come and go and left behind works for different versions...

However, this is almost the "once in a life time" moment when we witness the evolution of bitcoin and the blockchain technology itself in real life implementation.
legendary
Activity: 1442
Merit: 1001
Who are these people that are still working on XT? I mean, do you know their names (I can see the commits myself)? Looks like they enjoy wasting their free time.

https://groups.google.com/forum/#!topic/bitcoin-xt/FCdTN1oKbkY

Quote
Bitcoin XT Release 0.11.0E has been tagged.  Binaries are not yet available.

This release includes a bunch of work that was done before Mike Hearn moved on.  In particular, Dagur Johannsson has finished the block download acceleration that Mike started.
Thin blocks fast block downloading, enabled by default
Supports and votes for 2MB hard fork (identical to Classic).  BIP101 reverted.
Switch to secp256k1 custom bitcoin ECC library
Random mempool eviction reverted, low-fee txes evicted when mempool full
Mempool expiration at 72 hours (identical to Core)
Configurable user-agent comment
Display coinjoins better in GUI wallet
LevelDB anti-corruption fix (Windows platforms)
Gracefully handle migration from obfuscated (Core v0.12) chainstate
Thin blocks is simply block download acceleration.  It works without requiring changes to your peers' software.  You will become a source of faster blocks and contribute to faster confirmation times for the bitcoin network, so keep an eye on your upload bandwith usage.

Any future that Bitcoin XT has beyond this release depends totally on your interest and contributions.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Who are these people that are still working on XT? I mean, do you know their names (I can see the commits myself)? Looks like they enjoy wasting their free time.
With a little look on issues/pr I see these names:
https://github.com/dagurval
https://github.com/dgenr8
https://github.com/MarcoFalke

Maybe there are others, time and incentives can be subjective.

Anyway, they can still take other code from other forks as Classic, Core or Unlimited.
legendary
Activity: 2674
Merit: 2965
Terminated.
Who are these people that are still working on XT? I mean, do you know their names (I can see the commits myself)? Looks like they enjoy wasting their free time.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Added two implementations

Haskoin (new implementation in Haskell)
Code: https://github.com/haskoin/haskoin

Libbitcoin (new implementation in C++)
Site: https://libbitcoin.org
Code: https://github.com/libbitcoin/libbitcoin


I'll give you updates about new versions of all these listed implementations.
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Fairly certain that bitcore: https://bitcore.io/ is a full node software as well.
I added and then removed Bitcore.

Quote
“Bitcore has bitcoind built right in, so joining the peer-to-peer network is simple.”
Quote
Bitcore is a full bitcoin node — your apps run directly on the peer-to-peer network. By binding directly into bitcoind's source code, Bitcore's API is 20x faster than connecting to a separate bitcoin node, and orders of magnitude faster than a centralized API.

So it is exactly a Bitcoin Core daemon, same code, same rules.
legendary
Activity: 1442
Merit: 1001

it's equivalent of 1.75 mega at minimu, and it can be expanded to be above 2MB, and anyway 2mb, is a temporary step toward the issue, so having 1.75 or 2mb will not change anything

in case tere will be a saturation of the 2mb limit, having 1.75 will suffice with a little delay on the transaction, much better than what happened with the stress test

Huh? SW cannot get more than a 1.75x increase on its own. I'm unaware of any on-chain throughput increases that can be had as a soft fork, other than the SW accounting trick.

1) We have no idea when SW will be ready for release. It's over 500 lines of code that need to be reviewed, very much unlike a max block size increase.
2) We have no idea when most wallets will be ready to accommodate SW.
3) We don't really know whether miners will charge lower fees for SW transactions and theoretically incentivize users to upgrade and start using SW transactions rather than typical transactions.

I'm a big fan of some of the features that SW brings, but it's not a sure bet that this has any effect on throughput in 2016. Even if it does, the number of daily transactions has been growing quickly enough that we'll need a 2017 solution as well, and this brings up the 2MB + SW block size increase. There's a reason that miners aren't jumping on board SW alone.
staff
Activity: 3458
Merit: 6793
Just writing some code
Fairly certain that bitcore: https://bitcore.io/ is a full node software as well.
legendary
Activity: 3248
Merit: 1070
i'm fairly certain that none of those will get any real consensus besides core,

core is aiming as well to increase the limit to 2mb, so the other are obsolete

they seems like a way, for some dev to say " this version is mine, i made it..."

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

(deleted image - waiting for a better miner representation)

https://bitcoin.org/en/bitcoin-core/capacity-increases-faq, they want to do it via segregate witness

At best, that's a 1.7M block size equivalent. The miners supporting 2M blocks via Classic are well aware of SW. I'm also very supportive of SW although less so for the accounting trick scalability increase and more so for the new scripting features and malleability fix. Back to my original point, no Core does not support a 2M block size via HF which is what miners (among others) are now pushing for.
it's equivalent of 1.75 mega at minimum, and it can be expanded to be above 2MB, and anyway 2mb, is a temporary step toward the issue, so having 1.75 or 2mb will not change anything

in case tere will be a saturation of the 2mb limit, having 1.75 will suffice with a little delay on the transaction, much better than what happened with the stress test
staff
Activity: 4270
Merit: 1209
I support freedom of choice
thx for making this HostFat, i think that is a valuable summary. is theymos allowing that these days?  Roll Eyes
I hope so, but please avoid this argument here now.
legendary
Activity: 1148
Merit: 1014
In Satoshi I Trust
thx for making this HostFat, i think that is a valuable summary. is theymos allowing that these days?  Roll Eyes
staff
Activity: 4270
Merit: 1209
I support freedom of choice
@shorena
Added.


Fair enough - I searched and wasn't able to find F2Pool thoughts on Classic. Edited my original post - there's enough other pools that support Classic at this point, it's not to be ignored.

https://bitcointalksearch.org/topic/m.13571787
Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.
Pages:
Jump to: