Interesting non-altcoin forks?

[arnuschky]

Hey,

one thing that bugs me about github is that it's quite hard to keep track of forks - there's no description to the fork itself, it appears. So if one would like to explore useful alternative trees, it's quite difficult to do so! (not talking altcoins here - pure bitcoin). For example, in Linux there are some known trees used for integrating new functionality or proposed drivers etc.

Is there an equivalent for bitcoin? For example, is there some sort of index for "best of github bitcoin forks"?

[1715692973]

1715692973

[1715692973]

1715692973

[1715692973]

1715692973

[fsb4000]

Altcoins.
Then a successful functionality merge in Bitcoin 

[coinpr0n]

Not forks, but I think related: BitcoinJ is a Java Bitcoin library and there is also a full-node Bitcoin implementation written in Go.

[krigger]

Not forks, but I think related: BitcoinJ is a Java Bitcoin library and there is also a full-node Bitcoin implementation written in Go.

I agree with this. Java Bitcoin library indeed.
It is compatible with Python, Ruby and Clojure running on a JVM.
People work on this hard to make something good. And it is good, but the question is the usage of it.

[coinpr0n]

Not forks, but I think related: BitcoinJ is a Java Bitcoin library and there is also a full-node Bitcoin implementation written in Go.

I agree with this. Java Bitcoin library indeed.
It is compatible with Python, Ruby and Clojure running on a JVM.
People work on this hard to make something good. And it is good, but the question is the usage of it.

I use BitcoinJ quite a bit. I like it. It's very powerful and convenient.

[arnuschky]

Not forks, but I think related: BitcoinJ is a Java Bitcoin library and there is also a full-node Bitcoin implementation written in Go.

I agree with this. Java Bitcoin library indeed.
It is compatible with Python, Ruby and Clojure running on a JVM.
People work on this hard to make something good. And it is good, but the question is the usage of it.

I use BitcoinJ quite a bit. I like it. It's very powerful and convenient.

I use mostly python; does anyone has experience with BitcoinJ's python bindings?

Regarding my original question: I mostly wanted to know about interesting extensions to the original code (and no, not altcoins). For example, I only recently learned about this PR to prune bitcoin core's wallet: https://github.com/bitcoin/bitcoin/pull/5389

Which caused me to wonder what other interesting PR's are out there...

[arnuschky]

Interesting tree: Peter Todd's replace-by-fee fork.

https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4

What's replace-by-fee?
----------------------

Currently most Bitcoin nodes accept the first transaction they see
spending an output to the mempool; all later transactions are rejected.
Replace-by-fee changes this behavior to accept the transaction paying
the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
children are also considered - a chain of transactions is only replaced
if the replacement has a higher fee than the sum of all replaced
transactions.

Doing this aligns standard node behavior with miner incentives: earn the
most amount of money per block. It also makes for a more efficient
transaction fee marketplace, as transactions that are "stuck" due to bad
fee estimates can be "unstuck" by double-spending them with higher
paying versions of themselves. With scorched-earth techniques⁵ it gives
a path to making zeroconf transactions economically secure by relying on
economic incentives, rather than "honesty" and alturism, in the same way
Bitcoin mining itself relies on incentives rather than "honesty" and
alturism.

Finally for miners adopting replace-by-fee avoids the development of an
ecosystem that relies heavily on large miners punishing smaller ones for
misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
attack miners who include doublespends in their blocks - an unavoidable
consequence of imperfect p2p networking in a decentralized system - or
even Hearn's proposal⁷ that a majority of miners be able to vote to
confiscate the earnings of the minority and redistribute them at will.

[btchris]

Interesting tree: Peter Todd's replace-by-fee fork.

Interesting, and also quite controversial

A (slightly related) interesting fork: Tom Harding's Double-Spend Relay and Alerts. It actually made it into Bitcoin Core's master for a short while before being reverted (which I think is a shame; he put a lot of work into it and it had at least some chance of being very useful, but there were some legitimate concerns as well).

Double-Spend Relay and Alerts
VERY IMPORTANT: It has never been safe, and remains unsafe, to rely
on unconfirmed transactions.

Relay
When an attempt is seen on the network to spend the same unspent funds
more than once, it is no longer ignored.  Instead, it is broadcast, to
serve as an alert.  This broadcast is subject to protections against
denial-of-service attacks.

Wallets and other bitcoin services should alert their users to
double-spends that affect them.  Merchants and other users may have
enough time to withhold goods or services when payment becomes
uncertain, until confirmation.

Bitcoin Core Wallet Alerts
The Bitcoin Core wallet now makes respend attempts visible in several
ways.

If you are online, and a respend affecting one of your wallet
transactions is seen, a notification is immediately issued to the
command registered with `-respendnotify=<cmd>`.  Additionally, if
using the GUI:
 - An alert box is immediately displayed.
 - The affected wallet transaction is highlighted in red until it is
   confirmed (and it may never be confirmed).

A `respendsobserved` array is added to `gettransaction`, `listtransactions`,
and `listsinceblock` RPC results.

Warning
If you rely on an unconfirmed transaction, these changes do VERY
LITTLE to protect you from a malicious double-spend, because:

 - You may learn about the respend too late to avoid doing whatever
   you were being paid for.
 - Using other relay rules, a double-spender can craft the double-
   spend to resist broadcast.
 - Miners can choose which conflicting spend to confirm, and some
   miners may not confirm the first acceptable spend they see.

[coinpr0n]

Not forks, but I think related: BitcoinJ is a Java Bitcoin library and there is also a full-node Bitcoin implementation written in Go.

I agree with this. Java Bitcoin library indeed.
It is compatible with Python, Ruby and Clojure running on a JVM.
People work on this hard to make something good. And it is good, but the question is the usage of it.

I use BitcoinJ quite a bit. I like it. It's very powerful and convenient.

I use mostly python; does anyone has experience with BitcoinJ's python bindings?

Regarding my original question: I mostly wanted to know about interesting extensions to the original code (and no, not altcoins). For example, I only recently learned about this PR to prune bitcoin core's wallet: https://github.com/bitcoin/bitcoin/pull/5389

Which caused me to wonder what other interesting PR's are out there...

Python seems to be one of the more used languages for working with Bitcoin. I've seen lots of useful scripts made to interact with Bitcoin concepts using Python (I think Vitalik and Peter Todd have some tools on their GitHub pages).

[hhanh00]

For me, the most important one is the UTXO commitments proposal but I have no idea what its status is.

[arnuschky]

Interesting tree: Peter Todd's replace-by-fee fork.

Interesting, and also quite controversial

Indeed. However, I think it makes sense and would solve the double-spending problem quite nicely - maybe the only solution there is.

A (slightly related) interesting fork: Tom Harding's Double-Spend Relay and Alerts. It actually made it into Bitcoin Core's master for a short while before being reverted (which I think is a shame; he put a lot of work into it and it had at least some chance of being very useful, but there were some legitimate concerns as well).

Awesome! That is the kind of info I was fishing for. Thanks for sharing. I guess I'll give it a try soon, might be interesting to see what's happening on the network (and it's always worth measuring yourself, as blockchain.info is broken in so many ways...)

[arnuschky]

For me, the most important one is the UTXO commitments proposal but I have no idea what its status is.

You got a link or the lead dev's name?

[Exther2]

I don't like forks.
They are just clones with add-on's.
Nothing special is when they rename it, use a source which they are not made and then add some salt in it.
It's a stealing of coin to make something "new".
Not worth of mention or use anyway as it cannot stay long alive and to be usable.
Making something new from the bottom is the real thing and I support only that.
The original idea, not stolen one.

[fsb4000]

use a source which they are not made

Actually this is not true. You can see https://github.com/bitcoin/bitcoin/graphs/contributors and then look at other projects of the contributors. Many contributors have own coins.

Making something new from the bottom is the real thing and I support only that.

So you don't support Linux, LibreOffice and almost all opensource projects, do you?

[gmaxwell]

Many contributors have own coins.

I believe that is incorrect. The only non-trivial contributions that I can think of there is jtimon (freicoin).

[btchris]

Nothing special is when they rename it, use a source which they are not made and then add some salt in it.

OP specifically said he wasn't interested in altcoins, but in interesting forks which haven't been merged into Bitcoin (and presumably have some chance of being merged in the future):

Regarding my original question: I mostly wanted to know about interesting extensions to the original code (and no, not altcoins).

Read the whole thread... the referenced forks are interesting.

Making something new from the bottom is the real thing and I support only that.
The original idea, not stolen one.

If Satoshi had agreed with that point of view, it seems unlikely he would have released Bitcoin under the MIT License. 'Course it's hard to disagree with your sentiment regarding the quality of most altcoins....

[gmaxwell]

If Satoshi had agreed with that point of view, it seems unlikely he would have released Bitcoin under the MIT License. 'Course it's hard to disagree with your sentiment regarding the quality of most altcoins....

Any other choice would be giving the copyright holders of the software an elevated level of authority over the system, which would defeat the point-- even if it would be arguably desirable. Besides, it isn't like anonymous parties have tremendous recourse available via civil complaints; plus 99% of altcoins don't care: The MIT license required basically nothing but preserving copyright notices and most altcoins actually violate the license (because they search and replace out all the attribution).

[fsb4000]

Many contributors have own coins.

I believe that is incorrect. The only non-trivial contributions that I can think of there is jtimon (freicoin).

a few examples:
https://github.com/bitcoin/bitcoin/commits?author=dooglus - https://github.com/nochowderforyou/clams
https://github.com/bitcoin/bitcoin/commits?author=domob1812 - https://github.com/namecoin/namecore
https://github.com/bitcoin/bitcoin/commits?author=wtogami - https://github.com/litecoin-project/litecoin

[arnuschky]

Here's another interesting fork I came across when reading about scorched earth/replace-by-fee (see first fork mentioned in this thread).

Bitcoin XT, by Mike Hearn:

Bitcoin XT is a patch set on top of Bitcoin Core, with a focus on upgrades to the peer to peer protocol. By running it you can opt in to providing the Bitcoin network with additional services beyond what Bitcoin Core nodes provide. Currently it contains two additional features:

• Relaying of double spends. Bitcoin Core will simply drop unconfirmed transactions that double spend other unconfirmed transactions, forcing merchants who want to know about them to connect to thousands of nodes in the hope of spotting them. This is unreliable, wastes resources and isn't feasible on mobile devices. Bitcoin XT will relay the first observed double spend of a transaction. Additionally, it will highlight it in red in the user interface. Other wallets also have the opportunity to use the new information to alert the user that there is a fraud attempt against them.
• Support for querying the UTXO set given an outpoint. This is useful for apps that use partial transactions, such as the Lighthouse crowdfunding app. The feature allows a client to check that a partial SIGHASH_ANYONECANPAY transaction is correctly signed and by querying multiple nodes, build up some confidence that the output is not already spent.

Bitcoin XT is more experimental than Bitcoin Core, and has a strong emphasis on supporting the needs of app developers and merchants. By running it you not only provide additional services to the network but help build confidence in the implementations, contributing towards consensus for inclusion in a future version of Bitcoin Core.

https://github.com/bitcoinxt/bitcoinxt

[Cryddit]

Something that I've wished for in Bitcoin core itself the last few days is an option to monitor the size ( in both transactions and kilobytes) of the memory pool of unconfirmed transactions.  I've been seeing it get up to 3000 or so and staying there for hours during the last few days, while some miners continue to turn in tiny 60k blocks that have a few dozen transactions at most.  

It's a perverse-incentives problem.  Some miners are in such stark fear of an orphaned block that they're not processing transactions, and I think that having the ability to at least monitor that situation (outside of blockchain.org) would be a really good addition to the core.  It may turn out that we need to do more. 

I'd like to see a patch to the most-work rule that breaks equal-work ties by how much a proposed block reduces the transaction pool rather than by the order in which it was received.  But that would be risky in a few ways; it would lead to more rather than fewer orphaned blocks, and provide a new way for an attacker to cause a short-term fork.  And it would be a potential compute-time DoS, because you'd have to process all the blocks that are now "orphans" a lot more intensively to find out whether to replace your current chain tip.   So that's an experiment that needs tried out in an alt, long before it becomes a serious proposal for Bitcoin itself.