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

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).

[Proving substrings using OP_MERKLE]

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.

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.

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.

[Here is how 2x chain can be effectively destroyed]

Here is how 2x chain can be effectively destroyed 

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

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.

Looking for account in the 0.005 range

PM & post here

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

100 million $ out

To the shill monitoring site   , we just added an epic new feature, language processing.    
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..

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.

Set up a facility to archive and monitor the Epic Big Block Drama

Thinking of features to add, all ideas are welcome

...

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.

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?

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:

I think that Satoshi did the right thing.

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.

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

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

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