Bitcoin maximalism - spinoff technology

[sfultong]

I just joined the forums, so I apologize if there's already a thread for this, or it should be posted elsewhere.

As Peter R first described in:
https://bitcointalk.org/index.php?topic=563972.0

I'm developing a "bitcoin spinoff toolkit" for creating new blockchains of other cryptocurrency technologies, where the genesis ledger is a snapshot of the bitcoin ledger.

Along with this toolkit, I'm developing a proof-of-concept fork of litecoin that uses this toolkit. I plan to release this proof of concept in about a month.

 

[sfultong]

Relevant github:
https://github.com/sfultong/bitcoin-spinoff-toolkit
https://github.com/sfultong/bitcoin/tree/blightcoin

I called the litecoin fork "blightcoin" because it amuses me, but I probably should be more serious and brand it to be something people would want to use.

 

[Zangelbert Bingledack]

Excellent! Spinoffs are an idea whose time may be about to come, hopefully not quite yet but we should start preparing for the eventuality.

 

[Peter R]

Welcome to the forum, @sfultong! Looking forward to seeing your progress with a spin-off.

 

[awemany]

Excellent. I see, I should actually start to look into threads besides my PMs, GCBU and WO

A question out of pure ignorance and not having looked at anything yet: Have you implemented a safeguard into your spin-off code so that transactions that will be signed as valid on a spin-off are not valid on any other chain?

I think each spin-off would basically need some 'magic bytes' that are signed as part of any transaction - and make the transaction invalid anywhere else.

 

[sfultong]

I have not implemented such a safeguard. I wanted to get this out the door as quickly as possible, with few risks of creating new security issues.

The easiest thing to do from my standpoint is advise users to send all their bitcoins to a new address (or addresses) after they've imported their private keys from bitcoin. That reminds me, I should write a special rpc just for importing bitcoin private keys.

This litecoin spinoff will be different from spinoffs created for cryptocurrencies not based on bitcoin originally. I wanted to have all the transaction signing code done in the bitcoin spinoff toolkit library, but this is unnecessary for litecoin.

 

[awemany]

Thanks for the note. This sounds harsh maybe, but spin-offs are completely unusable for me without that feature. You already have some risk transacting on such a chain by exposing your pubkey and possible priv key entropy.
Adding the risk, or rather certainty of experimental transactions on such a spin-off being 'backported' to Bitcoin makes them a total no-go for me.

 

[sfultong]

Well, to be clear, you wouldn't be able to backport transactions made in the litecoin spinoff to bitcoin, because the snapshot transactions wouldn't be present in bitcoin.

The risk would only apply to two different spinoffs created utilizing the same pubkeyhash signing as in bitcoin, where both the amount and the pubkeyhash were identical.

So there is a risk, it's probably just less than you imagine.

 

[awemany]

Yes, understood. But that's exactly what you could fully prevent by making a small field (4 byte or so) of a magic field in each transaction mandatory in the spin-off - and signing only transactions including that magic field.

 

[cliff]

Self-Moderated - Will save this idea for a later date.

 

[Zangelbert Bingledack]

@sfultong

For an experiment that is fine, but for actual implementation it's a non-starter to have people expose their Bitcoin pubkey by forcing everyone to move their stash in order to participate in the spinoff. Hodlers gotta be able to sit tight. People will be choosing the best spinoff, so you can't really afford to leave out necessary features if you want adoption.

 

[sfultong]

Now, I am far from an expert on cryptography, so if you know more than me, please correct me...

But AFAIK, it's impossible to do the spinoff idea without exposing your public keys. That's the way keysign verification works with secp256k1: you take a stream of bytes and a signature signing those bytes, and from that you can recover a public key.

You're going to have to move your stash in both a spinoff and bitcoin itself one right after the other, to be truly secure.

This is unfortunate, but I still think it's worth it do a spinoff.

@awemany I'm not going to do the magic field for the litecoin spinoff, because it would greatly complicate things. I'll do it for the next spinoff, though.

As I've stated before in other places, I'm not the best C++ programmer, so I'm trying to be very conservative here with the amount of new code I write. If anyone here is a good C++ programmer or wishes to contribute in other ways, I'm welcoming help.

 

[Zangelbert Bingledack]

As I understood spinoffs, the same private key simply controls the coins in both chains. So yeah if you spend the coins in one chain you may want to hurry and move the coins in the other chain, but if you are just holding I thought you don't need to do anything.

 

[sfultong]

@Zangelbert Bingledack Oh, yes, you're right. As long as you don't move the coins in one chain, you should be fine.

 

[awemany]

With the sig, you expose your pubkey and possibly priv key entropy, so there is that risk. Small (like bitcoinocracy.org shows), but it is there.

However, for a couple mBTC, one might play around with such a spin-off.

But for a spin-off to have *any* worth at all, you really do *not* want to sign transactions that are valid both on the spin-off and on the main chain. Because this will IMO lead to immediate confusion and people losing their coins on the main chain. Or rather, and to reiterate: No one is going to be interested in such a spin off. Its of course up to you, but I consider this an absolutely essential part of any spin-off idea.

If you put in a new mandatory field into every transaction of your spin-off, that makes the signed data clearly incompatible with anything on the Bitcoin main chain, this would then allow people to sign just transactions on the spin-off or just on the main chain. Clean separation.

 

[sfultong]

I'm not sure what you're worried about, @awemany. I said above that transactions in the spinoff wouldn't be valid in bitcoin... unless you're worried about some random transaction hash collision?

 

[awemany]

@sfultong: Ah, ok, my fault, then I was misreading what you wrote above.

 

[sgornick]

Why is nobody making Bitcoin-XTS ... a Bitcoin spin-off implementing block sizes from BIP 101 (and other Bitcoin-XT changes, such as relaying double spends)?

I wouldn't doubt it would get plenty of miners giving it a try (especially those solo and hobby mining) that it might just find enough hashing to hold its own as an altcoin.

 

[YarkoL]

@sgornick
In a sense, if and when a hard fork occurs,
XT will be a spin-off, with a snapshot of the ledger taken at the fork time.
(But the same can be said about Core, depending on your view!)

If there is a "real" Bitcoin, it is embodied in the blockchain/ledger...

 

[AdrianX]

@Zangelbert Bingledack Oh, yes, you're right. As long as you don't move the coins in one chain, you should be fine.

This presents an interesting economic incentive with regards to where to take the snapshot.

I always imagined that the announcement of the snapshot date to be important. One reason being you may want to have your coins stored on Keys you control on the date. Say you use an exchange that has exclusivity told you they will keep all PoS interest or any coin derivatives one would logically move them to maximize your spin-off stake.

like wise I also felt there may be a motive to set it to a random date in the past, one the developers would know but not the public, that would be a way to capitalize on launch. I imagine the motive to be something like mitigating demand for the seed chain on the day of launch.

Now that I think of it, this adds an security incentive and a benefit to always use a fresh snapshot date that occurs after any other previously announced snapshots.