Replay Attacks, Replay Protection, and Safely Splitting Bitcoin Blake2b XBT and BTC

How do I spend my BTC without accidentally spending my XBT — or spend my XBT without accidentally spending my BTC?

This is where replay attacks and replay protection become important.

The XBT/BLAKE2b fork provides a particularly interesting example because the two networks share the historical UTXO set, while using different consensus rules after the fork. A transaction that is valid under both sets of rules can potentially be replayed from one network onto the other.

There are several ways to protect against this, including XBT's SIGHASH_UNIFIED mechanism and deliberately constructing a transaction that is valid on one chain but invalid on the other.

This article explains how replay attacks work, how XBT protects against them, how BTC transactions can be separated from XBT, and how to verify that your coins have actually been separated.

---

What Is a Replay Attack?

A replay attack occurs when a transaction created for one blockchain is copied and broadcast onto another blockchain where the same transaction is also valid.

Imagine that Alice owns 1 BTC before the fork.

After the fork, the same underlying UTXO exists under both sets of consensus rules.

Alice creates this transaction:

Alice → Bob: 1 BTC

If the transaction is valid under both networks' rules, someone can take the exact transaction and broadcast it to both chains.

Alice intended to make one payment.

Instead, the same UTXO may be spent on both networks.

Conceptually:

Before the fork

1 BTC

↓

Fork

1 BTC and 1 XBT

↓

Alice signs a transaction

Alice → Bob

↓

Without replay protection

BTC: accepted

XBT: potentially accepted

The important point is that the coins are not duplicated by the transaction itself. The two networks simply continue to recognize the same pre-fork UTXOs until transactions make them distinct under their respective rules.

---

XBT Replay Protection

XBT uses a mechanism called:

SIGHASH_UNIFIED

The implementation adds a new 0x20 flag to the signature hash type. The ordinary SIGHASH_ALL, for example, becomes 0x21.

The important consequence is that the resulting signature is not valid under the pre-fork SHA-256d consensus rules. Therefore, a transaction signed using the unified hash cannot simply be copied onto the old chain and accepted.

This is important because replay protection does not depend on the wallet asking the other network to behave differently.

Instead, the signature itself is different.

The old rules simply reject it.

In simplified form

Normal signature

SIGHASH_ALL

→ valid under the old rules

→ potentially valid on both sides

XBT unified signature

SIGHASH_UNIFIED + SIGHASH_ALL

→ valid under XBT's upgraded rules

→ rejected by the pre-fork SHA-256d rules

That is the fundamental mechanism behind XBT's replay protection.

---

Shrike Wallet

One wallet designed specifically around these changes is Shrike, an unofficial fork of Sparrow Wallet. I have not used this wallet, so I can not vouch for it or endorse it. Use at your own risk.

Shrike signs transactions using SIGHASH_UNIFIED when replay protection is enabled. Its send screen reports whether the transaction being created actually received replay protection.

This is an important distinction:

Having Shrike installed does not mean that every transaction is automatically protected.

The wallet needs to know that the signer — particularly a hardware wallet — can actually produce the required signature type.

Shrike therefore allows replay protection to be marked on individual keystores, and the transaction itself is checked before it is broadcast.

Hardware-wallet users need to pay particular attention to this. Current Shrike documentation notes that stock firmware does not yet produce SIGHASH_UNIFIED, while unofficial firmware builds exist for certain devices. Those builds are unaudited and carry their own risks.

---

What About Coins You Held Before the Fork?

This is one of the most important parts of the process.

Coins that existed before activation are recognized by both sets of rules.

Therefore, simply importing a pre-fork wallet into an XBT wallet does not magically separate the coins.

Shrike recommends sending the pre-fork coins to yourself using a transaction with the unified signature. Once that transaction confirms under the upgraded rules, the resulting UTXOs have been moved under the new transaction rules.

In other words:

Old UTXO

↓

Protected XBT transaction

↓

New XBT UTXO

That self-transfer is an important step before spending the coins in situations where replay could otherwise be possible.

---

Does BTC Have Replay Protection?

This question needs to be phrased carefully.

The better question isn't simply:

"Does BTC have replay protection?"

The more useful question is:

"Can I create a BTC transaction that is valid on BTC but invalid on XBT?"

The answer is yes, provided the transaction uses a consensus distinction between the two networks.

This gives us a second form of replay protection.

Instead of changing the signature so that BTC rejects it, we can construct a transaction that BTC accepts but XBT rejects.

---

Using a Consensus Difference to Separate BTC From XBT

One example is the treatment of OP_RETURN data.

Under the XBT/BLAKE2b consensus rules, the OP_RETURN data restriction provides a way to construct a transaction that BTC can accept while XBT rejects.

For example, a BTC transaction can contain an OP_RETURN output whose payload is larger than the XBT limit.

The result is:

BTC

Transaction → valid

XBT

Same transaction → invalid

This is fundamentally different from SIGHASH_UNIFIED.

With SIGHASH_UNIFIED, the signature distinguishes the transaction.

With the OP_RETURN method, the transaction itself violates an XBT consensus rule.

Current on-chain examples and community documentation describe an OP_RETURN payload above the XBT/BIP-110 limit as a way of creating a BTC-only transaction. The commonly cited boundary is that 83 bytes are allowed while larger payloads are rejected under the XBT rules.

Conceptually

BTC transaction

↓

Valid BTC transaction

↓

XBT node examines transaction

↓

XBT consensus rule violated

↓

XBT rejects transaction

Therefore the transaction cannot simply be replayed onto XBT.

---

An Example: Sending BTC Without Sending XBT

The basic procedure is to first make sure the coins have been separated appropriately, then create a BTC transaction that XBT will reject.

A simplified example looks like this:

Step 1 — Identify the UTXOs

Determine which UTXOs contain the coins you are trying to separate.

Do not assume that because your wallet shows a BTC balance and an XBT balance that the underlying UTXOs are already separated.

Verify them.

Step 2 — Create a BTC transaction

Create a transaction that sends your BTC to an address you control.

For example:

Your old UTXO

↓

Your new BTC address

And add an OP_RETURN output containing data that exceeds the XBT consensus limit.

The OP_RETURN output carries no spendable value. Its purpose in this example is to make the transaction invalid under XBT's rules.

Make sure you are sending it to yourself. You need to send it to a wallet you control.

---

Verify Your Wallet Before and After the Transfer

This is one of the most important practical steps.

Do not simply send the transaction and assume everything worked.

Check your wallet before the transfer and again after the transfer.

For XBT, you can use:

mempool.guide

For BTC, you can use:

mempool.space

These explorers allow you to inspect addresses, transactions and UTXOs on their respective networks. Please use your own nodes to check your balances'es, this helps preserve your privacy.

Before the transfer

Record:

• Your address

• Your balance

• Your UTXOs

• The transaction IDs associated with those UTXOs

• Which UTXOs you intend to spend

Then check the same wallet/address on both networks.

After the transfer

Once the transaction confirms, check both networks again.

For a BTC-only separation transaction, the desired result is:

BTC

The transaction is accepted and eventually confirmed.

XBT

The same transaction is rejected and does not spend the corresponding XBT UTXO.

This provides a practical way to confirm that the transaction actually separated the coins.

---

But There Is an Even Better Way: Use Your Own Node

Public block explorers are convenient, but they are not the best option for privacy.

When you enter an address into a public explorer, you are revealing that address to the operator of that service.

If you repeatedly search addresses belonging to the same wallet, the operator can potentially associate:

• your addresses

• your balances

• your transaction history

• your UTXOs

• your future transactions

Shrike's own documentation makes this point explicitly: a server you connect to can see the addresses you query, which can associate your wallet's activity and potentially your IP address. Running your own node avoids sending those wallet queries to someone else's server.

The privacy-first approach

Instead of:

Wallet → Public Explorer

use:

Wallet → Your Node

For BTC:

Wallet → Your Bitcoin node

For XBT:

Wallet → Your XBT/BLAKE2b-compatible node

Then verify the transaction directly against the nodes you control.

This is especially important when dealing with addresses and UTXOs that you do not want to associate with a third-party explorer.

Public explorers such as mempool.space and mempool.guide are useful as an independent secondary check, but your own node should be the primary source of truth when privacy matters.

---

Why Check Both Networks?

Checking only one network isn't enough.

Suppose you create a transaction and see it confirmed on BTC.

That proves that BTC accepted it.

It does not automatically prove that XBT rejected it.

Likewise, seeing a transaction rejected by XBT does not prove that BTC accepted and confirmed it.

You want to establish both sides independently.

The ideal test

Check	Desired result
BTC node	Transaction accepted
BTC blockchain	Transaction confirmed
XBT node	Same transaction rejected
XBT blockchain	Original XBT UTXO remains unspent

That is much stronger evidence that the transaction actually separated the two coins.

---

Two Different Ways to Protect Against Replay

There are therefore two fundamentally different approaches.

1. SIGHASH_UNIFIED

The signature itself is changed.

XBT

Transaction + SIGHASH_UNIFIED

↓

XBT accepts

BTC

Same transaction

↓

Signature does not satisfy old rules

↓

BTC rejects

This is the mechanism Shrike uses for XBT replay protection.

---

2. Chain-Specific Consensus Rule

The transaction itself is constructed so that one chain accepts it while the other rejects it.

For example:

BTC

OP_RETURN within BTC rules

↓

BTC accepts

XBT

OP_RETURN exceeds XBT consensus limit

↓

XBT rejects

This approach doesn't require the signature itself to be different.

Instead, the transaction is made incompatible with the other chain's consensus rules.

---

Post-Fork Coins Are Native to Their Own Chain

There is an important distinction between coins that existed before the fork and coins that are created after the fork.

The replay concern applies primarily to pre-fork UTXOs because those UTXOs were recognized by both chains when the networks split.

Coins created after the fork are different.

Once the two networks are operating under their separate consensus rules, newly mined coins are created by the blockchain on which they were mined. An XBT block creates XBT, while a BTC block creates BTC.

In other words:

XBT mining → new XBT

BTC mining → new BTC

There is no corresponding post-fork BTC UTXO created every time an XBT coin is mined, and there is no corresponding XBT UTXO created every time a BTC coin is mined.

This means that post-fork coins are not inherently mixed across the two chains in the same way that pre-fork coins are.

Why This Matters

Consider an XBT miner who receives a block reward after the fork.

That reward exists as an XBT UTXO on the XBT blockchain.

There is no matching BTC block reward sitting on the Bitcoin blockchain waiting to be replayed.

Likewise, when a Bitcoin miner receives a post-fork BTC block reward, that newly created BTC exists on the Bitcoin blockchain and does not simultaneously create an XBT balance.

The distinction can be illustrated simply:

Pre-fork UTXO

One historical UTXO

↓

BTC recognizes it

XBT recognizes it

↓

Replay protection may be necessary

---

Post-fork XBT coin

XBT block

↓

New XBT UTXO

↓

XBT recognizes it

BTC does not have the corresponding newly created UTXO

---

Post-fork BTC coin

BTC block

↓

New BTC UTXO

↓

BTC recognizes it

XBT does not have the corresponding newly created UTXO

The Practical Takeaway

The coins that require the most attention when separating BTC and XBT are therefore the coins that existed at the time of the fork.

Once you have received coins that were created natively on one chain after the fork, those coins are already associated with that chain's post-fork transaction history.

That does not mean that every later transaction is automatically replay-safe. You should still follow the rules of the particular wallet and chain and verify transactions when necessary.

But it is important not to confuse pre-fork shared UTXOs with post-fork native coins.

The simplest way to think about it is:

The fork created two chains from a shared starting point. It did not create a permanent mechanism whereby every new BTC coin also becomes XBT, or every new XBT coin also becomes BTC.

The shared history matters at the point of the fork. From there forward, each chain creates and tracks its own new UTXOs according to its own consensus rules.

BIP 110: What It Was Trying to Change in Bitcoin

What Was BIP 110 Trying to Do?

BIP 110 was called the Reduced Data Temporary Softfork. It proposed temporarily restricting several ways that arbitrary data could be embedded in Bitcoin transactions.

The basic idea was that Bitcoin was designed primarily as a monetary network, while some users had begun using Bitcoin block space to store arbitrary data such as images, text, and token-related information.

BIP 110 therefore proposed restricting some of the mechanisms that allowed large amounts of arbitrary data to be stored on-chain.

Importantly, it did not directly attempt to eliminate Ordinals themselves. Ordinal theory was software that assigned individual identities to satoshis and tracked them according to rules applied to the Bitcoin blockchain.

The important question was:

Where was the actual data being stored?

To understand that, it helped to go back to SegWit and Taproot.

---

SegWit — BIP 141

In 2017, Bitcoin activated Segregated Witness (SegWit) through BIP 141, which was a soft fork.

SegWit created a separate witness structure containing information needed to validate transactions, including signatures and scripts.

SegWit also introduced Bitcoin's modern block-weight system.

Instead of simply saying that every block could contain 1 MB of data, Bitcoin began measuring blocks in weight units.

The maximum block weight became:

4,000,000 weight units.

Witness data received a lower weight in that calculation than ordinary transaction data.

That distinction later became very important because it made certain types of data storage more economical.

---

Taproot — BIPs 340, 341 and 342

In 2021, Bitcoin activated Taproot through BIPs 340, 341 and 342. These were also soft-fork changes.

Taproot introduced new ways of constructing and spending Bitcoin outputs using Taproot scripts.

One consequence was that substantial amounts of arbitrary data could be placed into Taproot script-path witness data.

That became particularly important for Ordinal inscriptions.

So the sequence was:

SegWit → witness data and the witness discount

then:

Taproot → additional scripting capabilities

and later:

Ordinals → use of those existing capabilities to store inscriptions.

---

OP_RETURN — Bitcoin's Data Field

Another place people could put data was OP_RETURN.

A simple way to think about OP_RETURN was as a kind of memo/data field in a Bitcoin transaction.

It allowed a transaction to carry a small amount of information that did not represent a spendable Bitcoin output.

This became particularly important for Runes.

---

Runes

Runes were a protocol for creating fungible tokens on Bitcoin.

Unlike Ordinal inscriptions, Runes used OP_RETURN to encode their protocol instructions.

So the relationship looked roughly like this:

Bitcoin transaction → OP_RETURN → Rune protocol data → Runes

The Rune itself was not a native Bitcoin coin. Compatible software interpreted the transaction data according to the Rune protocol.

This meant that if OP_RETURN data limits were tightened, that could affect how Runes used Bitcoin block space.

---

Ordinals

This brings us to Ordinals.

Ordinal theory gave individual satoshis an identity and provided a system for tracking them as they moved through Bitcoin transactions.

It could be thought of roughly as giving every satoshi a serial number.

An important distinction was that Ordinals did not require inscriptions.

The Ordinal system could track individual satoshis without putting an image or other arbitrary data on them. Ordinals are a separate system, outside of Bitcoin, that tracks satoshis.

---

Inscriptions

An inscription is where additional data was associated with a satoshi.

That data could have been:

• An image
• Text
• HTML
• SVG
• Or other arbitrary content

The content is represented by bytes and stored in the witness portion of a Taproot transaction.

This was where the SegWit → Taproot → Ordinals connection became important.

The sequence was:

SegWit (2017)
↓
Created the witness structure and witness discount
↓
Taproot (2021)
↓
Created additional Taproot script-path capabilities
↓
Ordinals (2022–2023)
↓
Used those existing Bitcoin features
↓
Inscriptions
↓
Stored arbitrary content in Taproot witness data

The inscription data could be divided among multiple data pushes, allowing larger files to be stored across the witness portion of a transaction.

---

BRC-20 Tokens

BRC-20 took the idea one step further.

BRC-20 was a token protocol built on top of Ordinal inscriptions.

A BRC-20 inscription could contain instructions interpreted by BRC-20 software to:

• Deploy a token
• Mint tokens
• Transfer tokens

Bitcoin itself did not recognize a BRC-20 token as a native Bitcoin asset.

Instead, BRC-20-compatible software read the inscriptions and maintained token balances according to the protocol's rules.

The relationship was therefore:

Bitcoin
↓
Ordinals
↓
Inscriptions
↓
BRC-20
↓
Fungible tokens

---

Bitcoin Stamps

Bitcoin Stamps took a different approach to storing data.

Instead of relying primarily on the Taproot witness mechanism used by Ordinal inscriptions, Stamps embedded data into Bitcoin transaction outputs, particularly through multisig-based techniques and Counterparty-related formats.

So there was an important distinction:

Ordinals/Inscriptions → witness data

while:

Stamps → transaction-output data

That distinction mattered when looking at what BIP 110 was trying to restrict.

---

What Was BIP 110 Actually Trying to Restrict?

BIP 110 did not say:

"Ban Ordinals."

And it did not say:

"Ban Runes."

Instead, it proposed restrictions on several of the mechanisms used to put arbitrary data into Bitcoin transactions.

Among the proposed restrictions were:

• New scriptPubKeys over 34 bytes were restricted, with an exception for OP_RETURN outputs up to 83 bytes.
• Certain OP_PUSHDATA payloads and witness stack elements over 256 bytes were restricted.
• Certain undefined witness versions were restricted.
• Taproot annexes were prohibited.
• Certain large Taproot control blocks were restricted.
• Certain Tapscript constructions were restricted.

The overall objective was to make it substantially harder to embed large amounts of contiguous arbitrary data in Bitcoin transactions.

---

How Would That Have Affected Inscriptions?

This was probably the most important part.

An inscription could contain a large image because the inscription data could be divided into multiple witness data pushes.

Under BIP 110's proposed rules, individual witness data elements over 256 bytes would have been restricted.

That did not mean:

"Ordinals disappear."

The Ordinal numbering system could still exist.

Instead, the question would have become:

How could someone put a large image onto the blockchain using the remaining permitted structures?

BIP 110 therefore targeted the data-storage mechanism, rather than directly targeting the concept of an Ordinal.

Someone could potentially divide data into smaller pieces, but the proposal was intended to make arbitrary-data storage more difficult.

---

The Big Picture

The history could be summarized this way:

2017 — SegWit / BIP 141

Bitcoin introduced the witness structure and block-weight accounting.

Witness data received a discount in block-weight calculations.

2021 — Taproot / BIPs 340, 341 and 342

Bitcoin introduced new Taproot spending and scripting capabilities.

Those capabilities could carry substantial witness data.

2022–2023 — Ordinals and Inscriptions

People developed software that tracked individual satoshis and used Taproot witness data to associate arbitrary content with them.

Images, text, and other data could be stored directly on-chain.

BRC-20

People used Ordinal inscriptions to create a protocol for fungible tokens.

Runes

A different token protocol used OP_RETURN to encode its instructions.

Bitcoin Stamps

Another approach stored data in transaction outputs, using techniques associated with Counterparty.

BIP 110

BIP 110 proposed restricting several of the underlying mechanisms used to store arbitrary data:

large witness/data pushes + large output scripts + certain Taproot mechanisms + larger OP_RETURN data

The goal was to temporarily reduce arbitrary-data storage on Bitcoin while preserving normal monetary transactions.

---

One Important Distinction

The easiest way to understand the entire issue was to separate Ordinals from inscriptions.

Ordinals: the system for identifying and tracking individual satoshis.

Inscriptions: arbitrary data associated with those satoshis.

So when people argued about "Ordinals spam," the actual block-space issue was primarily the inscription data, not the act of assigning numbers to satoshis.

That distinction was central to understanding what BIP 110 was trying to change.

How to Enable SSH on Innosilicon S11 Siamaster Blake2b (Root Password & Remote Management Guide) Bitcoin XBT

The Innosilicon S11 SiaMaster has SSH capability, but access is password-protected, and Innosilicon has not publicly provided the default SSH password.

Fortunately, the S11 controller board provides a serial console, through uart, that can be used to access the miner's bootloader.

By interrupting the normal boot process and booting Linux (which is already installed on your S11) with a modified kernel command line, it is possible to obtain a temporary root shell. From this shell, the root password can be changed, allowing persistent SSH access to the miner.

FYI, I used Linux to connect to the S11. Its also possible to use other Operating Systems, you would just have to change 1 or 2 steps to make it work for you.

This guide walks through the process step by step.

Warning: This procedure modifies the miner's system configuration. Make sure you understand each step before proceeding. Having a backup of the original firmware and configuration is strongly recommended. Proceed at your own risk

You have three options for getting SSH root access on an Innosilicon S11:

1. Manual Configuration (Covered in this guide): The standard process for gaining direct command-line control.
1. Firmware v  s11_20181026_024244 Build Date 26th of October 2018 02:42 AM
1. I have confirmed this method to work for this version of the firmware.
2. Firmware v s11_20190424_095412 Build Date 24th of April 2019 09:54 AM
1. This method does not work on this version. 
2. Default Password Discovery: Waiting on the community to crack the default SSH credentials.
3. Pre-patched Custom Firmware: I can share a custom build pre-configured with known SSH credentials if there is enough interest. Note: Running unofficial firmware always carries a risk of bricking the ASIC, so proceed with caution.

The Default SSH Password Hash

The default root SSH password is stored in /etc/shadow as a SHA-512 crypt password hash:

$6$LDl3NtVWLpmGp1$52ivJuFI39PLeUerTxouNpwZn/WsJNlxhvQyUwPjJdxnoo2f93D1d904xFefd91qVWWjrC2jnj7Xz5oMaWAep1

The hash follows the standard crypt format:

$6$<salt>$<hash>

Breaking it down:

• $6$ — Indicates the SHA-512 crypt hashing algorithm.
• LDl3NtVWLpmGp1 — The unique salt used when generating the password hash.
• The remaining string — The resulting password hash.

Because the password itself is not stored in plaintext, the value in /etc/shadow cannot simply be read as the SSH password. The purpose of this guide is to use the S11's bootloader and serial console to gain temporary root access and set a new password that you control.

 

---

What You Will Need

• Innosilicon S11 SiaMaster
• CP2102 USB-to-TTL serial adapter - $10 (USB UART)
• PuTTY - Free Download
• Network connection to the S11

The serial adapter is used only for communicating with the S11's controller board.

---

1. Connect the CP2102 to the S11

Make sure your S11 is powered off and unplugged.

To gain access to the serial pins on the S11, remove the controller board by following these steps:

• Remove the back fan and the metal separator plate.
• Pull out all three hashboards just far enough to free the controller board.

Leave the power to all hashboards unplugged; they do not need to be powered on for this process.

Connect the CP2102 serial adapter to the S11 controller board as follows:

CP2102	S11
GND	GND
TXD	RXD
RXD	TXD

The transmit and receive lines are crossed:

CP2102 TXD → S11 RXD

CP2102 RXD → S11 TXD

CP2102 GND → S11 GND

Do not connect the CP2102's power/VCC pin to the S11 unless you specifically know that it is required. For the serial console, GND, TXD, and RXD are sufficient.

Once the connections are made, connect the CP2102 to your computer's usb port. To make it a little easier on myself, I used a usb extension.

Reconnect everything to your miner, ethernet cable, fans, hash boards and controller board. Leave the controller board out of the machine and make sure its on a non conductive, non static material. The controller board can not fit back into its slot in the s11 because of the cables we have connected to the serial pins.

Do not turn on the power yet.

---

2. Configure PuTTY

Open PuTTY and select:

Connection type: Serial

Serial line: /dev/ttyUSB0

Speed: 115200

On Linux, the CP2102 will commonly appear as:

/dev/ttyUSB0

On Windows, it will normally appear as a COM port such as:

COM4

Select the appropriate port for your computer.

Click Open and you will get a blank black window.

---

Pasting Commands into PuTTY

When entering the commands later in this guide, each command should be sent one at a time.

PuTTY has an option that allows text copied from outside PuTTY to be pasted into the terminal. On Linux, Shift+Insert can be used to paste text into the terminal.

Be careful when copying commands.

For example, Ctrl+C should be used to copy text rather than relying on the right mouse button, depending on how your PuTTY configuration is set up.

Also note that highlighting text in PuTTY can place that text into the clipboard.

---

3. Power On the S11

With PuTTY connected to the serial console, and window open, power on the S11.

You should see a large amount of boot information scrolling through the terminal.

Under normal circumstances, the S11 will eventually continue through its normal boot process and present a login prompt. If none of your hashboards are connected, then you may not see the login prompt.

The root credentials used by the factory firmware are not provided through the normal user interface, so the serial console provides another way to gain access to the underlying Linux system.

---

4. Interrupt the Normal Boot Process

This is the important part.

With the PuTTY window selected, restart or power-cycle the S11.

As the miner begins booting, repeatedly press a keyboard key in the PuTTY window.

The goal is to interrupt the normal boot process and stop at the U-Boot command prompt.

If successful, you should see:

Zynq>

This is the U-Boot prompt.

At this point, we can manually load the FPGA, kernel, device tree, and root filesystem and modify the Linux boot arguments.

---

5. Boot Linux With a Root Shell

At the Zynq> prompt, enter the following commands.

Enter each command separately and wait for it to finish before entering the next one.

Command 1

setenv image_flag 0

Command 2

nand read 0x400000 0x580000 0x400000

Command 3

fpga loadb 0 0x400000 0x400000

Command 4

nand read 0x2000000 0x480000 0x80000

Command 5

nand read 0x2080000 0xd80000 0x500000

Command 6

setenv bootargs 'console=ttyPS0,115200 noinitrd root=ubi0:rootfs ro ubi.mtd=8 earlyprintk rootfstype=ubifs rootwait init=/bin/sh'

Command 7

bootm 0x2080000 - 0x2000000

The system should now boot Linux using the modified boot arguments.

---

6. Confirm Root Shell Access

If everything worked, Linux should eventually stop at a shell prompt:

/#

The /# prompt indicates that you have a root shell.

Type in

cd /

ls -la

You should be able to see a large amount of folders and files.

At this point you have temporary root access to the S11's Linux operating system.

However, this access will disappear when the miner is rebooted.

To make SSH access persistent, we need to set a root password.

---

7. Remount the Root Filesystem Read/Write

The root filesystem was intentionally booted read-only.

First, in the shell prompt, remount it as read/write:

mount -o remount,rw /

---

8. Set a New Root Password

Run:

passwd

Linux will ask you to enter a new password. Enter the password you want to use for SSH.

For example, you could use:

admin

Use a strong password on any miner that is accessible from an untrusted network.

---

9. Remove the Root Password Expiration Date

The S11 firmware's /etc/shadow entry contains a password-aging value.

The following command removes the password date field from the root entry:

sed -i 's|^root:\([^:]*\):[0-9]*:|root:\1::|' /etc/shadow

This prevents the password from being treated as expired based on the existing date value.

---

10. Return the Root Filesystem to Read-Only

Once the changes are complete, remount the filesystem read-only:

mount -o remount,ro /

You can now power-cycle the miner.

The usb adapter will not be needed for the rest of the tutorial. You should keep it connected just incase you need to resend the commands.

---

11. Find the S11's IP Address

After powering the S11 back on, allow it a couple of minutes to complete its normal startup process.

Make sure that your computer and your s11 are on the same network.

You can use a network scanner such as Angry IP Scanner to locate the miner.

Once you find the IP address, enter it into your web browser.

For example:

http://10.0.0.15/

If the normal Innosilicon web dashboard interface appears, you have identified the correct IP address.

---

12. Connect to the S11 Using SSH

Open a terminal on your computer and run:

ssh root@10.0.0.15

Replace 10.0.0.15 with the actual IP address of your S11.

You should be prompted for the root password you created earlier.

After successfully authenticating, you should receive a root shell similar to:

#

Type in

cd /

ls -la

You should be able to see a large amount of folders and files.

You now have persistent root access to the S11 through SSH.

---

13. Optional: Configure Passwordless SSH

If you are going to administer the S11 frequently, you can configure SSH public-key authentication.

This is especially useful if you want scripts or automation software to connect to the miner without prompting for a password every time.

Generate an SSH Key

On your computer, run:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_s11 -N ""

If the specified key already exists, SSH will ask whether you want to overwrite it.

Do not overwrite an existing key unless you intend to replace it.

---

Open a Second Terminal

Keep the first terminal open.

In the second terminal, connect to the S11:

ssh root@10.0.0.15

After logging in, remount the filesystem as read/write:

mount -o remount,rw /

Leave this second terminal open.

---

Copy the SSH Key to the S11

Return to the first terminal and run:

ssh-copy-id -i ~/.ssh/id_s11.pub root@10.0.0.15

Enter the root password when prompted.

This copies your public SSH key to the S11's authorized keys file.

---

Return the Filesystem to Read-Only

Go back to the second terminal connected to the S11 and run:

mount -o remount,ro /

---

14. Test Passwordless SSH

Return to the first terminal.

Run:

ssh root@10.0.0.15

If everything was configured correctly, SSH should connect without asking for the root password.

You should receive a root shell:

#

You have now successfully configured passwordless SSH access to your Innosilicon S11 SiaMaster.

---

Conclusion

Using the S11's serial console and U-Boot environment, you can interrupt the normal boot process and launch the installed Linux system with a shell as root.

This provides a much more convenient way to work with the S11 than relying exclusively on the web interface or serial console.

The Fastest Way to Take Photos for eBay using Image Splitter Pro

I’m releasing Image Splitter Pro for free because I want every seller to spend less time listing and more time growing their business.

Please share this article & video with your friends who sell on eBay!

Get Started:

• 🛠️ Open Source: View the code on Github.com

• 💻 Download the App: 

• Windows-1.0.0-x64.zip

• MacOS-1.0.0-arm64.zip

• Linux-1.0.0-x64.zip

Buy Me a Coffee ☕

If you enjoy using the app and want to support its continued development, donations are greatly appreciated!

• PayPal
• Bitcoin Lightning - abelxl@breez.fun
• Bitcoin On-Chain 

Thank you for your support! 

🚀 Getting Started: The Setup Wizard

When you launch Image Splitter Pro for the first time, the Setup Wizard will guide you through two essential steps:

1. Select a Source Folder
• This is your "Input"—the location where Image Splitter Pro looks for images to edit. Any images placed here will automatically be available in the app.
• My workflow: Set your Source Folder to the Camera Roll folder. If you use the stock Windows Camera App, any pictures you take are instantly sent to this folder (typically located at C:\Users\YourName\OneDrive\Pictures\Camera Roll). Image Splitter Pro will detect these new photos and import them into the viewer immediately after you snap them.
• ⚠️ Note: Back up ALL files in your Source Folder! Image Splitter Pro may move or delete files in this folder during the editing process. If you have existing photos in your Camera Roll that you don't want the app to access, please move them to a different location before starting.
2. Select a Destination Folder
• This is your "Output"—the location where your finished, cropped images will be saved. 
• It's a best practice to create a new empty folder dedicated to only store the new cropped images

📸 How to Import Images

Getting your photos into the app is simple:

• Drag & Drop: Simply drag images directly into the app window.
• Direct Move: Manually move your image files into your Source Folder.
• Windows Camera Sync: If you are capturing photos using the default Windows Camera App, you can set your Source Folder to the default Windows Camera Roll. This allows Image Splitter Pro to auto load images automatically as you snap them.
• Set your Source Folder to path C:\Users\[YourName]\OneDrive\Pictures\Camera Roll.

Here are some sample 4K (3840 x 2160) images, you can download to test out the software. The images were taken from my Logitech Brio 4K Pro Webcam.

✂️ Understanding Profiles & Cropping

To start cropping, you must have at least one image in your Source Folder.

What is a Profile? A Profile is a saved list of cropping rules. You can create unlimited Profiles for different items, such as:

• Large Shirts

• Trading Cards

• Magazines

• Electronics

📝 How to Create a Profile

To start, ensure you have at least one image in your Source Folder to use as a reference.

1. Open the Menu: Click Edit → Create Profile (Ctrl + N).

2. Name Your Profile: Enter a descriptive name in the Profile Name field (e.g., Large Shirts, Trading Cards, or Small Electronics).

3. Select an Image: Click Select Image and choose your first reference photo to set your rules.

4. Set Aspect Ratio: By default, this is set to "None".

5. Adjust the Crop: On the right, you’ll see a red box. Click and drag the corner handles to the exact position and size you want.

6. Add Rules: Click Create New Cropping Rule and repeat for as many crops as you like.

7. Save: Click Save & Close.

💡 Pro Tip: eBay requires a minimum of 500 px on the longest side. For the zoom feature to work on eBay's site, your image must be at least 800 px on the longest side.

For your first profile, use 1 image and play around with the cropping rules. Once you understand how the rules and image positions work, then you can create a more complex profile like this:

⚡ The Workflow

Once your Profile is ready, it's time to let the automation do the heavy lifting:

1. Select Your Profile: Choose your saved Profile name (e.g., "Large Shirts") from the dropdown list at the top of the app.

2. Crop: Click the Crop button (Ctrl + R). The software will apply all your rules to the images in your Source Folder and display the results in the right-hand image viewer.

3. Move: Click the Move button (Ctrl + M). This sends all images directly to your Destination Folder.

4. Upload: To find your files, go to File → Open Destination Folder. Your images are now organized and ready to be uploaded to eBay!

🛠️ The Hardware Setup

To get the most out of Image Splitter Pro, you need a high-quality, stationary camera. Here is the gear I used.

🎥 The Camera: Logitech Brio 4K Pro Webcam

I bought mine used for $60 on eBay.

• Why 4K? Since we are cropping images down, starting with the highest resolution possible is key to keeping your eBay photos crisp.

• Instant Transfer: Unlike a phone, a webcam is hardwired to your computer. Images land in your Source Folder almost instantaneously via USB.

• The webcam has a 1/4-20 tripod tread on the bottom. This gives us a lot of mounting options.

• Set it and Forget it: A stationary camera stays in the perfect position for your products. This keeps your hands free to manipulate items without constantly picking up a camera or phone.

💡 Pro Tip: You can also use some Cell Phones, Point & Shoot, or Mirrorless cameras as a webcam by connecting them via USB or using wireless transfer software.

🏗️ The Rig: Magnetic Quick-Release System

I wanted to be able to switch from "Bird's Eye" shots to "Close-ups" quickly, so I built this custom mounting solution:

SmallRig Magic Arm with Super Clamp: This is the backbone of the station. It clamps to your desk or shelf and holds the camera exactly where you need it.

SUREWO Quick Release Magnetic Mount: This allows you to "snap" the webcam on and off instantly for detail shots.

1/4"-20 Conversion Adapter Mount to GoPro: This is the "bridge" that lets you mount a standard webcam (which uses a 1/4" screw) onto GoPro-style magnetic mounts. I didn't use this mount since I already had a 1/4-20 conversion adapter GoPro mount.

Or, you could spend a little more and get the NEEWER Magnetic Action Camera Mount Kit. It comes with some more hardware in case you need it for a different project. Fyi, I haven't used this kit so I don't know how strong the magnet is or if the mount can be in the base while being unlocked. I would want to have to flip the unlock switch every time I wanted to remove the camera.

Alternate Camera Mounts

JJC Magnetic Mount Stand with 1/4"-20 Screw - I tried to use this magnetic mount, but I could not get it high enough on my photo booth. I'm using the 1/4-20 thread to gopro mount from this device on my current rig setup.

Magnetic Tripod Mount Adapter for Magsafe, with 1/4"-20 Screw Hole, Compatible with iPhone - This would work if you could setup your Cell Phone as a webcam.

Selens Wall Mount Boom Arm with Triangle Base - This is a good way of setting up your camera for a horizontal flat lay. An issue you might have is that you can't move the camera any higher if you need to. Part of the challenge with a stationary camera setup is to make sure the article of clothing is at the proper distance from the camera.

The Reseller Ruler

The Reseller Ruler is a specialized tool featuring two rulers connected at a center pivot point, making it the ideal solution for measuring clothing.

A huge shout-out to TechnSports, a veteran eBay seller and the inventor of the Reseller Ruler, for creating such a game-changing tool for the community. It simplifies the process of getting accurate length and width measurements in a single layout.

💻 The Software Setup

To bridge the gap between your camera and Image Splitter Pro, we’ll use two simple tools.

LogiTune (Optional but Recommended)

LogiTune is the official utility from Logitech, and while it is technically optional, I highly recommend using it for one specific reason: Total Control. To get the most out of your setup, here are the settings I use and why:

1. Field of View (FoV) & Zoom

• Settings: FoV set to 90°; Zoom set to 0.

• Why: This provides the widest possible view, allowing the camera to capture the entire shirt at the lowest possible mounting height. If you decrease the FoV or zoom in, you’ll have to mount the camera much higher to fit the item in the frame, which results in a loss of valuable image resolution.

2. Manual Exposure

• Setting: Auto-Exposure OFF.

• Why: Auto-exposure tends to fluctuate based on the color of the shirt or the lighting in the room. By setting the exposure manually, you ensure every photo has a consistent, professional brightness that doesn't "flicker" between shots.

3. Manual Focus

• Setting: Auto-Focus OFF.

• Why: Auto-focus can be a major bottleneck. Every time my head or hands entered the frame to adjust a shirt, the camera would try to focus on me instead of the garment. I often had to "wave" at the lens to get it to refocus on the backboard. By switching to manual focus and locking it onto your mounting board, every shirt stays perfectly sharp without the camera hunting for focus.

Important Note: If you lock your focus, remember that taking the webcam off its stand for handheld detail shots will result in blurry images. You will need to toggle auto-focus back on or adjust it manually for close-ups.

Windows Camera App (The Shutter)

For the capture phase, we’ll use the native Windows Camera App. It’s lightweight, fast, and already built into Windows 10 and 11. To open it, click the Windows Icon > Camera, or simply search for "Camera" in your taskbar.

1. Select Your Device

In the top-right corner, look for the Change Camera icon (it looks like a camera with a rotating arrow). Click it until the Logitech Brio 4K Pro is selected.

2. Set Up Your Framing Grid

Consistency is the secret to getting the best performance out of Image Splitter Pro. You want to place your clothing in the same spot for every shot—within an inch or two of your original placement. To help with this:

• Click the Gear Icon (Settings) in the top-left corner.

• Under Camera Settings, look for the Framing Grid options.

• Select a grid that works for you; I personally recommend "Rule of Thirds" or "Square."

These lines will appear as an overlay on your screen, acting as a visual guide to ensure your shirts are centered and straight every single time. Replicating your layout consistently now will save you a massive amount of time during the splitting and cropping phase later.

In the Photo Settings tab, go to Photo Quality and scroll up to 8.3MP 16:9 (3840x2160). This will give you a 4K images.

If you scroll down, you will see an option that says 8.8MP 256:135 (4096x2160). This will also give you a 4K image with slightly better resolution, but what I found is that the overall image is shorter than the image with the 8.3MP 16:9 (3840x2160) settings. Which means, you will have to raise your webcam higher in order to fit the whole shirt in your frame. I believe that this will negate the added resolution from the 4096x2160 image.

Platform Note: macOS and Linux users will need to use their respective default camera software (like Photo Booth or Cheese). I haven't use either of these apps, I just read that they are a staple of those operating systems.

The Crucial Link: Syncing the Folders

To make the automation work, you need to bridge the gap between your camera and Image Splitter Pro. By default, the Windows Camera App automatically saves every photo directly into your "Camera Roll" folder.

To capitalize on this, simply set the Source Folder in Image Splitter Pro to that same Camera Roll folder. Once linked, the workflow becomes seamless: you snap a photo, Windows saves it, and Image Splitter Pro pulls it in instantly for processing.

⚡ Full Workflow Summary: From Backboard to eBay

Once your folders are synced and your rules are set, your production line looks like this:

1. Prep: Position your shirt on the backboard. Use the grid lines as a guide.

2. Launch: Open Image Splitter Pro and your Camera App.

3. Capture: White the Camera App is active, click the [Enter] key, this will trigger the shutter.

4. Process: Switch to Image Splitter Pro, select a profile and click Crop.

5. File: Click Move to send the finished shots to your destination folder.

6. Repeat: Replace with a new shirt and repeat.

Pro Tip: Resolution Matters

When capturing clothing, distance is your enemy. To maintain crisp fabric textures and fine details from a distance, a 4K camera is the absolute minimum. In my testing, 1080p images resulted in significant quality loss at these distances; 1080p is generally only suitable for close-up shots of smaller items.

Why Higher Resolution Wins

If you have access to a camera with higher than 4K resolution, use it. For example, I use a Canon SL2 DSLR. While it is an older model, its 24.2-megapixel sensor captures 6K still photos ($6000\times 3368$ pixels).

The advantage of 6K is the "crop factor." You can crop significantly deeper into a 6K image and still retain more detail than a native 4K shot. This is especially useful for showing close-ups of labels, stitching, or ruler measurements without needing to move the camera.

The 200% magnification of the 4K image shows that the ruler measurements are difficult but not impossible to read. While the 200% 6K image, is much easier to read.

Repurpose Your Existing Gear

Before you go out and buy a new high-end webcam, check if you already own a Point-and-Shoot Camera, DSLR or Mirrorless camera. Many manufacturers offer free software—like the Canon EOS Webcam Utility—that allows your computer to recognize your professional camera as a high-quality webcam. Many modern Cell Phone Cameras also support wireless transfers, allowing you to send high-res photos directly to your computer for processing.