Bitcoin Forum
July 08, 2025, 07:49:29 PM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Alternate cryptocurrencies / Altcoin Discussion / Botanix bridge on: June 05, 2025, 07:33:13 PM
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
2  Bitcoin / Development & Technical Discussion / Erlay looks flawed to me - a superior Invitation-less bitcoin protocol proposal on: July 30, 2024, 02:37:06 PM
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).
3  Bitcoin / Development & Technical Discussion / OP_MERKLE (an alternative to OP_CAT, SHASTREAM, SUBSTRING) on: December 21, 2021, 02:08:59 AM
I think a sha256 operation in bitcoin script that took two operands would fill all the requirements for substring (ignoring sha256 collision).

OP_MEKLE(a, b) = SHA256(a OP_CAT b)

Proving substrings using OP_MERKLE

We assume there are no sha256 collisions. If we validate in script, that:

OP_MERKLE(x,y) = SHA256(z)

Then we can be sure that x is a prefix of z, and y is a suffix of z. If z is constant, sha calculation can be amortized.

Proving substring checking can be of course done recursively, to prove even smaller substrings.

I wonder if Eltoo or covenants are somehow made easier using this.
4  Bitcoin / Development & Technical Discussion / chainsplit proofs in reverse analysis on: October 03, 2018, 06:15:10 PM
The idea is to reverse the flow of time.
If we can prove that both cores computing in reverse reach the same state (ie arbitrary split network can be reversibly unified) we proved that there exists blocks that can split network.

Let's hunt for consensus bugs using this method!

We start with a network of two split Bitcoin Core nodes (two different versions) and a three miners (so that no one has 51% when chainspilt is trivial).

GOAL: calculate in reverse what happens until we reach some unified network block (a block in set "a" in picrure below)


X     Y
\      /
 b   c
  \ /
   |
   a
   |
 


The miner schedule is generated, each miner takes 30min on average. it is a sequence of timestamps when blocks were "mined". The segment b cointains only blocks (actually timestamps) from miner #1, the segment c contains only timestamps from miner no. #2 and miner #3 blocks. The segment "a" contains blocks (timestamps) from all three miners.

To every copy of block, a boolean attribute is also added whether the block is other node relayed or miner relayed.

Next lets focus on the oldest block (chaintip) which must be unvalidated and unmined.
If it's miner relayed, it is unvalidated and sent back to miner. Miner serves as a sink and saves blocks it recieves to disk.
If it's node relayed it is either on one node, or on both nodes.
If it's on one node the other node must have rejected it. This rejection is simulated in reverse, meaning the node who does not have it internally simulates the reason for rejection, then sends it to node who has it. The node who has it then unvalidates it and sends it to miner for storage.

If it's node relayed and on both nodes the unvalidation by late node, sending to early node, receiving (unsending) by early node, unvalidating by early node, and sending to miner is performed.

Blocks are also popped from blockchains.

Actually node X is the minority node so it is rejecting all blocks from set c.

5  Bitcoin / Project Development / New blockchain consensus algorithm - "collect partition vote 3sat"- ANONYMOUS on: June 26, 2018, 06:53:22 PM
It is thought that a consensus on who receives coin can be reached via a numerical method. The mechanism is completely zero knowledge - no knowledge to who sends coin to who is revealed.

A large set of candidate creditors is collected into a merkle tree by a miner (collect)

Creditors and debitors pubkeys are shuffled by a miner into two sets (partition).

Creditors vote bit by bit on in which partition their debitors are, and debitors vote bit by bit where the creditors are (vote).

Miners solve the system of linear equations, to determine the set of  which creditors just received a coin (matrix).

If a solution is found (the set of creditors is solved) creditors are credited coins and all debitors are debited a coin (goto collect).

Otherwise the next shuffling - voting - solving round occurs (goto partition)

As you can see there is no relationship who send coin to whom, it's like a full coinjoin (like mimblewimble).

Another advantage all public keys own exactly 0 or 1 coins, so there is anonymity for amounts.

But it's far from completion.
6  Bitcoin / Development & Technical Discussion / User Activated Nuke Transactions - 3 steps to defeat S2X on: October 28, 2017, 11:59:45 AM
Here is how 2x chain can be effectively destroyed  Grin

As an user, do the following

1. Wait until the fork block is mined
2. Two way split all your coins.
3. Send all your S2X shitcoin to miner who recently mined a Bitcoin (not S2x!) block

As a miner do the following

1. Mine on the Bitcoin 1MB chain to get superior profits
2. When nuke transactions become censored on S2x chain:
3. Hop to S2x chain, mine a block full of nuke transactions, hop back to 1MB chain

Resulting mining rewards:

Bitcoin miner rewards: 25BTC + over 9000 shitcoin
S2X miner rewards: 0 BTC + 25 shitcoin
7  Bitcoin / Project Development / SATOHASH - cryptographic key derivation function on: July 24, 2017, 06:42:58 PM
tocode released the Satohash function

https://github.com/movedon2otherthings/satohash

The function takes 256bit input (for example a password) and returns a 256bit output (for example a bitcoin private key)

This function can be used as a key derivation function. You only remember the password to your funds.

Another purpose the function can be used for hashing, like when combined with sha256 or any other function like this satohash(sha256(input file))

Code:
$ sha256sum hash.h | ./run
d590e41a6cb9ea0b1952565d29c40d3e09fe3c0d07acf42c089b9c009775d71d

The function also can be mined to create proof of work like bitcoin. But must be again chained with arbitrary input hash function like sha256

There is also a command line code that hashes stdin or the first argument

Examples:

empty input (all zeros)

Code:
$ ./run 0000000000000000000000000000000000000000000000000000000000000000
fe077f0af592477a82d8eb871615add4a53a489402dd9b5a09c4565c66db0814

$ echo -n "" | ./run
fe077f0af592477a82d8eb871615add4a53a489402dd9b5a09c4565c66db0814
$ ./run ""
fe077f0af592477a82d8eb871615add4a53a489402dd9b5a09c4565c66db0814

hello world
Code:
$ ./run satohash
db63fef9f4805eac731877f36f653635865b0a2700aae8cf6af40cb12801ada2

Demonstrate the avalanche effect, changing one letter changes whole output

Code:
$ ./run Satohash
2b4f3c56fd7f93d8d2730cc79f6e0f492dcff1e4784cef58f4a1b24554b11b06

I wish you happy holding of Bitcoin in your head, happy mining and fun. Thanks.
8  Economy / Digital goods / [buy] Bitcointalk account on: May 04, 2016, 08:10:22 AM
Looking for account in the 0.005 range

PM & post here
9  Bitcoin / Project Development / Scannable addresses. Please help on: March 20, 2016, 11:47:27 PM
I'm designing special scannable address format. See:
http://scanaddress.ucoz.com.global.prod.fastly.net/index.html

Do you like this idea? To help please photograph the code with all your phones

You can also print it and photograph the paper

Many photos are welcome!



different angles are great

shit cameras especially welcome
10  Alternate cryptocurrencies / Altcoin Discussion / ETH DUMP IS ON HOLY SHIT on: March 17, 2016, 12:48:45 PM
100 million $ out
11  Bitcoin / Project Development / the shill observer - troll monitoring - NEW: language processing on: March 16, 2016, 12:07:15 AM
To the shill monitoring site  Grin , we just added an epic new feature, language processing.  Grin  Grin
Our machinery can analyze online posts with high precision.
No matter what type of shill (government, bank, corporate) .
No matter what topic (fear, scare ,bitcoin dead, promotion, social media, convince, community engagement.), etc..

How analyzed shill post looks like?

...

As u can see we can detect the most important stuff like verbs and nouns. This will allow us to categorize posts by topics, agenda etc..

12  Alternate cryptocurrencies / Altcoin Discussion / Continuous Linked Settlement on: March 09, 2016, 01:19:41 PM
There's a system called Continuous Linked Settlement, operated by the Continuous Linked Settlement Bank under (I think) the Bank of International Settlements. This is essentially a central bank for central banks, where the worlds top 50 or banks including central banks, maintain balances in the worlds top 10 currencies for international settlements. This is how the majority of international FX trades are settled. The rest are settled bilaterally through direct vostro and nostro accounts (latin for yours and mine) between correspondent and respondent banks. The cost and complexity isn't actually related to the underlying medium of exchange (fiat balances kept in core banking systems), transfer of value (payment systems) or the network (SWIFT) but in the integration across all the channel, product, trading, treasury, risk, processing, compliance, fraud, reporting etc systems within a bank and out to customers. Also banks generally have entirely separate systems in each country, and each country generally has a regime of compliance completely different to each other. Reducing complexity, cost, risk and increasing standardisation and automation is the key yes: but this is a massive job and not as straight forward as just adding a cryptocurrency based settlement layer. Payment services need to reduce friction not increase it, so you need to provide a better service than paypal, not a much worse system, in order to compete. Finally, as an architect of core banking and payment systems for many years I can tell you first hand that commercial and central banking systems are vastly superior in cost and speed to any massively distributed consensus based public cryptocurrency system that can ever be.
13  Bitcoin / Project Development / The Shill Observer on: March 01, 2016, 12:39:34 PM
Set up a facility to archive and monitor the Epic Big Block Drama

Thinking of features to add, all ideas are welcome

...
14  Other / Off-topic / 1. April 2016 BIP: Block size decrease to 0.5MB on: February 29, 2016, 12:45:43 PM
Thanks to censorship, a 100% consensus has been reached in order to activate an effective block size decrease to 0.5MB on 1.4.2016

This highly anticipated fee event will boost miner revenues and serve as a bold warning to the illuminati behind the stress test.

After a successfull activation, the censorship on all social media will be lifted. This will cause a new consensus to be reached, for an urgent block size increase.

The subsequent massive block size increase will allow us to raise block size by 200%. This means, that the block cap will grow from 0.5 MB to 1 MB.

We expect that this massive increase will have a huge effect on the public image of Bitcoin, on the social media and will trigger a new major wave of adoption.
15  Bitcoin / Development & Technical Discussion / Pasting untrusted blocks/ and chainstate/ to new pruned node safe? on: February 14, 2016, 05:42:14 PM
I ask if it's safe to download untrusted blocks and chainstate from the internet and paste it to a pruning Bitcoin Core as a quick-start method?

Does Core validate the UTXO?

Edit: Is the chain cross platform?
16  Bitcoin / Bitcoin Discussion / Social Media Shill Activity level monitor - Classic REKT 2.0 on: February 02, 2016, 12:40:21 PM
We're developing a new startup. We want to monitor activity of shills who're trying to crash the Bitcoin project.

This has the huge potential to save Bitcoin - believers' time because they don't have to waste time reading the same
copy pasted arguments and FUD over and over.

Responding to the sockpuppets is a waste of time, they shill full-time taking shifts in the cubicle and their asses are covered by mods and upvote/downvote robots.

We want to measure using a scientific method the intensity of shills and collect proofs of various events of interest (sockpuppets, downvote robots, censorship on "uncensored" boards)

If we discover what boards are "taken over" we save time by notifying everyone of this, quit visiting, and turn the boards into the echo chamber and circlejerk it is.

Here is a proof of concept home page:

17  Bitcoin / Bitcoin Discussion / What would be Satoshi's opinion on blocksize shills ? on: January 26, 2016, 06:57:33 PM
I think that Satoshi did the right thing.
18  Alternate cryptocurrencies / Altcoin Discussion / Sky is falling. Increase to 1.337 MB needed. Consensus today, deploy tomorrow on: January 26, 2016, 01:37:57 PM
I think that Bitcoiners do not see how serious the situation is.

The recent Ethereum pump worries Satoshi Nakamoto. Satoshi is considering moving all his funds to Ethereum.
This is why we at the Bitcoin headquarters need to deploy the 1.337 MB upgrade immediately.

But before we do that, we need to do a slight bump to 1.31337 MB to test how the quadratic slow transaction.
If everything goes correctly and only some nodes crash, we can crash the remaining nodes with the full upgrade.

Major pools like the solo miners who don't mine at pool expressed full support. The central bankers agree as well.

Please sign this document with your full name and address so we can blackmail you if you decide to disagree with this proposal.

Thank you.
19  Bitcoin / Bitcoin Discussion / The shills have read the " Who Controls Bitcoin? " article on: January 25, 2016, 05:33:12 PM
It's now clear to me that they have read the article "Who Controls Bitcoin?" we released a year ago.

Only thing they did swap  Bitcoin New vs Core and Bitcoin Classic Grin

We are truly playing them like the fiddle now Grin What I expect we are going to fund another
highly trusted article this time by some Lawyer Governor or whatever and they are done Grin

20  Bitcoin / Bitcoin Discussion / Chinese community consensus to stay with Core 1MB. Meeting held Jan 25 Wuhan on: January 25, 2016, 12:31:01 PM
Chinese community consensus to stay with Core 1MB. Meeting held Jan 24 Shenzen, many Chinese BTC companies including AntPool/Bitmain, Bither, HaoBTC, BTC123, BTCKan, BTC456, BitFury, BW.COM, BitClub Network Asia.

Source: http://8btc.com/thread-38405-1-1.html

yes, this is a joke
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!