Design notes for sharing work between multiple independent chains

[Dusty]

(watching)

[1715155497]

1715155497

[1715155497]

1715155497

[1715155497]

1715155497

[1715155497]

1715155497

[1715155497]

1715155497

[theymos]

So you don't think miners will forget DNS transactions.

They can't be forgotten when you're limited to standard scripts, but if non-standard scripts were usable, you could spend the 0-value outputs to make the network forget about them. Yet another reason why IsStandard should be removed.

[jtimon]

So you don't think miners will forget DNS transactions.

They can't be forgotten when you're limited to standard scripts, but if non-standard scripts were usable, you could spend the 0-value outputs to make the network forget about them. Yet another reason why IsStandard should be removed.

I'm not talking about the current bitcoin code but about what miners could do within the network protocol.
Anyway, I've not read the bitcoin code yet, So I'm not sure I've understand what you're saying.
You want 0 value outputs to be remembered until the receiver sends them out?

I thought bitDNS would use one transaction output (with 0 value) for storing the the DNS data (the IP, the URL and whatever else is needed) and other output for "parking" some coins and "lock" the transaction, preventing it to be forgotten.

What is the incentive for miners to remember 0 value outputs?
When they receive a transaction with an input that they don't know but that input doesn't add value to the transaction, they can just accept it as good.

That is assuming that miners will never forget outputs with values greater than zero. Maybe they could take the risk of accepting blocks they cannot completely verify if that increases their hash rate.

[theymos]

I thought bitDNS would use one transaction output (with 0 value) for storing the the DNS data (the IP, the URL and whatever else is needed) and other output for "parking" some coins and "lock" the transaction, preventing it to be forgotten.

No. The 0-value output is used to store data. The other output is used to show ownership: you send this coin to transfer the domain. You also need to send the valued output for every new BitDNS command.

The valued output isn't necessary for "locking". A transaction can have just a 0-value output and still be "locked".

Our BitDNS spec wastes a lot of space because the 0-value transactions will exist forever. They can't ever be redeemed. But this is only necessary because our spec -- designed to work with current code -- writes the outputs in such a way that they are irredeemable. If script could be used freely, the 0-value outputs could both contain data and be redeemable. This was the original design, in fact, but IsStandard was created while we were writing it.

You want 0 value outputs to be remembered until the receiver sends them out?

What is the incentive for miners to remember 0 value outputs?

Miners must know all unspent transactions, or else they risk ending up in a situation where they need to verify a transaction but are unable to do so. If this ever happens, they will have to stop mining until they get the needed transaction, which might be difficult.

When they receive a transaction with an input that they don't know but that input doesn't add value to the transaction, they can just accept it as good.

Inputs don't state what its value is, so the miner can't know that it's a 0-value input if it can't see the associated output. It would be clear that no value is taken by the outputs, but you can't determine the fee, which is necessary for verifying blocks. (Rejecting transactions like this is also impossible for other reasons.)

Maybe they could take the risk of accepting blocks they cannot completely verify if that increases their hash rate.

Forgetting transactions will usually slow down mining somewhat, and sometimes it could cause very unprofitable things to happen.

Example:

You are using a client that forgets unspent 0-value transactions after a while. 10% of the network is also running that code. I create a block with a transaction that redeems a 0-value transaction, and most of the network builds on my block. If you reject my block, you are isolated from the network. If you reject my block initially, but start working on it later on, you've just wasted a ton of hashing work. If you accept my block blindly, and it turns out that the transaction is actually invalid later on, you've just wasted a ton of hashing work. Your best option is to immediately find the transaction being redeemed so you can verify it. First, you'll contact your peers to see if they have it. If they don't, you'll have to connect to more peers. Maybe you'll use an archiver service. This is a second or two of wasted hashing time per transaction you need to look up. An attacker might create lots of these transactions just to mess with you.

You actually end up giving up quite a bit of mining power for some disk space.

If your side has more than 50% of the network's computational power, your side can reject transactions with impunity for as long as it is in control.

[phathash]

This sharing of work... are you saying that a % of hashing would be pushed off to the other chain.. or, that useless hashes (ie that don't satisfy bitcoin difficulty) would somehow satisfy a smaller difficulty in another chain?

[jtimon]

When they receive a transaction with an input that they don't know but that input doesn't add value to the transaction, they can just accept it as good.

Inputs don't state what its value is, so the miner can't know that it's a 0-value input if it can't see the associated output. It would be clear that no value is taken by the outputs, but you can't determine the fee, which is necessary for verifying blocks. (Rejecting transactions like this is also impossible for other reasons.)

Imagine a transaction like this:

input 0: tx A output 0 [unknown by the miner]
input 1: tx B output 1 [known by the miner] 10 btc
input 2: tx C output 0 [known by the miner] 5 btc
output 0: address X, 14 btc
fee: 1 btc

The miner could just ignore tx A since it doesn't add value to this tx.
Can he accept this transaction as good even if he doesn't have tx A?

Maybe they could take the risk of accepting blocks they cannot completely verify if that increases their hash rate.

Forgetting transactions will usually slow down mining somewhat, and sometimes it could cause very unprofitable things to happen.

Example:

You are using a client that forgets unspent 0-value transactions after a while. 10% of the network is also running that code. I create a block with a transaction that redeems a 0-value transaction, and most of the network builds on my block. If you reject my block, you are isolated from the network. If you reject my block initially, but start working on it later on, you've just wasted a ton of hashing work. If you accept my block blindly, and it turns out that the transaction is actually invalid later on, you've just wasted a ton of hashing work. Your best option is to immediately find the transaction being redeemed so you can verify it. First, you'll contact your peers to see if they have it. If they don't, you'll have to connect to more peers. Maybe you'll use an archiver service. This is a second or two of wasted hashing time per transaction you need to look up. An attacker might create lots of these transactions just to mess with you.

You actually end up giving up quite a bit of mining power for some disk space.

If your side has more than 50% of the network's computational power, your side can reject transactions with impunity for as long as it is in control.

I would accept your block and if it turns out that the transaction is actually invalid later on, I've wasted hashing work.
I would balance the risk of wasting hash power by accepting invalid blocks with the gain in hashing power for not bothering about old transactions.
This can be done not only with 0-value outputs, but with any old transactions.
If I receive a transaction that I cannot verify, I ignore it (don't include it in my block), because otherwise my block could be rejected as invalid.
I just accept transactions that I cannot verify when it's in another block.

The question that remains is...
Is the gain in hashing power for not bothering about old transactions powerful enough to allow miners to forget old transactions?

[theymos]

The miner could just ignore tx A since it doesn't add value to this tx.
Can he accept this transaction as good even if he doesn't have tx A?

The fee is not specified directly by the transaction. It is calculated by looking at the difference between input value (which is also not specified) and output value.

Ignoring the other problems with doing this, you could accept the transaction into your own blocks without knowing the exact fee, but you could not correctly verify other blocks that include the transaction. For all you know, the transaction you've forgotten permits a fee of 1000 BTC.

I would balance the risk of wasting hash power by accepting invalid blocks with the gain in hashing power for not bothering about old transactions.

You don't gain any hashing power. Only disk space, which is cheap.

[jtimon]

The fee is not specified directly by the transaction. It is calculated by looking at the difference between input value (which is also not specified) and output value.

Didn't know that.

I would balance the risk of wasting hash power by accepting invalid blocks with the gain in hashing power for not bothering about old transactions.

You don't gain any hashing power. Only disk space, which is cheap.

Then I don't understand why people said in the demurrage fee thread that miners will forget transactions.

Thank you for all the clarifications.

[theymos]

Then I don't understand why people said in the demurrage fee thread that miners will forget transactions.

If storage ends up being really expensive (which I doubt), miners might use demurrage. I think it's a good solution for that (unlikely) case, in fact.

More than 50% of the miners need to agree before actually forgetting transactions, though. Otherwise you'll get the problems that I've described.

[ByteCoin]

More than 50% of the miners need to agree before actually forgetting transactions, though. Otherwise you'll get the problems that I've described.

The problems you outline presuppose that the miner is trying to include as many transactions as possible. The miner can just shun transactions that use inputs it has forgotten. Unless these transactions contain substantial fees then the miner is not losing out significantly. The underlying problem is that the incentives for miners to include transactions are currently weak.

Taking the "miners forgetting transactions" to its logical conclusion, you could probably run a miner in the current bitcoin environment that neither verifies signature nor stores the block chain. It would assume that all incoming transactions are correct as they have probably been verified by someone else. To prevent an obvious poisoning attack, it could maintain more than one separate anonymous connection to the network and only accept transactions that appear on both.

ByteCoin

[theymos]

The problems you outline presuppose that the miner is trying to include as many transactions as possible.

No. In my posts in this topic, I have always assumed that the miner will never include the transaction in his own blocks. I am only concerned here with what the miner will do with other blocks with transactions he can't verify.

[marcus_of_augustus]

Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?

Is that the desired outcome?

[BitterTea]

Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?

Is that the desired outcome?

I don't think so.

perhaps BitCoin can just do what Slushs pool already does and vend work of min(bitcoin difficulty, extra difficulty) then ignore found blocks that don't match BitCoins own difficulty

The only thing that I know I don't understand is how you are able to compute only one hash but have the solution be valid for either block chain.

[marcus_of_augustus]

a) Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?

b) Is that the desired outcome?

I don't think so.

"You don't think so" to part a) or part b)?

[BitterTea]

a) Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?

b) Is that the desired outcome?

I don't think so.

"You don't think so" to part a) or part b)?

Neither part a nor b.

I think the desired outcome is that with just a single hash computation, a miner could potentially generate a valid block on any chain connected in this way.

[marcus_of_augustus]

a) Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?

b) Is that the desired outcome?

I don't think so.

"You don't think so" to part a) or part b)?

Neither part a nor b.

I think the desired outcome is that with just a single hash computation, a miner could potentially generate a valid block on any chain connected in this way.

Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised

[BitterTea]

Ok, yeah, that clicked. I think you're right. The goal is to maximally secure the most block chains with the least effort.

[jtimon]

Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised

This reasoning is correct, but you're assuming that the block rate in the alternate network is the same as in btc (10 min per block).
That's not necessarily true.

[ShadowOfHarbringer]

(Added to watchlist)

[marcus_of_augustus]

Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised

This reasoning is correct, but you're assuming that the block rate in the alternate network is the same as in btc (10 min per block).
That's not necessarily true.

Good point, thanks for that.

So, choosing the block rate of an alternate chain utilising the same hashing network, is tantamount to choosing it's difficulty ratio with the main BTC chain.

And I propose that this maybe "fix" its relative security, desirability and thus price relative to BTC. E.g. The alternate block chain could have a block rate of 1 per minute (faster confirms) but it's network difficulty would be 1/6th that of BTC and thus it would trade at approx. 1:6 ratio with BTC.