Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1566EAA6 for ; Tue, 12 Dec 2017 01:10:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4253EF4 for ; Tue, 12 Dec 2017 01:10:40 +0000 (UTC) Received: by mail-it0-f49.google.com with SMTP id d16so20423234itj.1 for ; Mon, 11 Dec 2017 17:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mQZ/M9v4rMG7Nw88uer+2201z2s07y50KFfDJa0lJv8=; b=Mqfmw3XSSXzjJbPDdvPTRxYdaMcxvCPdViGyhCjcVtHHAG+x9rVdnPEIp3qrfkYmaV +z2n7yvabwRdhtw8wWb2J8cEcCG8s7jyEdW0xSCO2uY+kbrhnXAKxAOM0Yh8L+gEVrFV hNc6sHUag/JW7GRYyovdVU5QyZg8BL5WHTh802aJpHcnQjhty+IqQ465YtOhhKGhJVl7 rYxon7yBvyH369gq8B9b7BJaTQmCSUe22y1Z0kBgWRmGSf/8dD05/W+9vxqKRD50njBY KZbbW6OLSg+Y0TMVGimiYmrPg5VqTawVx8TFa1BpfgD8FI4Bcn79BcMM60DYiNwX7UE4 a6Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mQZ/M9v4rMG7Nw88uer+2201z2s07y50KFfDJa0lJv8=; b=rIptCPB4ZFMkVgdnT+BnSkRaxtWJfjUU305zPqysJ7UBy/Jq1m1RlkpeIssJqGolpu H0kuVlfOtu6Mejn6Rl/bDRZSZ6cLuJAj/kjETv1DR/KsOYVRf4HtJOVeczLblysb1by/ aespKTLHnsNc2e1ZDtiqNfXTexu1B0hhOH2w98VTu80W6x8ZcVEydVLgoE81aOMnEJ6S /TzsmP/k1V638gGckjH7c6dTkzJE844QkpUXIKvoGqRl/6slafSokdaFIGq8bh6NTgX1 9GcpILGEKfJ8xeXd92WyuKbH4QaCbVMj3V2la510q6zOYuSdwYnHrMzr7Y/A1O8DX7Mh x2hg== X-Gm-Message-State: AKGB3mKNGi/cZxCIteMzK+8tNc5MqKxLDgE3XEj5qxj33G3wgrYSulau B9n1SOXLAvqbd42cpF2eQA6JrGZJOYvTvajz9bwkkg== X-Google-Smtp-Source: ACJfBovKb+xTT34jseFRrD5z6xlXKM3z0PCW8d0pDn/fgxumoWOMQ1Ba5P423wGqOBlhHT15ciK4i6cz+7A0X19NXTI= X-Received: by 10.107.12.212 with SMTP id 81mr2978623iom.75.1513041039236; Mon, 11 Dec 2017 17:10:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.148.69 with HTTP; Mon, 11 Dec 2017 17:10:38 -0800 (PST) Received: by 10.107.148.69 with HTTP; Mon, 11 Dec 2017 17:10:38 -0800 (PST) In-Reply-To: <201712111834.13672.luke@dashjr.org> References: <201712111834.13672.luke@dashjr.org> From: Teweldemedhin Aberra Date: Tue, 12 Dec 2017 04:10:38 +0300 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="001a113f8f84aca26605601a51c4" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 12 Dec 2017 01:11:34 +0000 Subject: Re: [bitcoin-dev] BIP - Dead Man's Switch X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 01:10:41 -0000 --001a113f8f84aca26605601a51c4 Content-Type: text/plain; charset="UTF-8" Hi, The only solution other than Dead Man's Switch to avoid gradual loss Bitcoins in transaction is increasing the divisibiliy of Bitcoins. Then Bitcoin values will need integer of more than 64 bits. Could that be done with soft fork? On Dec 11, 2017 9:42 PM, wrote: > You can implement this already, but only for ~1 year expirations. > > IF ELSE <1 year> CHECKSEQUENCEVERIFY ENDIF > > Perhaps it would make sense to propose a flag extending the range of > relative > lock-times so you can do several years? > > Luke > > > On Monday 11 December 2017 5:30:37 PM Teweldemedhin Aberra via bitcoin-dev > wrote: > > It is estimated that about 4 million of the about 16.4 Bitcoins ever > mined > > are lost forever because no one knows the private keys of some Bitcoin > > addresses. This effectively mean there are actually only 14.4 million > > Bitcoins in circulation even though 16.4 million are mined. There is no > way > > of eliminating the human errors that cause these losses of Bitcoin from > > circulation, while the number of Bitcoin that will ever be mined is > capped > > at 21 million. This means the total number of Bitcoins that are in > > circulation will eventually become zero, bringing the network to an end. > > > > The solution this BIP proposes is to implementing a dead man's switch to > > Bitcoin addresses. The dead man's switch causes the Bitcoins assigned to > > dormant addresses to automatically expire. A Bitcoin address is deemed > > dormant if it is not used in transactions for some fixed length of time, > > say ten years. > > > > The calculation of the miner's reward should take into account the > Bitcoins > > that has expired. This means there is a possibility that miner's reward > can > > increase if sufficient number of Bitcoins expire. > > > > Ref: > > > > http://fortune.com/2017/11/25/lost-bitcoins/ > > > > > > source=link&utm_campa > > ign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. > > www.avast.com > > source=link&utm_campa > > ign=sig-email&utm_content=webmail&utm_term=link> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > --001a113f8f84aca26605601a51c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The only solution other than Dead Ma= n's Switch to avoid gradual loss Bitcoins in transaction is increasing = the divisibiliy of Bitcoins. Then Bitcoin values will need integer of more = than 64 bits. Could that be done with soft fork?

On Dec 11, 2017 9:42 PM, <bitcoin-dev-request@lists.linuxfoundation.org> wrote:
You can implement this = already, but only for ~1 year expirations.

IF <normal script> ELSE <1 year> CHECKSEQUENCEVERIFY ENDIF

Perhaps it would make sense to propose a flag extending the range of relati= ve
lock-times so you can do several years?

Luke


On Monday 11 December 2017 5:30:37 PM Teweldemedhin Aberra via bitcoin-dev<= br> wrote:
> It is estimated that about 4 million of the about 16.4 Bitcoins ever m= ined
> are lost forever because no one knows the private keys of some Bitcoin=
> addresses. This effectively mean there are actually only 14.4 million<= br> > Bitcoins in circulation even though 16.4 million are mined. There is n= o way
> of eliminating the human errors that cause these losses of Bitcoin fro= m
> circulation, while the number of Bitcoin that will ever be mined is ca= pped
> at 21 million. This means the total number of Bitcoins that are in
> circulation will eventually become zero, bringing the network to an en= d.
>
> The solution this BIP proposes is to implementing a dead man's swi= tch to
> Bitcoin addresses. The dead man's switch causes the Bitcoins assig= ned to
> dormant addresses to automatically expire. A Bitcoin address is deemed=
> dormant if it is not used in transactions for some fixed length of tim= e,
> say ten years.
>
> The calculation of the miner's reward should take into account the= Bitcoins
> that has expired. This means there is a possibility that miner's r= eward can
> increase if sufficient number of Bitcoins expire.
>
> Ref:
>
> http://fortune.com/2017/11/25/lost-bitcoins/
>
>
> <https= ://www.avast.com/sig-email?utm_medium=3Demail&utm_source=3Dli= nk&utm_campa
> ign=3Dsig-email&utm_content=3Dwebmail&utm_term=3Dicon>= Virus-free.
> = www.avast.com
> <https= ://www.avast.com/sig-email?utm_medium=3Demail&utm_source=3Dli= nk&utm_campa
> ign=3Dsig-email&utm_content=3Dwebmail&utm_term=3Dlink>=
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--001a113f8f84aca26605601a51c4--