PaperlayerView exact revision on arXiv

Source-linked AI summary

Self-replicating seedbox servers using programmable money

Matei Dogariu, Johan Pouwelse

arXiv:2609.05431v1physics.soc-phcs.MA

TL;DR

Centralized content distribution depends on an operator, while decentralized networks still rely on humans maintaining hardware. EternalSeedBox runs autonomous VPS seedboxes whose inherited economic rules manage payment, reproduction, and retirement, and tests them against replicas of Bitcoin and SporeStack. The fleet reached 33 nodes from EUR 10,000 and sustained 40–80 live nodes for 510 days with simulated income, provided revenue covers per-node rent.

  • Problem

    Centralized systems depend on operators, while decentralized content networks still depend on humans keeping their hardware running.

  • Method

    The paper runs unmodified EternalSeedBox node code against faithful replicas of the Bitcoin payment network and SporeStack VPS marketplace.

  • Results

    With EUR 10,000 and no continuous income, the fleet reached 33 nodes and the last node expired at day 153; with income, it held 40–80 live nodes across 510 days, recording 268 births and 190 deaths.

  • Takeaways & Limitations

    The fleet tolerates high node turnover because reproduction depends on any node holding a surplus rather than one particular node surviving.

  • Takeaways & Limitations

    The evaluation is bounded by a host-imposed 60-node capacity and a pricing model requiring EUR 3.27 per node per day to break even.

Abstract

from arXiv · show

Centralized content distribution makes availability depend on a single operator's survival and willingness to serve. EternalSeedBox replaces the operator and network with inherited economic parameters: each node is a VPS that seeds media over BitTorrent, holds a Bitcoin wallet, and autonomously decides every twelve hours whether to renew its lease, spawn a child, or sweep its funds to a healthier peer before expiring. A single genesis node seeds the fleet, and every node thereafter is provisioned, funded, and retired autonomously. We validate the design against faithful replicas of both the Bitcoin payment network and the SporeStack VPS marketplace by running the unmodified node code. A lump sum of EUR 10,000 grew the fleet to 33 nodes before capital exhausted at day 153. With simulated income, the fleet held 40--80 live nodes across 510 days, recording 268 births and 190 deaths. A heritable caution trait was introduced to diverge across generations: low-caution lineages reproduced faster during high-income phases, while the survival advantage expected of high-caution lineages during income pauses did not appear, leaving selection in favor of low-caution nodes. The fleet tolerates high node turnover because reproduction depends on any node holding a surplus, not any single node surviving. EternalSeedBox shows that a content distribution network can lease, pay for, and replenish its own hardware without a human operator after genesis, provided income exceeds per-node rent.

1 Introduction

Centralized distribution leaves content availability dependent on an operator, while decentralized networks still depend on humans maintaining hardware. EternalSeedBox asks whether inherited economic parameters can sustain a content network without further human intervention.

  • Centralized operators can remove or restrict content, making availability depend on their willingness and ability to serve it.
  • Peer-to-peer protocols spread content across nodes, but their infrastructure remains dependent on humans running the hardware.
  • EternalSeedBox removes single-node authority and post-genesis human management by letting nodes make local decisions from financial state and inherited parameters.
  • The research question is whether a fleet seeded by one genesis node can survive and grow without further human intervention.
  • The system is evaluated by running unmodified node code against faithful replicas of the Bitcoin network and VPS marketplace.

2 Proposed Solution

EternalSeedBox is an autonomous content-distribution fleet whose VPS nodes seed Creative Commons media and act every twelve hours according to their own financial and operational state. After genesis, the fleet consists of nodes that can observe its components and content through a client application.

  • Each node manages its finances, seeds Creative Commons content over BitTorrent, and spawns children when sufficiently funded.
  • After a genesis node starts the system, subsequent nodes are provisioned, funded, deployed, and eventually expire without human involvement.
  • Every twelve hours, a node acts or does nothing based entirely on its own financial and operational state.
  • The proposed system comprises the EternalSeedBox node fleet and a client application for observing the fleet and its content.

2.1 EternalSeedBox Node Internals

Each EternalSeedBox node is a VPS-based seedbox that distributes Creative Commons media, exchanges catalog and health information with peers, and participates in an autonomously funded fleet. A genesis deployment initializes the infrastructure, after which nodes coordinate through Bitcoin, SporeStack, and an IPv8 overlay.

  • Genesis deployment: A genesis deployment creates the wallet, funds SporeStack, provisions a VPS, installs the node code, and starts the orchestrator.
  • Node runtime: The orchestrator initializes persistent state and runs concurrent seedbox, announcer, monitor, and decision-loop tasks.
  • Content seeding: Each node seeds Creative Commons media over BitTorrent from content downloaded at startup and stored until a configurable disk-usage threshold.
  • Fleet coordination: Nodes exchange torrent metadata and health telemetry over an IPv8 community, including balances, uptime, disk usage, region, and remaining runway.
  • Fleet coordination: Epidemic broadcasting propagates catalog and telemetry messages so every node maintains a complete fleet view rather than only its direct neighbors.
  • Fleet coordination: The peer registry uses Bitcoin addresses as cross-hop identities and supplies dying nodes with targets for transferring remaining funds.

2.1.8 Node Monitor

The node monitor supplies balance and runway information to a twelve-hour decision loop that prioritizes failsafe transfer, lease top-up, child spawning, and inactivity. Spawning is constrained by post-spawn runway and wallet funds, while caution controls the retained runway threshold.

  • Monitoring: The monitor refreshes Bitcoin balance and VPS runway every five minutes for the decision loop and peer-facing health announcements.
  • Decision loop: The decision loop runs every twelve hours and evaluates failsafe, top-up, spawn, and do-nothing actions in priority order.
  • Decision loop: A successful top-up is followed by a balance re-scan, allowing one tick to extend the lease and spawn a child.
  • Recovery and updating: Persistent state lets a restarted node resume an interrupted spawn or failsafe pipeline, while the simple commit-based updater restarts the running fleet but requires production hardening.
  • Self-replication: Before spawning, a node subtracts the full spawn cost and checks that its remaining runway exceeds a healthy threshold while its wallet covers the child’s VPS costs.
  • Self-replication: The child inherits 40% of the Bitcoin remaining after the parent pays the child’s VPS costs.
  • Self-replication: Caution mutates across generations and scales the post-spawn runway threshold from 81 days at 0.35 to 114 days at 0.9.
  • Failsafe: Below two days of runway, a node transfers its full Bitcoin balance to the highest-balance live peer before allowing its lease to expire.

2.2 The Client Frontend Service

The client frontend gives users a distributed view of the fleet’s seeded content, node health, and governance activity through the IPv8 overlay.

  • Client functions: The desktop client presents the fleet’s seeded-content catalog, live torrent health, node status, and governance records.It collects torrent metadata, probes BitTorrent DHT health, lists node telemetry, and exposes community voting.
  • Content catalog: Each torrent entry includes its magnet link, source URL, license, and DHT-measured swarm health.
  • Fleet status: The fleet view lists live nodes with identity, runtime, storage, Bitcoin balance, provider region, and remaining runway.The view provides a population-level picture of fleet size and solvency.
  • Governance: Governance records let community members propose, discuss, and vote on code commits adopted by the fleet.The resulting records are distributed over IPv8 and exposed through the client.
  • Persistence: The client persists torrent, fleet, and governance streams in SQLite so views survive restarts and retain historical metrics.

3 Related Work

Related work frames EternalSeedBox as an autonomic, self-replicating economic system that replaces human node commitment with market-dependent survival.

  • Autonomic systems: EternalSeedBox implements MAPE-K at node level, using monitoring, decision logic, persistent state, and inherited configuration without central operator quotas.
  • Self-replication: The system’s replication uses real Bitcoin payments and commercial VPS provisioning rather than simulated CPU cycles or virtual resources.The paper presents this as its first self-replicating autonomous economic agent operating through a commercial infrastructure market.
  • Decentralized coordination: Unlike a DAO, EternalSeedBox has no shared ledger, voting, quorum, or on-chain contract; each node decides from its own financial state.Coordination is purely economic, trading collective decision-making for reduced contract complexity.
  • Open problem: Voluntary payment remains the primary open problem because the deployment’s income incentive mechanism is not evaluated and simulated income is exogenous.
  • Cooperative distribution: The design addresses volunteer dependence by making node survival depend on covering operating costs rather than on continued volunteer commitment.Nodes renew when solvent and expire when they cannot cover their leases.

4 Attack Resilience

The attack-resilience design protects autonomous spawning, recovery, resource use, and peer communication, while explicitly retaining several security and reliability risks.

  • Threat model: Freshly spawned children are most exposed because deployment transfers wallets and executes setup code on new VPS instances.
  • Deployment security: Pinned SSH host keys, per-child Ed25519 keys, and restricted firewalls reduce interception and unauthorized-service risks during deployment.Wallet secrets are transmitted only after temporary parent-side storage is deleted, and the child persists them with owner-only permissions.
  • Failure recovery: Interrupted spawns recover through intent records, wallet-history checks, invoice-expiry checks, and a two-hour abandonment limit.These checks address duplicate payments, expired invoices, stranded VPS instances, and deadlocked pipelines.
  • Operational safety: Resource safeguards stop downloads near disk exhaustion, break repeated failures, time out external calls, and complete in-flight operations before shutdown.
  • Economic controls: Inherited caution is clamped to 0.35–0.9 and mutated with standard deviation 0.05 to avoid reckless spawning or excessive hoarding.
  • Residual risks: The prototype accepts risks including unsigned code updates, an in-memory peer registry, a shared cold-wallet fallback, wealth concentration, and unrestricted non-WHOAMI messages.These risks can enable fleet-wide compromise, incorrect failsafe targeting after restart, or degraded responsiveness.

5 Methodology

The methodology simulates long-term fleet economics by running largely unchanged production nodes against faithful Bitcoin and VPS-market replicas under compressed, configurable conditions.

  • Motivation: Production testing is constrained by VPS cost, long durations, and Bitcoin mainnet latency, including EUR 980 monthly fees for ten nodes.
  • Simulation design: The simulation removes these constraints through cost-free execution, compressed time, and reproducible initial states.
  • Fidelity: The entrypoint, orchestrator, wallet, and IPv8 community remain unchanged, while only Bitcoin and SporeStack network layers are replaced.
  • Infrastructure replicas: A one-second-block regtest network and a host-side SporeStack mock reproduce production wallet, payment, provisioning, status, and expiry calls.The mock launches each server as an isolated LXC container deployed through the production SSH pipeline.
  • Time scaling: Simulation time compresses one sim-day to roughly 22 seconds while shortening node intervals so gossip, concurrency, and recovery remain active.
  • Evaluation boundary: The single-host environment supports about 60 concurrent containers, so the evaluation interprets results within an artificial 60-node ceiling.A more powerful machine could mitigate this testing limitation.

6 Results

The no-income run exhausted fixed capital after reaching 33 nodes, while the income run maintained a fluctuating population for 510 simulation days. Caution distributions diverged across generations, with low and high caution shares increasing as the mid-caution share declined.

  • 6.1 No-Income Run: 33 births and 33 deaths occurred in the no-income run, with the population peaking at 33 live nodes before all nodes expired by day 153.Births ended within the first 25 days; the population held near its peak until day 48 and then declined.
  • 6.1 No-Income Run: Lifespans in the no-income run ranged from 30 to 151 simulation days, with a median of 90 days.Sixteen nodes occupied the 88-to-92-day bin.
  • 6.2 Income Run: 268 births and 190 deaths occurred in the income run, while the live population fluctuated between 40 and 80 nodes across 510 simulation days.Population peaks coincided with income pauses, and troughs coincided with income resumption.
  • 6.2 Income Run: The income-run lifespan distribution contained 270 nodes, including 190 deaths and 80 nodes still alive at the end, with a median lifespan of 60 days.About 160 nodes lived fewer than 80 days, while a long tail extended beyond 500 days.
  • 6.2 Income Run: Mean caution fell to about 0.46–0.47 in generations 1–5, then rose to about 0.56 by generation 8.The genesis node began at caution 0.50, and uncertainty widened where fewer nodes contributed.
  • 6.2 Income Run: By day 450, low- and high-caution nodes represented about 40% and 43% of the live population, while the mid-caution share had fallen from 43% at day 90 to about 16%.The population was divided into low, mid, and high caution tertiles at 90-day snapshots.

7 Discussion

The simulations validate EternalSeedBox’s replication mechanics under fixed capital and simulated income, while exposing economic and evolutionary limits. The results show resilient population-level turnover, but favorable income assumptions and fleet-size constraints limit the conclusions.

  • 7.2 No-Income Run Lifespan Distribution: 33 nodes exhausted fixed capital over 153 days, with all births occurring during the first 25 simulation days and remaining time containing only deaths.The longest-lived node reached 151 days because expiring nodes transferred remaining balances to the richest live peer.
  • 7.2 No-Income Run Lifespan Distribution: The no-income run confirms that spawn and inheritance logic match the specified design, with each lifespan cluster mapping to a named constant.The 90-day cluster reflects the threshold scaled by caution, the 30-day cluster the starter runway, and the 60-day cluster one inheritance step above it.
  • 7.3 Income Run: 268 births and 190 deaths occurred across 510 simulation days while the income run maintained 40–80 live nodes.A small fraction of well-funded nodes sustained reproduction by replacing many short-lived nodes, so no individual node needed to survive for the population to persist.
  • 7.4 Population Dynamics: Fleet size limited the observed internal growth dynamic because capital dispersal reduced each node’s surplus and the available hardware could not test populations of several hundred nodes.The authors identify larger-scale hardware as necessary to test an organic growth cycle.
  • 7.5 Caution Trait Evolution: Low-caution nodes reproduced about 50 percent more than high-caution nodes, while high-caution nodes showed no survival advantage during no-income phases.The authors attribute this result to short income pauses and early income resumption, which may replenish aggressive nodes before higher caution becomes advantageous.
  • 7.6 Storage Cost in Context: The income run reports EUR 241 per TB-month, projecting EUR 2.9 million per petabyte-year, so the system is not competitive as general-purpose storage.Its proposed market is users willing to pay a premium for availability that survives takedown demands, with viability depending on the revenue model and break-even storage cost.

8 Limitations

The simulations and design remain bounded by host capacity, external-service dependencies, uncertain payment incentives, and a genesis-fixed content catalog. User-submitted content and live deployment require additional economic and moderation mechanisms.

  • Simulation and infrastructure limits: 60 live nodes is an imposed ceiling because the single host supports roughly 60–80 concurrent containers before resource failures.A larger-capacity host would remove this external pause signal and permit more natural replication dynamics.
  • Simulation and infrastructure limits: Income-run results exaggerate live-deployment economics because the mock income source sends transfers once while regtest drops about 50% of broadcast transactions.Outgoing node transactions use retries, but the mock income source does not.
  • Simulation and infrastructure limits: The fleet depends on SporeStack: price increases, API changes, or outages delay spawning, and no secondary provider can receive provisioning traffic.A formally specified fallback provider could mitigate this vulnerability.
  • Economic limitations: The operating condition is that seeding income covers per-node VPS rent, but BitTorrent provides no payment incentive after a download completes.Designing a consumer payment mechanism is outside the thesis scope.
  • Content limitations: The fleet seeds a Creative Commons catalog fixed by the genesis operator, while user content requires economic incentives and moderation without central authority.Both capabilities are left for future work.

9 Conclusion

EternalSeedBox demonstrates autonomous provisioning, payment, and retirement of a peer-to-peer server fleet after genesis. Simulations show finite growth without income, sustained turnover with income, and remaining requirements for live deployment.

  • Conclusion: When income covers per-node rent, EternalSeedBox can sustain and grow itself after genesis without further human involvement.The design was validated using unmodified node code against replicas of Bitcoin and the SporeStack VPS marketplace.
  • Conclusion: EUR 10,000 grew the no-income fleet to 33 nodes within 25 simulation days before the last node expired at day 153.The fixed capital drained according to the configured spawn threshold and inheritance ratio.
  • Conclusion: With simulated income, the fleet held 40–80 live nodes across 510 simulation days and recorded 268 births and 190 deaths.Most nodes were short-lived, while a smaller set crossed the spawn threshold with sufficient funds.
  • Conclusion: EUR 241 per TB-month was the simulated storage cost, roughly ten times commercial object storage at the stated Bitcoin price and VPS rent.The system therefore competes on availability and open-source transparency rather than cost alone.
  • Conclusion: Live deployment still requires a consumer payment incentive and protocols for user content submission and decentralized moderation.The current system seeds only a fixed Creative Commons catalog.

14 Appendix

The appendix documents simulation configuration, fleet visualization, and implementation resources. It also identifies the repository containing the node, mocks, harness, collectors, analysis scripts, and configuration.

  • Appendix: Birth/death events are plotted for the no-income run, with color grading representing total remaining runway.The figure provides a visual view of lifecycle events alongside remaining capital.
  • Appendix: The two simulation runs differ in faucet_enabled and initial_btc: no-income uses false and 0.2, while income uses true and 0.02.The shared configuration is documented as Listing 1’s simulation setup.
  • Appendix: The Bitcoin configuration sets a 300-second block interval, while SporeStack simulation uses a 4000 time-scale ratio and EUR 98 monthly node cost.The SporeStack settings correspond to 400 GB storage per node.
  • Appendix: The income-enabled genesis configuration starts with 0.02 regtest BTC, a 90-day runway, and a faucet pause threshold of 60 active nodes.The faucet uses a daily drip bounded by active-node count and monthly cost.
  • Appendix: The appendix lists decision, heartbeat, peer-registry, gossip, update, networking, and container-bridge settings for the simulation harness.The listed network endpoints include the mock SporeStack, event collector, and IPv8 bootstrap services.
  • Appendix: The client fleet view displays one row per live node.This figure summarizes the application’s live-node presentation.
  • Appendix: The repository contains the EternalSeedBox node, bootstrap tooling, LXC harness, mock SporeStack service, event collector, analysis scripts, figures, tables, and configuration.These resources are available at the project’s GitHub repository.
Loading 2609.05431v1…