this' already clear on post #0

Yes the transactions couldn't be just copy-pasted on B, since the whole point would be to change into a different signature.

On the purpose on keeping Bitcoin-A, it would be for being conservative regarding such change into B. Ofc A would still be a hard-fork from the original, and users would still be required to keep keys from both A and B in order to just use A, but oh well. I'd say it's for the sake of not jumping entirely into B, or to still keep having one feet at A. 

I think this is the closest to having a B as backup while being as inertial as possible on the original.

This is a simple and small idea, but not that it necessarily could/should be implemented.
Related to the prevention of quantum attack on the cryptography, on some hypothetical situation where all of the private keys of the entire history are calculated and published, which would render the entire history useless.

Let Bitcoin ("original" Bitcoin) be forked twice, into Bitcoin-A and Bitcoin-B.
Bitcoin-A operates mostly identically to Bitcoin-original, so it is sort of it's "successor".
Bitcoin-B will be the watchdog, it will use a more (likely) quantum-resistant crypto for the ownership/spending.
When someone spends on Bitcoin-A, that person will also have to replicate/translate that transaction on Bitcoin-B. When blocks of A are being formed, only transactions that are duplicated in B are allowed in A. And a markle tree root (or something) from Bitcoin B's "block" must be present in Bitcoin A's block - and ofc validators from A would have to "read data" from B to function.
Then initially, Bitcoin A is the source of truth, and Bitcoin B follows that truth arbitrarily.

Let's say one day all of the keys from Bitcoin A are exposed. So Bitcoin A's history goes to the trashbin, but the users can, say, rollback a few days and switch into Bitcoin B, and then B would now operate independently from (the now defunct) A - assuming B survives that attack. This could also help to inhibit the attack in the first place, since there would be a backup around.

What you think?

Hi aleksej, I meant not to change bitcoin mining in any way, but for nodes to, instead of throwing the best PoW away (when failing to mine that round's block), to send the failed block to one connected peer (this will work better for small blocks, with just a handful of transactions in the block's body).

With that particular coinbase and considering the exchanged information, the connected peer can verify that the failed block's miner was doing it dedicated to that peer. Since the miner must choose who is getting his dedication on each round, this seems suitable for preventing spam. And it will increase the network's hashrate. I believe a higher hashrate is certainly good for the network.

This doesn't change the reward mechanism, but would be a soft-fork instead, where nodes will require higher dedication (when under message or bandwidth stress) in order to communicate with other peers at all.

This is the idea that a failed block is still lightly useful (not for Bitcoin purposes, but for networking): a spammer will increase bitcoin's hashrate, increasing it's security. On the other hand, as you said, "miners are allowed to spam"; and "spammers may get rewarded" (by actually mining bitcoin), which kind of sucks, but well..

edit:
> But I see that you are proposing a single mining system where you get rewards in Bitcoin for your anti-spam efforts.

Well, mining has always been spam prevention: preventing blockchain block insertion spam. And also functions to increase older data immutability certainty.
PoW has always been used for more than one purpose..

edit: if some block limit of ~100kB is considered (for dedicatory purposes), then it's likely that "actual miners" won't bother letting go of 900kB for a "you may spam the network free pass card". That is, anti-spam + mining would intersect under 100kB, but >100kB would still be just plain mining. Since "serious business" miners will have more than enough "dedication credit", they won't miss it.
This will at least lower bitcoin rewards for lucky spammers.

[text also on github: https://github.com/swfsql/btc-opinions/blob/gh-pages/pow-recycling.md]

---

Was reading this: hackingdistributed.com/2017/02/23/green-blockchains#piecework-recycling-pows

And this looks like a good idea. Under messages or bandwidth flooding, requiring some PoW for simple message passing helps.
One way to have that is to recycle mining. On the other hand, mining tends to be, even if inneficient, maxed out (have higher hashrate than otherwise).

Assume a standard node Std, and a low-end, average joe node Joe. If Joe can afford to do _any_ tx validation, he does; if he can't, he doesn't--just go with the coinbase. Then Joe and Std trade bitcoin addresses public keys, such that: 
**Ja** -> _JA_ {**Ja** is Joe's private key, _JA_ is it's public key} 
**Sa** -> _SA_ {**Sa** is Std's private key, and so on..} 

Then Joe grabs _SA_ and uses it as a private key **Ja'**, so: 
**Ja'** -> _JA'_ {so that "private key" has it's own public key} 
and then: 
**Jb** = **Ja** + **Ja'** {Joe sums his and "his other" private key (on Std's knowledge), getting a new private key} 
**Jb** -> _JB_ {and that has a public key} 
_JB_ = _JA_ + _JA'_ {and such public key is also the sum of _JA_ and _JA'_; learned about this magic from mimblewimble} 

Then Joe may mine and target the coinbase to an address that comes from _JB_. Even if he doesn't mine in time, he keeps mining it, until he gets enought PoW required by Std. Or, he still keeps his best PoW form each mining round, and stashes it, until it's enought PoW as a folded sum of PoW iterations. Also, if he has many connected peers, he may spend each mining round to one of his peers (since each would have a different _SA_ or **Ja'**).

Assuming Joe fails to mine in time, he can still announce Std that round's header, with his best work proof. Since Std has _SA_ or **Ja'**, he also has _JA'_. If they exchanged both _JA_ and _SA_ among each other, Std may verify that _JB_ is indeed _JA_ + _SA_, so it was indeed a work trying to prove to Std (to himself). 
Joe still has **Jb**, whereas Std doesn't, so Joe's rewards should be safe if he actually mines it. 

So each node may track the peers "dedicated" Proof of Work, recycled from mining, as an anti-spam measure.

Hi, you're welcome!
What do you mean by posting in one thread?
I didn't post anything else elsewhere, so I believe all the information is in the post itself.

Updated! Added the miners impact and their unique capability when considering the charge units; Also organized the function suggestions.

# Definition

Bitcoin hodls is a hodl quantity that a given unspent bitcoin transaction output has. It requires a wallet soft-fork and some analysis over the blockchain data, particularly over the transaction-chains hidden inside of it - then the user's hodl units (and their price) could be optionally shown.

# Creation function

A hodl is produced when a user timelocks their own unspent transaction outputs - he forbids himself of transfering it, thus the unit name. From that satoshi ammount and (block)time duration, some hodl quantity is created according to some function.
The function (satoshi: i64, duration: u64) => satoshi * duration/2016u64 looks simple enought to me (where 2016 is the bitcoin's dificulty's recalculation cycle period; the return value could be u128 bits).

# Explanation

Pieces of gold may be pure or diluted, metals may be bright and colored or grey, batteries may be charged or empty, tuna may be fat or slim, and game characters may be experienced or a newbie. We can apply the same kind of concept in various ways into bitcoin, and one of those is the result (or appearance) of the hodl quantity.
Just like gold purity, it's part of the piece's characteristics. Sure players aren't required to not ignore any characteristic they want to. But again, just like gold purity, the hodl quantity is one characteristic - like a "physical" one -  that does exists, whether we choose to ignore it or not. This is because all value is subjective, and bitcoin must be, entirely, be reasoned about (subjectively interpreted) - or it's nothing more than numbers at random that have no meaning within themselves.

So I'll let myself name hodl units as bitcoin charges, and timelocking as charging.

# Usage

A charge quantity is attached to each bitcoin transaction's output. For simple init, it's on the bitcoin itself. So if I charged one bitcoin for a a difficulty cycle period, that bitcoin has 1 charge * bitcoin/satoshi units. If I send you that bitcoin, you've got a bitcoin plus it's charges. Other usecases are discussed later.

## Impact (subjective)

The appearance of charges fits well with the hodlers position regarding bitcoin trading. It's also a chance to have this kind of extra valuation from that very positioning.

What is objective though is the possibility of dismissing the homegeonity of bitcoin units. If ever desired by bitcoin users, they may (even only temporarily) increase their subjective price valuation over charge units in order to fight an eventual and suspeciously strong short positioning of cash settled bitcoin futures beign traded. Those future trades will start to lose purpose if some of the subjective valuation jumps into bitcoin charge units. This would make it impossible for a cash settled future market to exist, they'd be forced to use bitcoin itself, and this could, at some point, be important to the network.

In fact, a decision to charge your bitcoins is a partial "future trade" decision, where you take the price variance risk but get the charged units in return. That is, you may bet the unit's price will be superior to the price of the risk of not being able to move your bitcoins for some time.

## Lightning Network combination

Since bitcoins in Lightning Networks are timelocked, they may also charge bitcoins, so the two could fit well together. This is why I preffer calling hodls as charges.

## Other transfer usecases

Charge units aren't really on bitcoins but on unspent transaction inputs/outputs. So if I gave you a bitcoin + 10 charges, you may split that bitcoin in half (thus also splitting the charges units in some way). Also, you may receive bitcoins (as a single unspent output) from various inputs (thus merging inputs means merging charges in some way).

### Transaction function

For a given transaction, to sum the input charges and then to equally distribute them according to each output satoshi ammount looks simple enought to me. That is, if bitcoins were electrically charged metal balls, you just group them altogether before merging and splitting into the outputs holes (they would end up with the same charge density).

#### Miners

• fee transactions have no charges since they are not an output, so a given transaction bitcoin fee appeal won't be changed;
• only them may increase a bitcoin's charge density, when mining a block with a private transaction that uses a desired (high) ammount of fee rate. I expect that a fixed density would be desired for some traders;
• some will decide to create create fee-only private transactions. This would fully separate the charges from the bitcoins, but the charges would have nowhere to go. So another cryptocurrency could be created out of that, where it has a charge-only currency and requires some reading over the bitcoin's blockchain data (a parasyte blockchain).
• if a charge decrease is desired, negative fee rate could be allowed (hardfork in bitcoin), where the transaction's output comes from the coinbase - so only miners would still be able to do that.

So even without a node/miner soft/hardfork, miners still have a (optional) specific function and their user behaviour might be impacted.

# light node

Since the chaining of transactions inputs and outputs must be analysed, initially the full blockchain must be read, but read spent output can be prunned away. So a data structure can be layered on top of the blockchain, containing the unspent output's charges information. So the ~60Mtx (according to https://blockchain.info/charts/utxo-count), would consume ~3GB of information (32B txID, 1B outputID, 4B charges), or a light node.

---

I hope you enjoyed! Also posted it on github: https://github.com/swfsql/btc-opinions/blob/gh-pages/bitcoin-hodls.md

I think it's not stealing for both cases because I think it wasn't a private property of some previous owner, it just happened he had the priv. keys, and now you also have. I tried to give a better explanation here: https://bitcointalk.org/index.php?topic=1598043.0

According to the idea that bitcoins exists in our "minds", what is happening is that you are able to communicate "to the air" and other people will hear that and they will arbitrarily decide to change their memory of the mental blockchain. So you can't be a theft just by saying some words to the air, while you're not taking any private property away from anyone. You are not more blamable than the people who decided to give their interpretation to your meaningless speech, and decided to ignore the (now) useless effort of the previous owner to re-spend his bitcoins.

Let's change the story: what if I'm walking in a mall, then I say something like "it's so could here", but some random guy hears me and thinks I said that I ordered him to go and kill random people. The interpretation he gives to what I said is his own business, I have nothing to do with his actions. But in the bitcoin case, the messages aren't "propositional" and there's not even private property aggression, anywhere. So in the bitcoin case I'm far more secure that it's not a wrong-doing.

Well, I think it's ok to think that way IF you consider that btc aren't priv. property. If not, if they are, then yes I would consider it a theft for both cases.

---

I very similar situation is when someone wrongly sends you some bitcoin, in a address you didn't expect any donation. Would you send it back? I mean, he could still just be donating random ppl some btc, but its very likely he is not. And if you consider it a donation, then (maybe) you can consider that everyone who participates on the blockchain are also donators to whoever have "their" private addresses.

I get your point. But I'm not sure we should use the word "right" as a "positive right", as some people (governments) could enforce this right (and be aggressive toward some people).

---

I have one more example that could actually arise in reality:

> B sends money to A (and A sends "something" or some information to B). Then, we don't know why, everyone decides to change their Bitcoin rules and the result is that A can't get to spend his money in the new version.

So does A have a right to force other participants to use his arbitrary version of the Bitcoin, in order to be able to spend his money? I mean, could his justification of "I have the right to spend those bitcoins" be used while he attacks other people when trying to force them to change their stuff on their computers? I'm thinking about governments behavior and analogous justifications. Since I believe that bitcoins aren't priv. prop., that kind of justification is wrong.

I'm talking about the money kind of bitcoin.

Some situations where the bitcoin status of being a private property or not could arise:

> A mistakenly sends bitcoins to B, and A finds out who B is.
> A mistakenly shows his private keys to B (by just saying it), and A finds out who B is.
> B executes a replay attack on A.
> B, by an practical impossible luck, creates a private key that had founds that belonged to A already.
> B sends money to A (and A sends "something" or some information to B). Then, we don't know why, everyone decides to change their Bitcoin rules and the result is that A can't get to spend his money in the new version.

I started an article (here) trying to defend the idea that bitcoin is not private property, therefore all of the examples above couldn't be classified as theft or robbery (of private property).

What do you think?