public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] idea post: trimming and demurrage
@ 2017-09-25 21:54 Patrick Sharp
  2017-09-25 23:30 ` Richard Hein
  2017-09-25 23:34 ` ZmnSCPxj
  0 siblings, 2 replies; 7+ messages in thread
From: Patrick Sharp @ 2017-09-25 21:54 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 3265 bytes --]

Hello Devs,

I am Patrick Sharp. I just graduated with a BS is computer science. Forgive
my ignorance.

As per bip-0002 I have scoured each bip available on the wiki to see if
these ideas have already been formally proposed and now as per bip-0002
post these ideas here.

First and foremost I acknowledge that these ideas are not original nor new.

Trimming and demurrage:

I am fully aware that demurrage is a prohibited change. I hereby contest.
For the record I am not a miner, I am just aware of the economics that
drive the costs of bitcoin.

Without the ability to maintain some sort of limit on the maximum length or
size of the block chain, block chain is not only unsustainable in the long
run but becomes more and more centralized as the block chain becomes more
and more unwieldy.

Trimming is not a foreign concept. Old block whose transactions are now
spent hold no real value. Meaningful trimming is expensive and inhibited by
unspent transactions. Old unspent transactions add unnecessary and unfair
burden.

   - Old transactions take up real world space that continues incur cost
   while these transactions they do not continue to contribute to any sort of
   payment for this cost.
   - One can assume that anybody with access to their bitcoins has the
   power to move these bitcoins from one address to another (or at least that
   the software that holds the keys to their coins can do it for them) and it
   is not unfair to require them to do so at least once every 5 to 10 years.
   - Given the incentive to move it or lose it and software that will do it
      for them, we can assume that any bitcoin not moved is most likey
therefore
      lost.
      - moving these coins will cost a small transaction fee which is fair
      as their transactions take up space, they need to contribute
      - most people who use their coins regularly will not even need to
      worry about this as their coins are moved to a change address anyway.
   - one downside is that paper wallets would then have an expiration date,
   however I do not think that a paper wallet that needs to be recycled every
   5 to 10 years is a terrible idea.

Therefore I propose that the block chain length be limited to either 2^18
blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than
10 years. I propose that each time a block is mined the the oldest block(s)
(no more than two blocks) beyond this limit is trimmed from the chain and
that its unspent transactions are allowed to be included in the reward of
the mined block.

This keeps the block chain from tending towards infinity. This keeps the
costs of the miners balanced with the costs of the users.

Even though I believe this idea will have some friction, it is applicable
to the entire community. It will be hard for some users to give up small
benefits that they get at the great cost of miners, however miners run the
game and this fair proposal is in in their best interest in two different
ways. I would like your thoughts and suggestions. I obviously think this is
a freaking awesome idea. I know it is quite controversial but it is the
next step in evolution that bitcoin needs to take to ensure immortality.

I come to you to ask if this has any chance of acceptance.

-Patrick

[-- Attachment #2: Type: text/html, Size: 4202 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

• * Re: [bitcoin-dev] idea post: trimming and demurrage
    2017-09-25 21:54 [bitcoin-dev] idea post: trimming and demurrage Patrick Sharp
  @ 2017-09-25 23:30 ` Richard Hein
    2017-09-25 23:34 ` ZmnSCPxj
    1 sibling, 0 replies; 7+ messages in thread
  From: Richard Hein @ 2017-09-25 23:30 UTC (permalink / raw)
    To: Patrick Sharp, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 3882 bytes --]
  
  It kills Bitcoin as a store of value.  Disk space is not the problem; bandwidth is.  The blockchain won't go to infinity as you suggest, as it is bounded by certain constraints.  It's growth is a function of the transactions in a block, and the number of blocks is linear in growth.  
  
  Sent from my iPhone
  
  > On Sep 25, 2017, at 5:54 PM, Patrick Sharp via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
  > 
  > Hello Devs,
  > 
  > I am Patrick Sharp. I just graduated with a BS is computer science. Forgive my ignorance.
  > 
  > As per bip-0002 I have scoured each bip available on the wiki to see if these ideas have already been formally proposed and now as per bip-0002 post these ideas here.
  > 
  > First and foremost I acknowledge that these ideas are not original nor new.
  > 
  > Trimming and demurrage:
  > 
  > I am fully aware that demurrage is a prohibited change. I hereby contest. For the record I am not a miner, I am just aware of the economics that drive the costs of bitcoin.
  > 
  > Without the ability to maintain some sort of limit on the maximum length or size of the block chain, block chain is not only unsustainable in the long run but becomes more and more centralized as the block chain becomes more and more unwieldy.
  > 
  > Trimming is not a foreign concept. Old block whose transactions are now spent hold no real value. Meaningful trimming is expensive and inhibited by unspent transactions. Old unspent transactions add unnecessary and unfair burden.
  > Old transactions take up real world space that continues incur cost while these transactions they do not continue to contribute to any sort of payment for this cost.
  > One can assume that anybody with access to their bitcoins has the power to move these bitcoins from one address to another (or at least that the software that holds the keys to their coins can do it for them) and it is not unfair to require them to do so at least once every 5 to 10 years.
  > Given the incentive to move it or lose it and software that will do it for them, we can assume that any bitcoin not moved is most likey therefore lost.
  > moving these coins will cost a small transaction fee which is fair as their transactions take up space, they need to contribute
  > most people who use their coins regularly will not even need to worry about this as their coins are moved to a change address anyway.
  > one downside is that paper wallets would then have an expiration date, however I do not think that a paper wallet that needs to be recycled every 5 to 10 years is a terrible idea.
  > Therefore I propose that the block chain length be limited to either 2^18 blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than 10 years. I propose that each time a block is mined the the oldest block(s) (no more than two blocks) beyond this limit is trimmed from the chain and that its unspent transactions are allowed to be included in the reward of the mined block.
  > 
  > This keeps the block chain from tending towards infinity. This keeps the costs of the miners balanced with the costs of the users.
  > 
  > Even though I believe this idea will have some friction, it is applicable to the entire community. It will be hard for some users to give up small benefits that they get at the great cost of miners, however miners run the game and this fair proposal is in in their best interest in two different ways. I would like your thoughts and suggestions. I obviously think this is a freaking awesome idea. I know it is quite controversial but it is the next step in evolution that bitcoin needs to take to ensure immortality.
  > 
  > I come to you to ask if this has any chance of acceptance.
  > 
  > -Patrick
  > _______________________________________________
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  
  [-- Attachment #2: Type: text/html, Size: 5332 bytes --]
  
  ^ permalink raw reply	[flat|nested] 7+ messages in thread

• * Re: [bitcoin-dev] idea post: trimming and demurrage
    2017-09-25 21:54 [bitcoin-dev] idea post: trimming and demurrage Patrick Sharp
    2017-09-25 23:30 ` Richard Hein
  @ 2017-09-25 23:34 ` ZmnSCPxj
    2017-09-26  1:33   ` Patrick Sharp
    1 sibling, 1 reply; 7+ messages in thread
  From: ZmnSCPxj @ 2017-09-25 23:34 UTC (permalink / raw)
    To: Patrick Sharp; +Cc: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 4498 bytes --]
  
  Good morning Patrick,
  
  Demurrage is simply impossible.
  
  In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
  
  This opcode requires that a certain block height or date has passed before the output can be spent.
  
  It can be used to make an "in trust for" address, where you disallow spending of that address.  For example, you may have a child to whom you wish to dedicate some inheritance to, and ensure that the child will not spend it recklessly until they achieve some age (when hopefully they would be more mature), regardless of what happens to you.
  
  If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows spending 18 years from birth of my child, and then suddenly Bitcoin Core announces demurrage, I would be very angry.
  
  OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be impossible to refresh the UTXO's as required by demurrage, without requiring a hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
  
  It would be better to put such additional features as demurrage in a sidechain rather than on mainchain.
  
  Regards,
  ZmnSCPxj
  
  -------- Original Message --------
  Subject: [bitcoin-dev] idea post: trimming and demurrage
  Local Time: September 25, 2017 9:54 PM
  UTC Time: September 25, 2017 9:54 PM
  From: bitcoin-dev@lists•linuxfoundation.org
  To: bitcoin-dev@lists•linuxfoundation.org
  
  Hello Devs,
  
  I am Patrick Sharp. I just graduated with a BS is computer science. Forgive my ignorance.
  
  As per bip-0002 I have scoured each bip available on the wiki to see if these ideas have already been formally proposed and now as per bip-0002 post these ideas here.
  
  First and foremost I acknowledge that these ideas are not original nor new.
  
  Trimming and demurrage:
  
  I am fully aware that demurrage is a prohibited change. I hereby contest. For the record I am not a miner, I am just aware of the economics that drive the costs of bitcoin.
  
  Without the ability to maintain some sort of limit on the maximum length or size of the block chain, block chain is not only unsustainable in the long run but becomes more and more centralized as the block chain becomes more and more unwieldy.
  
  Trimming is not a foreign concept. Old block whose transactions are now spent hold no real value. Meaningful trimming is expensive and inhibited by unspent transactions. Old unspent transactions add unnecessary and unfair burden.
  Old transactions take up real world space that continues incur cost while these transactions they do not continue to contribute to any sort of payment for this cost.
  One can assume that anybody with access to their bitcoins has the power to move these bitcoins from one address to another (or at least that the software that holds the keys to their coins can do it for them) and it is not unfair to require them to do so at least once every 5 to 10 years.
  Given the incentive to move it or lose it and software that will do it for them, we can assume that any bitcoin not moved is most likey therefore lost.
  moving these coins will cost a small transaction fee which is fair as their transactions take up space, they need to contribute
  most people who use their coins regularly will not even need to worry about this as their coins are moved to a change address anyway.
  one downside is that paper wallets would then have an expiration date, however I do not think that a paper wallet that needs to be recycled every 5 to 10 years is a terrible idea.
  Therefore I propose that the block chain length be limited to either 2^18 blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than 10 years. I propose that each time a block is mined the the oldest block(s) (no more than two blocks) beyond this limit is trimmed from the chain and that its unspent transactions are allowed to be included in the reward of the mined block.
  
  This keeps the block chain from tending towards infinity. This keeps the costs of the miners balanced with the costs of the users.
  
  Even though I believe this idea will have some friction, it is applicable to the entire community. It will be hard for some users to give up small benefits that they get at the great cost of miners, however miners run the game and this fair proposal is in in their best interest in two different ways. I would like your thoughts and suggestions. I obviously think this is a freaking awesome idea. I know it is quite controversial but it is the next step in evolution that bitcoin needs to take to ensure immortality.
  
  I come to you to ask if this has any chance of acceptance.
  
  -Patrick
  
  [-- Attachment #2: Type: text/html, Size: 5266 bytes --]
  
  ^ permalink raw reply	[flat|nested] 7+ messages in thread

• • * Re: [bitcoin-dev] idea post: trimming and demurrage
      2017-09-25 23:34 ` ZmnSCPxj
    @ 2017-09-26  1:33   ` Patrick Sharp
      2017-09-25 22:43     ` Aymeric Vitte
                           ` (2 more replies)
      0 siblings, 3 replies; 7+ messages in thread
    From: Patrick Sharp @ 2017-09-26  1:33 UTC (permalink / raw)
      To: ZmnSCPxj; +Cc: bitcoin-dev
    
    [-- Attachment #1: Type: text/plain, Size: 5572 bytes --]
    
    Thank you for your responses. I have been enlightened. For the time being
    the combination of the UTXO's and pruning will accomplish what I desire. I
    suspect that there will come a time when the UTXO database becomes too
    large, but I guess that is a problem for another day. If that day ever
    comes 10 years was just an example, like you said there are reasons to
    preserve value beyond that point, perhaps a human lifetime or two would be
    a better choice.
    
    Side question: wouldn't it be a good idea to store the hash of the current
    or previous UTXO's in the block header so that pruned nodes can verify
    their UTXO's are accurate without having to check the full chain? and/or
    maybe include a snap shot of the UTXO's every x blocks?
    
    You guys are totally awesome!!!
    
    I here by withdraw my proposal for the time being.
    
    On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
    
    > Good morning Patrick,
    >
    > Demurrage is simply impossible.
    >
    > In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
    >
    > This opcode requires that a certain block height or date has passed before
    > the output can be spent.
    >
    > It can be used to make an "in trust for" address, where you disallow
    > spending of that address.  For example, you may have a child to whom you
    > wish to dedicate some inheritance to, and ensure that the child will not
    > spend it recklessly until they achieve some age (when hopefully they would
    > be more mature), regardless of what happens to you.
    >
    > If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows spending
    > 18 years from birth of my child, and then suddenly Bitcoin Core announces
    > demurrage, I would be very angry.
    >
    > OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be impossible
    > to refresh the UTXO's as required by demurrage, without requiring a
    > hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
    >
    > It would be better to put such additional features as demurrage in a
    > sidechain rather than on mainchain.
    >
    >
    > Regards,
    > ZmnSCPxj
    >
    > -------- Original Message --------
    > Subject: [bitcoin-dev] idea post: trimming and demurrage
    > Local Time: September 25, 2017 9:54 PM
    > UTC Time: September 25, 2017 9:54 PM
    > From: bitcoin-dev@lists•linuxfoundation.org
    > To: bitcoin-dev@lists•linuxfoundation.org
    >
    > Hello Devs,
    >
    > I am Patrick Sharp. I just graduated with a BS is computer science.
    > Forgive my ignorance.
    >
    > As per bip-0002 I have scoured each bip available on the wiki to see if
    > these ideas have already been formally proposed and now as per bip-0002
    > post these ideas here.
    >
    > First and foremost I acknowledge that these ideas are not original nor new.
    >
    > Trimming and demurrage:
    >
    > I am fully aware that demurrage is a prohibited change. I hereby contest.
    > For the record I am not a miner, I am just aware of the economics that
    > drive the costs of bitcoin.
    >
    > Without the ability to maintain some sort of limit on the maximum length
    > or size of the block chain, block chain is not only unsustainable in the
    > long run but becomes more and more centralized as the block chain becomes
    > more and more unwieldy.
    >
    > Trimming is not a foreign concept. Old block whose transactions are now
    > spent hold no real value. Meaningful trimming is expensive and inhibited by
    > unspent transactions. Old unspent transactions add unnecessary and unfair
    > burden.
    > Old transactions take up real world space that continues incur cost while
    > these transactions they do not continue to contribute to any sort of
    > payment for this cost.
    > One can assume that anybody with access to their bitcoins has the power to
    > move these bitcoins from one address to another (or at least that the
    > software that holds the keys to their coins can do it for them) and it is
    > not unfair to require them to do so at least once every 5 to 10 years.
    > Given the incentive to move it or lose it and software that will do it for
    > them, we can assume that any bitcoin not moved is most likey therefore lost.
    > moving these coins will cost a small transaction fee which is fair as
    > their transactions take up space, they need to contribute
    > most people who use their coins regularly will not even need to worry
    > about this as their coins are moved to a change address anyway.
    > one downside is that paper wallets would then have an expiration date,
    > however I do not think that a paper wallet that needs to be recycled every
    > 5 to 10 years is a terrible idea.
    > Therefore I propose that the block chain length be limited to either 2^18
    > blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than
    > 10 years. I propose that each time a block is mined the the oldest block(s)
    > (no more than two blocks) beyond this limit is trimmed from the chain and
    > that its unspent transactions are allowed to be included in the reward of
    > the mined block.
    >
    > This keeps the block chain from tending towards infinity. This keeps the
    > costs of the miners balanced with the costs of the users.
    >
    > Even though I believe this idea will have some friction, it is applicable
    > to the entire community. It will be hard for some users to give up small
    > benefits that they get at the great cost of miners, however miners run the
    > game and this fair proposal is in in their best interest in two different
    > ways. I would like your thoughts and suggestions. I obviously think this is
    > a freaking awesome idea. I know it is quite controversial but it is the
    > next step in evolution that bitcoin needs to take to ensure immortality.
    >
    > I come to you to ask if this has any chance of acceptance.
    >
    > -Patrick
    >
    
    [-- Attachment #2: Type: text/html, Size: 6926 bytes --]
    
    ^ permalink raw reply	[flat|nested] 7+ messages in thread

  • • * Re: [bitcoin-dev] idea post: trimming and demurrage
        2017-09-26  1:33   ` Patrick Sharp
      @ 2017-09-25 22:43     ` Aymeric Vitte
        2017-09-26  7:10     ` Алексей Мутовкин
        2017-09-26  7:50     ` ZmnSCPxj
        2 siblings, 0 replies; 7+ messages in thread
      From: Aymeric Vitte @ 2017-09-25 22:43 UTC (permalink / raw)
        To: Patrick Sharp, Bitcoin Protocol Discussion, ZmnSCPxj
      
      [-- Attachment #1: Type: text/plain, Size: 6979 bytes --]
      
      Maybe I missed or did not receive some messages, where was your
      centralization concern addressed in the discussion?
      
      
      Le 26/09/2017 à 03:33, Patrick Sharp via bitcoin-dev a écrit :
      > Thank you for your responses. I have been enlightened. For the time
      > being the combination of the UTXO's and pruning will accomplish what I
      > desire. I suspect that there will come a time when the UTXO database
      > becomes too large, but I guess that is a problem for another day. If
      > that day ever comes 10 years was just an example, like you said there
      > are reasons to preserve value beyond that point, perhaps a human
      > lifetime or two would be a better choice.
      >
      > Side question: wouldn't it be a good idea to store the hash of the
      > current or previous UTXO's in the block header so that pruned nodes
      > can verify their UTXO's are accurate without having to check the full
      > chain? and/or maybe include a snap shot of the UTXO's every x blocks?
      >
      > You guys are totally awesome!!!
      >
      > I here by withdraw my proposal for the time being.
      >
      > On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com
      > <mailto:ZmnSCPxj@protonmail•com>> wrote:
      >
      >     Good morning Patrick,
      >
      >     Demurrage is simply impossible.
      >
      >     In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
      >
      >     This opcode requires that a certain block height or date has
      >     passed before the output can be spent.
      >
      >     It can be used to make an "in trust for" address, where you
      >     disallow spending of that address.  For example, you may have a
      >     child to whom you wish to dedicate some inheritance to, and ensure
      >     that the child will not spend it recklessly until they achieve
      >     some age (when hopefully they would be more mature), regardless of
      >     what happens to you.
      >
      >     If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows
      >     spending 18 years from birth of my child, and then suddenly
      >     Bitcoin Core announces demurrage, I would be very angry.
      >
      >     OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be
      >     impossible to refresh the UTXO's as required by demurrage, without
      >     requiring a hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
      >
      >     It would be better to put such additional features as demurrage in
      >     a sidechain rather than on mainchain.
      >
      >
      >     Regards,
      >     ZmnSCPxj
      >
      >     -------- Original Message --------
      >     Subject: [bitcoin-dev] idea post: trimming and demurrage
      >     Local Time: September 25, 2017 9:54 PM
      >     UTC Time: September 25, 2017 9:54 PM
      >     From: bitcoin-dev@lists•linuxfoundation.org
      >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
      >     To: bitcoin-dev@lists•linuxfoundation.org
      >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
      >
      >     Hello Devs,
      >
      >     I am Patrick Sharp. I just graduated with a BS is computer
      >     science. Forgive my ignorance.
      >
      >     As per bip-0002 I have scoured each bip available on the wiki to
      >     see if these ideas have already been formally proposed and now as
      >     per bip-0002 post these ideas here.
      >
      >     First and foremost I acknowledge that these ideas are not original
      >     nor new.
      >
      >     Trimming and demurrage:
      >
      >     I am fully aware that demurrage is a prohibited change. I hereby
      >     contest. For the record I am not a miner, I am just aware of the
      >     economics that drive the costs of bitcoin.
      >
      >     Without the ability to maintain some sort of limit on the maximum
      >     length or size of the block chain, block chain is not only
      >     unsustainable in the long run but becomes more and more
      >     centralized as the block chain becomes more and more unwieldy.
      >
      >     Trimming is not a foreign concept. Old block whose transactions
      >     are now spent hold no real value. Meaningful trimming is expensive
      >     and inhibited by unspent transactions. Old unspent transactions
      >     add unnecessary and unfair burden.
      >     Old transactions take up real world space that continues incur
      >     cost while these transactions they do not continue to contribute
      >     to any sort of payment for this cost.
      >     One can assume that anybody with access to their bitcoins has the
      >     power to move these bitcoins from one address to another (or at
      >     least that the software that holds the keys to their coins can do
      >     it for them) and it is not unfair to require them to do so at
      >     least once every 5 to 10 years.
      >     Given the incentive to move it or lose it and software that will
      >     do it for them, we can assume that any bitcoin not moved is most
      >     likey therefore lost.
      >     moving these coins will cost a small transaction fee which is fair
      >     as their transactions take up space, they need to contribute
      >     most people who use their coins regularly will not even need to
      >     worry about this as their coins are moved to a change address anyway.
      >     one downside is that paper wallets would then have an expiration
      >     date, however I do not think that a paper wallet that needs to be
      >     recycled every 5 to 10 years is a terrible idea.
      >     Therefore I propose that the block chain length be limited to
      >     either 2^18 blocks (slightly less than 5 years) or 2^19 blocks, or
      >     slightly less than 10 years. I propose that each time a block is
      >     mined the the oldest block(s) (no more than two blocks) beyond
      >     this limit is trimmed from the chain and that its unspent
      >     transactions are allowed to be included in the reward of the mined
      >     block.
      >
      >     This keeps the block chain from tending towards infinity. This
      >     keeps the costs of the miners balanced with the costs of the users.
      >
      >     Even though I believe this idea will have some friction, it is
      >     applicable to the entire community. It will be hard for some users
      >     to give up small benefits that they get at the great cost of
      >     miners, however miners run the game and this fair proposal is in
      >     in their best interest in two different ways. I would like your
      >     thoughts and suggestions. I obviously think this is a freaking
      >     awesome idea. I know it is quite controversial but it is the next
      >     step in evolution that bitcoin needs to take to ensure immortality.
      >
      >     I come to you to ask if this has any chance of acceptance.
      >
      >     -Patrick
      >
      >
      >
      >
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      
      -- 
      Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
      Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
      Get the torrent dynamic blocklist: http://peersm.com/getblocklist
      Check the 10 M passwords list: http://peersm.com/findmyass
      Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
      Peersm : http://www.peersm.com
      torrent-live: https://github.com/Ayms/torrent-live
      node-Tor : https://www.github.com/Ayms/node-Tor
      GitHub : https://www.github.com/Ayms
      
      
      [-- Attachment #2: Type: text/html, Size: 12469 bytes --]
      
      ^ permalink raw reply	[flat|nested] 7+ messages in thread

    • * Re: [bitcoin-dev] idea post: trimming and demurrage
        2017-09-26  1:33   ` Patrick Sharp
        2017-09-25 22:43     ` Aymeric Vitte
      @ 2017-09-26  7:10     ` Алексей Мутовкин
        2017-09-26  7:50     ` ZmnSCPxj
        2 siblings, 0 replies; 7+ messages in thread
      From: Алексей Мутовкин @ 2017-09-26  7:10 UTC (permalink / raw)
        To: Patrick Sharp, Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 6198 bytes --]
      
      Lets call it blocktrain instead of blockchain. Because it is fixed amount
      of blocks moving forward on the time axis. Oldest blocks are detached from
      the tail of that blockTrain and goes to depot.
      
      2017-09-26 4:33 GMT+03:00 Patrick Sharp via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org>:
      
      > Thank you for your responses. I have been enlightened. For the time being
      > the combination of the UTXO's and pruning will accomplish what I desire. I
      > suspect that there will come a time when the UTXO database becomes too
      > large, but I guess that is a problem for another day. If that day ever
      > comes 10 years was just an example, like you said there are reasons to
      > preserve value beyond that point, perhaps a human lifetime or two would be
      > a better choice.
      >
      > Side question: wouldn't it be a good idea to store the hash of the current
      > or previous UTXO's in the block header so that pruned nodes can verify
      > their UTXO's are accurate without having to check the full chain? and/or
      > maybe include a snap shot of the UTXO's every x blocks?
      >
      > You guys are totally awesome!!!
      >
      > I here by withdraw my proposal for the time being.
      >
      > On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
      >
      >> Good morning Patrick,
      >>
      >> Demurrage is simply impossible.
      >>
      >> In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
      >>
      >> This opcode requires that a certain block height or date has passed
      >> before the output can be spent.
      >>
      >> It can be used to make an "in trust for" address, where you disallow
      >> spending of that address.  For example, you may have a child to whom you
      >> wish to dedicate some inheritance to, and ensure that the child will not
      >> spend it recklessly until they achieve some age (when hopefully they would
      >> be more mature), regardless of what happens to you.
      >>
      >> If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows spending
      >> 18 years from birth of my child, and then suddenly Bitcoin Core announces
      >> demurrage, I would be very angry.
      >>
      >> OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be
      >> impossible to refresh the UTXO's as required by demurrage, without
      >> requiring a hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
      >>
      >> It would be better to put such additional features as demurrage in a
      >> sidechain rather than on mainchain.
      >>
      >>
      >> Regards,
      >> ZmnSCPxj
      >>
      >> -------- Original Message --------
      >> Subject: [bitcoin-dev] idea post: trimming and demurrage
      >> Local Time: September 25, 2017 9:54 PM
      >> UTC Time: September 25, 2017 9:54 PM
      >> From: bitcoin-dev@lists•linuxfoundation.org
      >> To: bitcoin-dev@lists•linuxfoundation.org
      >>
      >> Hello Devs,
      >>
      >> I am Patrick Sharp. I just graduated with a BS is computer science.
      >> Forgive my ignorance.
      >>
      >> As per bip-0002 I have scoured each bip available on the wiki to see if
      >> these ideas have already been formally proposed and now as per bip-0002
      >> post these ideas here.
      >>
      >> First and foremost I acknowledge that these ideas are not original nor
      >> new.
      >>
      >> Trimming and demurrage:
      >>
      >> I am fully aware that demurrage is a prohibited change. I hereby contest.
      >> For the record I am not a miner, I am just aware of the economics that
      >> drive the costs of bitcoin.
      >>
      >> Without the ability to maintain some sort of limit on the maximum length
      >> or size of the block chain, block chain is not only unsustainable in the
      >> long run but becomes more and more centralized as the block chain becomes
      >> more and more unwieldy.
      >>
      >> Trimming is not a foreign concept. Old block whose transactions are now
      >> spent hold no real value. Meaningful trimming is expensive and inhibited by
      >> unspent transactions. Old unspent transactions add unnecessary and unfair
      >> burden.
      >> Old transactions take up real world space that continues incur cost while
      >> these transactions they do not continue to contribute to any sort of
      >> payment for this cost.
      >> One can assume that anybody with access to their bitcoins has the power
      >> to move these bitcoins from one address to another (or at least that the
      >> software that holds the keys to their coins can do it for them) and it is
      >> not unfair to require them to do so at least once every 5 to 10 years.
      >> Given the incentive to move it or lose it and software that will do it
      >> for them, we can assume that any bitcoin not moved is most likey therefore
      >> lost.
      >> moving these coins will cost a small transaction fee which is fair as
      >> their transactions take up space, they need to contribute
      >> most people who use their coins regularly will not even need to worry
      >> about this as their coins are moved to a change address anyway.
      >> one downside is that paper wallets would then have an expiration date,
      >> however I do not think that a paper wallet that needs to be recycled every
      >> 5 to 10 years is a terrible idea.
      >> Therefore I propose that the block chain length be limited to either 2^18
      >> blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than
      >> 10 years. I propose that each time a block is mined the the oldest block(s)
      >> (no more than two blocks) beyond this limit is trimmed from the chain and
      >> that its unspent transactions are allowed to be included in the reward of
      >> the mined block.
      >>
      >> This keeps the block chain from tending towards infinity. This keeps the
      >> costs of the miners balanced with the costs of the users.
      >>
      >> Even though I believe this idea will have some friction, it is applicable
      >> to the entire community. It will be hard for some users to give up small
      >> benefits that they get at the great cost of miners, however miners run the
      >> game and this fair proposal is in in their best interest in two different
      >> ways. I would like your thoughts and suggestions. I obviously think this is
      >> a freaking awesome idea. I know it is quite controversial but it is the
      >> next step in evolution that bitcoin needs to take to ensure immortality.
      >>
      >> I come to you to ask if this has any chance of acceptance.
      >>
      >> -Patrick
      >>
      >
      >
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      >
      
      [-- Attachment #2: Type: text/html, Size: 8009 bytes --]
      
      ^ permalink raw reply	[flat|nested] 7+ messages in thread

    • * Re: [bitcoin-dev] idea post: trimming and demurrage
        2017-09-26  1:33   ` Patrick Sharp
        2017-09-25 22:43     ` Aymeric Vitte
        2017-09-26  7:10     ` Алексей Мутовкин
      @ 2017-09-26  7:50     ` ZmnSCPxj
        2 siblings, 0 replies; 7+ messages in thread
      From: ZmnSCPxj @ 2017-09-26  7:50 UTC (permalink / raw)
        To: Patrick Sharp; +Cc: bitcoin-dev
      
      [-- Attachment #1: Type: text/plain, Size: 6152 bytes --]
      
      Good morning,
      
      This is called "UTXO Set Commitments".
      
      Pieter Wuille I think had concrete proposals for the cryptographic primitive to use. Try searching "Rolling UTXO Set Commitments".
      
      Regards,
      ZmnSCPxj
      
      Sent with [ProtonMail](https://protonmail.com) Secure Email.
      
      > -------- Original Message --------
      > Subject: Re: [bitcoin-dev] idea post: trimming and demurrage
      > Local Time: September 26, 2017 9:33 AM
      > UTC Time: September 26, 2017 1:33 AM
      > From: psharp.x13@gmail•com
      > To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
      > bitcoin-dev@lists•linuxfoundation.org <bitcoin-dev@lists•linuxfoundation.org>
      >
      > Thank you for your responses. I have been enlightened. For the time being the combination of the UTXO's and pruning will accomplish what I desire. I suspect that there will come a time when the UTXO database becomes too large, but I guess that is a problem for another day. If that day ever comes 10 years was just an example, like you said there are reasons to preserve value beyond that point, perhaps a human lifetime or two would be a better choice.
      >
      > Side question: wouldn't it be a good idea to store the hash of the current or previous UTXO's in the block header so that pruned nodes can verify their UTXO's are accurate without having to check the full chain? and/or maybe include a snap shot of the UTXO's every x blocks?
      >
      > You guys are totally awesome!!!
      >
      > I here by withdraw my proposal for the time being.
      >
      > On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
      >
      >> Good morning Patrick,
      >>
      >> Demurrage is simply impossible.
      >>
      >> In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
      >>
      >> This opcode requires that a certain block height or date has passed before the output can be spent.
      >>
      >> It can be used to make an "in trust for" address, where you disallow spending of that address.  For example, you may have a child to whom you wish to dedicate some inheritance to, and ensure that the child will not spend it recklessly until they achieve some age (when hopefully they would be more mature), regardless of what happens to you.
      >>
      >> If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows spending 18 years from birth of my child, and then suddenly Bitcoin Core announces demurrage, I would be very angry.
      >>
      >> OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be impossible to refresh the UTXO's as required by demurrage, without requiring a hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
      >>
      >> It would be better to put such additional features as demurrage in a sidechain rather than on mainchain.
      >>
      >> Regards,
      >> ZmnSCPxj
      >>
      >> -------- Original Message --------
      >> Subject: [bitcoin-dev] idea post: trimming and demurrage
      >> Local Time: September 25, 2017 9:54 PM
      >> UTC Time: September 25, 2017 9:54 PM
      >> From: bitcoin-dev@lists•linuxfoundation.org
      >> To: bitcoin-dev@lists•linuxfoundation.org
      >>
      >> Hello Devs,
      >>
      >> I am Patrick Sharp. I just graduated with a BS is computer science. Forgive my ignorance.
      >>
      >> As per bip-0002 I have scoured each bip available on the wiki to see if these ideas have already been formally proposed and now as per bip-0002 post these ideas here.
      >>
      >> First and foremost I acknowledge that these ideas are not original nor new.
      >>
      >> Trimming and demurrage:
      >>
      >> I am fully aware that demurrage is a prohibited change. I hereby contest. For the record I am not a miner, I am just aware of the economics that drive the costs of bitcoin.
      >>
      >> Without the ability to maintain some sort of limit on the maximum length or size of the block chain, block chain is not only unsustainable in the long run but becomes more and more centralized as the block chain becomes more and more unwieldy.
      >>
      >> Trimming is not a foreign concept. Old block whose transactions are now spent hold no real value. Meaningful trimming is expensive and inhibited by unspent transactions. Old unspent transactions add unnecessary and unfair burden.
      >> Old transactions take up real world space that continues incur cost while these transactions they do not continue to contribute to any sort of payment for this cost.
      >> One can assume that anybody with access to their bitcoins has the power to move these bitcoins from one address to another (or at least that the software that holds the keys to their coins can do it for them) and it is not unfair to require them to do so at least once every 5 to 10 years.
      >> Given the incentive to move it or lose it and software that will do it for them, we can assume that any bitcoin not moved is most likey therefore lost.
      >> moving these coins will cost a small transaction fee which is fair as their transactions take up space, they need to contribute
      >> most people who use their coins regularly will not even need to worry about this as their coins are moved to a change address anyway.
      >> one downside is that paper wallets would then have an expiration date, however I do not think that a paper wallet that needs to be recycled every 5 to 10 years is a terrible idea.
      >> Therefore I propose that the block chain length be limited to either 2^18 blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than 10 years. I propose that each time a block is mined the the oldest block(s) (no more than two blocks) beyond this limit is trimmed from the chain and that its unspent transactions are allowed to be included in the reward of the mined block.
      >>
      >> This keeps the block chain from tending towards infinity. This keeps the costs of the miners balanced with the costs of the users.
      >>
      >> Even though I believe this idea will have some friction, it is applicable to the entire community. It will be hard for some users to give up small benefits that they get at the great cost of miners, however miners run the game and this fair proposal is in in their best interest in two different ways. I would like your thoughts and suggestions. I obviously think this is a freaking awesome idea. I know it is quite controversial but it is the next step in evolution that bitcoin needs to take to ensure immortality.
      >>
      >> I come to you to ask if this has any chance of acceptance.
      >>
      >> -Patrick
      
      [-- Attachment #2: Type: text/html, Size: 8227 bytes --]
      
      ^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-09-26  9:22 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-25 21:54 [bitcoin-dev] idea post: trimming and demurrage Patrick Sharp
2017-09-25 23:30 ` Richard Hein
2017-09-25 23:34 ` ZmnSCPxj
2017-09-26  1:33   ` Patrick Sharp
2017-09-25 22:43     ` Aymeric Vitte
2017-09-26  7:10     ` Алексей Мутовкин
2017-09-26  7:50     ` ZmnSCPxj

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox