Author

Topic: [IDEA] A new standard protocol for new or existing chains? (Read 777 times)

legendary
Activity: 3472
Merit: 4801
How can this be true if people send crypto to bad addresses all the time and they just get lost?

You're going to have to describe what you mean when you say "bad address". Your use of that phrase is an indication that you either don't understand what you are talking about, or you are having difficulty translating to english form some other language.

There are no addresses in the blockchain, or in actual transactions.  Only output scripts.

I don't think you're right about coins being lost or getting sent to bad addresses you might wanna double check that.

Ok. I've double checked.  My understanding of how Bitcoin works appears to be accurate.

Now its your turn.

You might want to double check the things you think you know about bitcoin.  You've either been misinformed, or you've made some very inaccurate assumptions.
staff
Activity: 3458
Merit: 6793
Just writing some code
How can this be true if people send crypto to bad addresses all the time and they just get lost?
People can create addresses for which no one is known to have a private key for. Private keys exist for those addresses, just that the probability of someone having the private key for those addresses is so small that it is basically 0. Those addresses are not bad addresses, they are perfectly valid. The coins are lost because the coins are basically unspendable. Regardless of whether the coins are sent to such addresses or not, the transaction is valid and it becomes confirmed. There does not need to be an owner who claims coins for a transaction to become confirmed.

It was just a concept idea to implement for longevity and healthy chain growth in the long term anyway. I don't think you're right about coins being lost or getting sent to bad addresses you might wanna double check that.
You really need to learn how Bitcoin and transactions work before you go and make such statements. Clearly you don't understand how addresses, transactions, and Bitcoin as a whole works.
newbie
Activity: 4
Merit: 0
Then take the same concept for the unconfirmed transactions after x amount of time instead & apply it.

So, if someone creates a transaction and it doesn't get confirmed right away, you're saying we should steal their bitcoins?

No thanks.  Horrible idea.

If I broadcast a transaction that doesn't get confirmed, then I might want to spend those transaction outputs in a different transaction in the future.  What right do you have to take my money just because you saw a transaction I created once in the past?

Just out of curiosity where do coins go then from sending to a none existing address?

It is not possible to send to a non-existing address.

Furthermore, at the protocol level there are no addresses and there are no coins.  Those are abstractions that we humans use to make it easier to talk about the transfer of control over value.  "Coins" never "go" anywhere.  Transactions either exist in the blockchain or don't exist in the blockchain.  The amount of "coins" you "own" is actually just the sum of the value of the transaction outputs in the blockchain that you have control over.

Do they just stay in an unconfirmed state?

Transactions are unconfirmed until they are either included in a block in the blockchain, or until they become invalid.

If so why can't the same method be applied?

Because bitcoin doesn't work the way you seem to think it works, and you haven't taken the time to learn how it actually works.

How can this be true if people send crypto to bad addresses all the time and they just get lost?

It was just a concept idea to implement for longevity and healthy chain growth in the long term anyway. I don't think you're right about coins being lost or getting sent to bad addresses you might wanna double check that.
member
Activity: 86
Merit: 26
Here is an analysis of the blockchain from July 2014 determining which bitcoins were provably unspendable at that time:

In validating a UTXO parser I started looking at various outputs which are provably unspendable.  As of block #305303 2,745.22283996 BTC have been provably lost.  The total number of coins lost is higher potentially much higher but most of those losses can't be proven.   Funds sent to outputs that can never be redeemed can be provably shown to be lost.

Code:
Category       NumOutputs    AmountLost
-----------------------------------------
BugOpFalse            23   2,609.36304319
BugP2Pool            182       0.60280235
BugInvalidOpcode      14       0.04520008
BugInvalidPubKey  17,112       0.00242288
BugParseError          1       0.00040000
ZeroValue *        3,080       0.00000000
MissingFromUTXO **   ---     135.20897146
-----------------------------------------
Total             20,412   2,745.22283996 BTC

* Zero value unprunable outputs are not invalid outputs but they are undesirable.  I was surprised to see there are over three thousand in the UTXO.  In the future the creation of new zero value outputs (with the exception of the prunable OP_RETURN) could be made invalid and potentially even these outputs pruned off by a hard fork.

** As of block 305,303 the coin supply is limited to 12,882,575 BTC.   This is based on the max subsidy per block and the block height.  However the UTXO (set of all unspent outputs) is only 12,882,439.79102854 BTC.  Some of the difference may be due to OP_RETURN outputs (which are unspendable by protocol) having a value set.  This could be accidental or intentional.  Another source of lost coins is due to miners taking less than the maximum block reward which in effect "de-mines" an amount of coins equal to the difference between the allowed reward and the taken reward.

Thanks for this list. I will dive into this different script types.
legendary
Activity: 3472
Merit: 4801
The only 100% proven destroyed coins are the one with OP_RETURN outputs.

Not true.  See below.

Not sure how many BTC were destroyed in this way, but I remember an article saying, that there are about 4 BTC lost due to OP_RETURN outputs. Could be higher now, as it was an old article.

It is higher. See below.

All other script outputs may be valid for someone to spend.

Not true.  See below.

There is no way so far I know, to identify if any UTXO is never ever spendable in the future.

Not true.  See below.



Here is an analysis of the blockchain from July 2014 determining which bitcoins were provably unspendable at that time:

In validating a UTXO parser I started looking at various outputs which are provably unspendable.  As of block #305303 2,745.22283996 BTC have been provably lost.  The total number of coins lost is higher potentially much higher but most of those losses can't be proven.   Funds sent to outputs that can never be redeemed can be provably shown to be lost.

Code:
Category       NumOutputs    AmountLost
-----------------------------------------
BugOpFalse            23   2,609.36304319
BugP2Pool            182       0.60280235
BugInvalidOpcode      14       0.04520008
BugInvalidPubKey  17,112       0.00242288
BugParseError          1       0.00040000
ZeroValue *        3,080       0.00000000
MissingFromUTXO **   ---     135.20897146
-----------------------------------------
Total             20,412   2,745.22283996 BTC

* Zero value unprunable outputs are not invalid outputs but they are undesirable.  I was surprised to see there are over three thousand in the UTXO.  In the future the creation of new zero value outputs (with the exception of the prunable OP_RETURN) could be made invalid and potentially even these outputs pruned off by a hard fork.

** As of block 305,303 the coin supply is limited to 12,882,575 BTC.   This is based on the max subsidy per block and the block height.  However the UTXO (set of all unspent outputs) is only 12,882,439.79102854 BTC.  Some of the difference may be due to OP_RETURN outputs (which are unspendable by protocol) having a value set.  This could be accidental or intentional.  Another source of lost coins is due to miners taking less than the maximum block reward which in effect "de-mines" an amount of coins equal to the difference between the allowed reward and the taken reward.
member
Activity: 86
Merit: 26
The only 100% proven destroyed coins are the one with OP_RETURN outputs.
Not sure how many BTC were destroyed in this way, but I remember an article saying, that there are about 4 BTC lost due to OP_RETURN outputs. Could be higher now, as it was an old article.

All other script outputs may be valid for someone to spend.

There is no way so far I know, to identify if any UTXO is never ever spendable in the future.

So I would not suggest to "steal" someone elses BTC.
sr. member
Activity: 257
Merit: 343
Just out of curiosity where do coins go then from sending to a none existing address? Do they just stay in an unconfirmed state? If so why can't the same method be applied?

I think there is some misunderstanding: there are no such things as "none" existing addresses. Once a tx has been accepted by a full node, it is valid :-)
Maybe you think about addresses, who have "no known owner with his privkey"? Or do you think about those tx which are non-spendable (cause the script was invalid, stupid, intentionally ...)
This has been discussed already here in the forum, and the point is, who can decide what is invalid, and what not. The idea of bringing back coins into the cycle is nice, to avoid scarcity, but the problems around it are not yet fully understood (maybe the ideas are not yet mature). Danny and Achow provided already a short view on this. 
legendary
Activity: 3472
Merit: 4801
Then take the same concept for the unconfirmed transactions after x amount of time instead & apply it.

So, if someone creates a transaction and it doesn't get confirmed right away, you're saying we should steal their bitcoins?

No thanks.  Horrible idea.

If I broadcast a transaction that doesn't get confirmed, then I might want to spend those transaction outputs in a different transaction in the future.  What right do you have to take my money just because you saw a transaction I created once in the past?

Just out of curiosity where do coins go then from sending to a none existing address?

It is not possible to send to a non-existing address.

Furthermore, at the protocol level there are no addresses and there are no coins.  Those are abstractions that we humans use to make it easier to talk about the transfer of control over value.  "Coins" never "go" anywhere.  Transactions either exist in the blockchain or don't exist in the blockchain.  The amount of "coins" you "own" is actually just the sum of the value of the transaction outputs in the blockchain that you have control over.

Do they just stay in an unconfirmed state?

Transactions are unconfirmed until they are either included in a block in the blockchain, or until they become invalid.

If so why can't the same method be applied?

Because bitcoin doesn't work the way you seem to think it works, and you haven't taken the time to learn how it actually works.
newbie
Activity: 4
Merit: 0
Then take the same concept for the unconfirmed transactions after x amount of time instead & apply it.

Just out of curiosity where do coins go then from sending to a none existing address? Do they just stay in an unconfirmed state? If so why can't the same method be applied?

100% programmable.
staff
Activity: 3458
Merit: 6793
Just writing some code
The long term goal is to keep miners on board & keep the chain alive while it gets more scarce over time. Well, what if you developed a new protocol to check for lost coins that never arrived. I'm not done yet what if you could take those undelivered coins & transactions sitting in the mem pool every 5 years or so. Then recycle them back into the block reward again?...
That's not how Bitcoin works. First of all, coins are not undelivered and transactions don't sit in the mempool for years. That's not how the mempool or transactions work. Coins cannot be "not delivered". You don't have to claim transactions or anything like that for the coins to be "delivered". Transactions can only be in two states: unconfirmed or confirmed. Coins can only ever be "delivered"; there is no state where coins are "in between" and get lost.

I highly suggest that you actually learn how Bitcoin transactions work and how the mempool works first before thinking of any new ideas.
newbie
Activity: 4
Merit: 0
I've rattled this idea for a while now & can't see why it wouldn't be useful.

The long term goal is to keep miners on board & keep the chain alive while it gets more scarce over time. Well, what if you developed a new protocol to check for lost coins that never arrived. I'm not done yet what if you could take those undelivered coins & transactions sitting in the mem pool every 5 years or so. Then recycle them back into the block reward again?...

I don't see a problem with this as it creates an incentive for miners in the long run. Keeps your total number in circulation refreshed and the mem pool clean. Making everyone happy and the chain healthy. This would also slow the process of things becoming more scarce faster. You could argue n say it slows the inflation price at the same time but it still keeps the same circulating amount in supply from refreshing every so X amount of time. Every 5 years or so seems like a good time to refresh. Over 20 years when difficulties are up you can refresh & keep block rewards up.

Think of it like a predicted Black Friday. Where things ramp up over difficulty then take a small dip as recycled coins get redistributed. I would choose this option over miners not mining the network altogether and the chain dying. As this is something we've learned from Historic Genesis Chains, Miners need an incentive for longevity. Over time the price will still increase as the difficulty gets harder.

Off the top of my head, you could make some kinda accumulation collector for the mem pool for undelivered coins. Make it an automatic protocol to repeat every so x amount of time = to projected difficulty increase. I honestly don't see a problem for this kinda idea or standard to be added to create a longevity for chains.

The same method can be applied for unconfirmed transactions.

I call it: Recycling or Purging

Thanks for reading Smiley
Jump to: