Hello, I searched the discussion and didn't found info regarding Botanix
I'm trying to deposit testnet3/testnet4 coins into and withdraw back from botanix bitcoin L2
Anyone knows if it's possible or not
Thanks

Attention: haircomber.com domain will cease to be used soon
All business related will move to haircomb.biz
All information related sites will move to haircomb.info
core.haircomber.com -> core.haircomb.biz
test.haircomber.com -> test.haircomb.biz
swap.haircomber.com -> swap.haircomb.biz
api.haircomber.com -> api.haircomb.biz
wiki.haircomber.com -> wiki.haircomb.info

Combfullui 0.5.4 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui/releases

Combdownloader 0.1.9 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases

Combapp 0.1.4 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases

Haircomb docker 0.1.4 released.
https://hub.docker.com/r/haircombs/haircomb

What's new:

* Testnet 4 support

a87dd545ffedea34f87e49d79551acc8180f7a05a2833db542508d776401be85  merlin-layer2.md  (2131 bytes)

https://codeberg.org/watashi564/atomicswap/src/branch/main/roadmap/merlin-layer2.md

We want to list a Merlin L2 / Haircomb trading pairs. Thanks.

Combfullui 0.5.3 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui/releases

Combdownloader 0.1.8 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases

Combapp 0.1.3 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases

Haircomb docker 0.1.3 released.
https://hub.docker.com/r/haircombs/haircomb

All known issues were resolved. Everyone is invited to visit the haircomb wiki at:
https://wiki.haircomber.com

Combfullui 0.5.2 released. Users can upgrade if needed.
Hard fork can be optionally activated by users who are willing to trade.
https://codeberg.org/watashi564/combfullui/releases

Combdownloader 0.1.7 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases

Combapp 0.1.2 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases

Haircomb docker 0.1.2 released.
https://hub.docker.com/r/haircombs/haircomb

All known issues were resolved.

With interest, I read the paper "Bandwidth-Efficient Transaction Relay in Bitcoin" (Erlay Project). It seems quite flawed, and I believe I can offer a better approach.

Let's reconsider full mempool reconciliation. We can train a reconciliation AI model on a CPU. The training times for an ordinary CPU are as follows:

    0.147s for 100 transactions, 100 inner Merkle tree nodes
    3.984s for 1,000 transactions, 1,000 inner Merkle tree nodes
    Very long for 5,000 transactions, 5,000 inner Merkle tree nodes

Now, applying bucketing (sharding by the initial hash byte, which divides the problem into 256 "equal" subproblems) on the same CPU yields:

    0.004s * 256 = 1.024s for 1,000 transactions, 1,000 inner Merkle tree nodes, training 256 models on 8 data points each [48 * 256 bytes model]
    0.029s * 256 = 7.424s for 5,000 transactions, 5,000 inner Merkle tree nodes, training 256 models on 40 data points each [157 * 256 bytes model]
    0.057s * 256 = 14.592s for 10,000 transactions, 10,000 inner Merkle tree nodes, training 256 models on 80 data points each [258 * 256 bytes model]

Surprisingly, it's faster? And it will benefit from future CPU advancements. Maybe mining farms won’t mind?

If Party A sends this 66KB (44KB more realistically) model to Party B, Party B will immediately be able to respond with only the transactions that Party A doesn't have. The best part: notice how the AI model is smaller than a simple vector of hashes? It's about 3x-4x smaller.

Our model (actually, 256 models) will be able to predict the following boolean values based on TX/tree internal node 256-bit hash:

    reconcile(model, hash1) = true // I have this object, and it is a TX hash (Merkle tree leaf). It is NOT a root/inner node.
    reconcile(model, hash2) = true or false // I don't have this object (false positive/false negative)
    reconcile(model, hash3) = false // This object is NOT a TX HASH but a Merkle tree root/inner node hash

Here is the proposed protocol:

    ProtocolPacketUnsolicitedData:
        field: "block_header": raw_header ([80]byte) // Note: contains the Merkle root
        field: "block_height": 814201

    ProtocolPacketReconcileRequest:
        field: "merkle_root": hash
        field: "my_best_model_hash_or_hashes": {model_hash} // Multiple or none, used only by a proxy; otherwise, one
        field: "block_height": 814201

    ProtocolPacketReconcileModelRequest:
        field: "requested_model": model_hash ([32]byte)

    ProtocolPacketReconcileModelResponse:
        field: "model_hash": model_hash ([32]byte)
        field: "model_response": raw_model ([]byte)

    ProtocolPacketReconcileResponse:
        field: "block_height": 814201
        field: "merkle_root": ([32]byte)
        field: "model_hash_vector": {model1_hash, model2_hash} ([][32]byte) // Used only by a proxy; otherwise, empty
        field: "transactions": raw_txs ([][]byte)
        field: "merkle_nodes": raw_inodes_left_right_hashes ([][2][32]byte)

Full node protocol:

    A block is mined by us/new TX signed, and added to the chain/mempool respectively.
    If it’s a block, we send it to everyone using the unsolicited ProtocolPacketUnsolicitedData packet.
    Initialize reconciliation for the just-mined block (height), and perform periodic reconciliation for the next candidate block (height+1).
    When a new reconciliation model (based on Merkle root and nodes) is trained, we send it to all peers via ProtocolPacketReconcileRequest.
    The other party may download it using ProtocolPacketReconcileModelRequest/ProtocolPacketReconcileModelResponse.
    The other party will perform reconciliation and directly send us the objects that we don't have for that specific height/candidate block.

Full node protocol - Handling ProtocolPacketReconcileRequest from another node:

    If the block_height is far in the past or future, ignore it.
    If the known Merkle root is on the chain or known chain branch, ignore it; we already have this.
    If the sender's my_best_model_hash is different, update the my_best_model_hash for this connection and attempt to download the full model using ProtocolPacketReconcileModelRequest.
    Once we have the ProtocolPacketReconcileModelResponse (the full model), determine if this is a mempool reconciliation or a block reconciliation based on the block_height.
    Perform inference on the model and our view of the mempool/on-chain block. For each mempool/on-chain block object:
        For each Merkle internal node, check if the model says the other node thinks it is truly an internal node. If the model is wrong, send the inode object.
        For each transaction hash leaf, check if the model says the other node thinks it is truly a transaction hash leaf. If the model is wrong, send the whole transaction.
    Send the ProtocolPacketReconcileResponse.

Proxy/Relay/Non-reconciliating node protocol - Handling ProtocolPacketReconcileRequest:

    If the block_height is far in the past or future, ignore it.
    If the known Merkle root is on the chain or known chain branch, ignore it; we already have this.
    When a ProtocolPacketReconcileRequest comes in, set the inbound hash for this connection and add the hash to the outbound bag for all other connections.
    Proxy the ProtocolPacketReconcileRequest to all other connections, containing the same block_height, same merkle_root, but their own connection's outbound hash bag set into the my_best_model_hash_or_hashes.

Proxy/Relay/Non-reconciliating node protocol - Handling ProtocolPacketReconcileResponse:

    Determine which objects some peers don't have based on their connection's latest available model for that block height/merkle root.
    Construct a ProtocolPacketReconcileResponse if they made a request before.
    Send the TX data/tree inode data to them.

Proxy/Relay/Non-reconciliating node protocol - Handling ProtocolPacketReconcileModelRequest:

    Identify which connection has the inbound model hash.
    Set up mapping to send the response based on the model hash to whoever requested it.
    Proxy the request to the node that has the inbound model hash, then proxy its response back (and save the response to the connection; this is how the proxy discovers models).

Let's revive this.

I am offering 1 Nat for 1 Wei at https://swap.haircomber.com

Any takers?

Today marks a big day for the evolution of haircomb.

The COMB / Ethereum trading pair is now live on https://swap.haircomber.com/

What this means:

- The hard fork is active on all my nodes. All people who trade should enable it too.
- Someone should verify that the contract works. This is done by trading 1 Nat for 1 Wei.
- After that people who know what they are doing can start initiating larger deals.

People should monitor relevant channels to see if there are any bugs/fixes.

If you don't know how to trade, practice on the testnet.

Combfullui 0.5.1 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui/releases

Combdownloader 0.1.6 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases

Combapp 0.1.1 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases

Haircomb docker 0.1.1 released.
https://hub.docker.com/r/haircombs/haircomb

Combfullui 0.4.1 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.4.0-bugfix/releases


Combdownloader 0.1.2 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases


Combapp 0.0.7 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases


Users can newly install the haircomb full node as a docker container.
https://hub.docker.com/r/haircombs/haircomb

Combfullui 0.4.0 released. Users can upgrade if needed.
https://codeberg.org/watashi564/combfullui-0.3.8-features/releases


Combdownloader 0.1.1 released. Upgrade is optional.
https://codeberg.org/watashi564/combdownloader-ng/releases


Combapp 0.0.6 released. Upgrade is optional.
https://codeberg.org/watashi564/combapp/releases



As always, you can experiment with a live instance:
https://core.haircomb.org

Combapp 0.0.4 available on F-Droid

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/

New in version 0.0.4
CombApp 0.0.4

- New UI on port 21212
- RAM Pruning
- V2 Disk format (downgrade not possible after upgrade)
- Combdownloader 0.0.13
- Haicromb Core 0.3.7

Haircomb Core 0.3.7 available
Combdownloader 0.0.15 available with windows timers fix


Future development and all bitbucket repos will move on to:

https://codeberg.org/watashi564

Haircomb Core 0.3.6 available

https://bitbucket.org/watashi564/combfullui-0.3.5-liqtree/downloads/

Note: To fix bitbucket downloads page, a small bump to 0.3.6.1 was required.
The code for 0.3.6 and 0.3.6.1 is identical.

Combdownloader 0.0.12 available

https://bitbucket.org/watashi564/combdownloader/downloads/

Combapp 0.0.3 available on F-Droid

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/

All known issues are patched in  Haicromb Core patched 0.3.5.1
code here:  https://bitbucket.org/watashi564/combfullui-0.3.4-testnet
Combapp 0.0.2 is available with the fix for android,
 here: https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/
All users must upgrade

I am investigating a security issue, in all versions of haircomb core. The latest git version is believed to be patched.

The attack is that certain commitment orderings could lead to doublespends. The real rule should be that all commitments above the frontier
need to have utxo tag greater than the greatest (most recent) utxo tag on the frontier.

This is true for both haircomb, decider.

I don't know if someone (else) knew about this and could doublespend, if so, the fixed version will siphon the attacker funds out from the economy (if there are any such funds).

Hello. The app release is very good, should run on most phones with armv8.

Get it on F-droid:

https://f-droid.org/en/packages/org.bitbucket.watashi564.combapp/

As mentioned above, there are number of known issues (mainly manifesting on newer phones).

Important:

Future development of haircomb core

I want to integrate accelerators more into haircomb core. I hope to have the current accelerator hash
the user is synced to shown on the main page.

A separate html page will be published that shows the current accelerator hash from the blockchair api. Said page can be hosted on public server etc.

I want to make haircomb core to work on phones with less RAM. Towards that end, we'll try integrating cuckoo filter.

Anyone wants to change something in haircomb core?? Speak up!

Future development of related projects

There are multiple ideas floating around about what to do next, like the accelerator network, about doing the turbine, eternal file etc.
We want to make sure these ideas are well understood but in the end it matters what ecosystem a coin provides, even without quantum computers etc.


So, let's try our best