Re: [bitcoin-dev] BIP - Dead Man's Switch

[Teweldemedhin Aberra via bitcoin-dev]

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_campa
> > ign=sig-email_content=webmail_term=icon> Virus-free.
> > www.avast.com
> >  source=link_campa
> > ign=sig-email_content=webmail_term=link>
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication

[Peter Todd via bitcoin-dev]

On Mon, Dec 11, 2017 at 10:23:21PM +, Pulat Yunusov wrote:
> Thank you for your post, Peter. Why is it necessary to centralize the p-o-p
> sidechain and have a maintainer? It seems the Bitcoin network will secure
> the most critical element, which is the witness authenticity. Wouldn't a
> second decentralized network be able to perform the functions of the
> maintainer so the entire system is trustless?

It's centralized in that writeup basically because centralizing it is
*significantly* easier; it's not obvious how to maintain a proof-of-publication
ledger in a decentralized, scalable, way.

In the centralized version it's obvious how to scale process by which the
ledger is built via sharding: split the key range up as needed and assign each
range to a separate server (be it an actual server, or a fault-tolerate cluster
acting as a single server) that reports back to a master co-ordinator who
builds the tree from the per-range sub-tips reported back by the shards. If
required due to extreme scale, do this on multiple levels. Similarly, once the
tree is built, storage and distribution can obviously be done via sharding.

In short, no matter how much the transaction rate on a PoP ledger grows, it's
possible to meet demand by simply buying more hardware, and distributing the
key space over a larger number of smaller shards.

But that simple architecture only works with trust: the coordinator is trusting
the shards to build valid trees and distribute the results. Without trust, how
do you ensure that actually happens? How do you pick who is assigned to what
shard? How do you incentivise correct behavior?

That's not to say this is impossible - in fact my prior work on Treechains(1)
is an attempt to do just this - but it's an orders of magnitude more difficult
problem.

1) 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html,
   "[Bitcoin-development] Tree-chains preliminary summary", Mar 25th 2014,
   Peter Todd

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] "Compressed" headers stream

[Gregory Maxwell via bitcoin-dev]

On Mon, Dec 11, 2017 at 10:41 PM, Tier Nolan via bitcoin-dev
 wrote:
> There is a method called "high hash highway" that allows compact proofs of
> total POW.

That provides no security without additional consensus enforced
commitments, so I think pretty off-topic for this discussion.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] "Compressed" headers stream

[Tier Nolan via bitcoin-dev]

On Mon, Dec 11, 2017 at 9:56 PM, Jim Posen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Omitting nBits entirely seems reasonable, I wrote up a possible
> implementation here
> .
> The downside is that it is more complex because it leaks into the
> validation code. The extra 4 byte savings is certainly nice though.
>

A compromise would be to have 1 byte indicating the difference since the
last header.

Since the exponent doesn't use the full range you could steal bits from
there to indicate mode.

- no change
- mantissa offset (for small changes)
- full difficulty

This would support any nBits rule and you say 3 of the 4 bytes.


> Can you elaborate on how parallel header fetching might work? getheaders
> requests could probably already be pipelined, where the node requests the
> next 2,000 headers before processing the current batch (though would make
> sense to check that they are all above min difficulty first).
>

I suggest adding a message where you can ask for the lowest N hashes
between 2 heights on the main chain.

The reply is an array of {height, header} pairs for the N headers with the
lowest hash in the specified range.

All peers should agree on which headers are in the array.  If there is
disagreement, then you can at least narrow down on which segment there is
disagreement.

It works kind of like a cut and choose.  You pick one segment of the ones
he gave you recursively.

You can ask a peer for proof for a segment between 2 headers of the form.

- first header + coinbase with merkle branch
- all headers in the segment

This proves the segment has the correct height and that all the headers
link up.

There is a method called "high hash highway" that allows compact proofs of
total POW.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication

[Pulat Yunusov via bitcoin-dev]

Thank you for your post, Peter. Why is it necessary to centralize the p-o-p
sidechain and have a maintainer? It seems the Bitcoin network will secure
the most critical element, which is the witness authenticity. Wouldn't a
second decentralized network be able to perform the functions of the
maintainer so the entire system is trustless?

On Tue, Dec 5, 2017 at 5:16 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I recently wrote this up for a client, and although the material has been
> covered elsewhere, I thought being a worked example it might be of
> interest,
> particularly while sidechains are being discussed again.
>
> As per (1) I've perhaps foolishly committed to making an even more fleshed
> out
> example, so peer review here before it gets to an even wider audience
> would be
> appreciated. :)
>
> 1) https://twitter.com/petertoddbtc/status/937401676042039296
>
>
> tl;dr: We can do trustless with respect to validity, trusted with respect
> to
> censorship resistance, indivisible asset transfer with less than
> 5MB/year/token
> of proof data, assuming token ownership is updated every two hours, at a
> rate
> of ~500,000 transfers per second. The scalability of this scheme is linear
> with
> respect to update interval, and logarithmic with respect to overall
> transfer
> rate.
>
>
> ## Single-Use-Seal Definition
>
> Analogous to the real-world, physical, single-use-seals used to secure
> shipping
> containers, a single-use-seal primitive is a unique object that can be
> closed
> over a message exactly once. In short, a single-use-seal is an abstract
> mechanism to prevent double-spends.
>
> A single-use-seal implementation supports two fundamental operations:
>
> Close(l,m) -> w_l
> Close seal l over message m, producing a witness w_l
>
> Verify(l,w_l,m) -> bool
> Verify that the seal l was closed over message m
>
> A single-use-seal implementation is secure if it is impossible for an
> attacker
> to cause the Verify function to return true for two distinct messages m_1,
> m_2,
> when applied to the same seal (it _is_ acceptable, although non-ideal, for
> there to exist multiple witnesses for the same seal/message pair).
>
> Practical single-use-seal implementations will also obviously require some
> way
> of generating new single-use-seals. Secondly, authentication is generally
> useful. Thus we have:
>
> Gen(p) -> l
> Generate a new seal bound to pubkey p
>
> Close(l,m,s) -> w_l
> Close seal l over message m, authenticated by signature s valid
> for pubkey p
>
> Obviously, in the above, pubkey can be replaced by any cryptographic
> identity
> scheme, such as a Bitcoin-style predicate script, zero-knowledge proof,
> etc.
>
> Finally, _some_ single-use-seal implementations may support the ability to
> prove that a seal is _open_, e.g. as of a given block height or point in
> time.
> This however is optional, and as it can be difficult to implement, it is
> suggested that seal-using protocols avoid depending on this functionality
> existing.
>
>
> ## Indivisible Token Transfer
>
> With a secure single-use-seal primitive we can build a indivisible token
> transfer system, allowing the secure transfer of a token from one party to
> another, with the seals preventing double-spends of that indivisible token.
>
> Each token is identified by its genesis seal l_0. To transfer a token, the
> most
> recent seal l_n is closed over a message committing to a new seal, l_{n+1},
> producing a witness w_{l_n} attesting to that transfer. This allows a
> recipient
> to securely verify that they have received the desired token as follows:
>
> 1. Generate a fresh, open, seal l_{n+1} that only they can close.
> 2. Ask the sender to close their seal, l_n, over the seal l_{n+1}
> 3. Verify that there exist a set of valid witnesses w_0 .. w_n, and seals
>l_0 .. l_n, such that for each seal l_i in i = 0 .. n, Verify(l_i, w_i,
> l_{i+1})
>returns true.
>
> Since a secure single-use-seal protocol prohibits the closure of a single
> seal
> over multiple messages, the above protocol ensures that the token can not
> be
> double-spent. Secondly, by ensuring that seal l_{n+1} can be closed by the
> recipient and only the recipient, the receipient of the token knows that
> they
> and they alone have the ability to send that token to the next owner.
>
>
> ## Divisible Asset Transfer
>
> In the case of a divisible asset, rather than transferring a single,
> unique,
> token we want to transfer a _quantity_ of an asset. We can accomplish this
> in a
> manner similar how Bitcoin's UTXO-based transactions, in which one or more
> inputs are combined in a single transaction, then split amongst zero or
> more
> outputs.
>
> We define the concept of an _output_. Each output x is associated with a
> seal l
> and value v. For each asset we define a set of _genesis outputs_, X_G,
> whose
> validity is assumed.
>
> To transfer divisible assets we further 

Re: [bitcoin-dev] "Compressed" headers stream

[Jim Posen via bitcoin-dev]

On Mon, Dec 11, 2017 at 1:04 PM, Gregory Maxwell  wrote:

> On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev
>  wrote:
> > Firstly, I don't like the idea of making the net header encoding
> dependent
> > on the specific header validation rules that Bitcoin uses (eg. the fact
> that
> > difficulty is only recalculated every 2016 blocks). This would be
> coupling
>
> In the last proposal I recall writing up, there was a one byte flag on
> each header to indicate what was included.
>
>
Is there a link somewhere to that proposal? The only thing I could find was
your forwarded email

on
this thread.


> Nbits _never_ needs to be sent even with other consensus rules because
> its more or less necessarily a strict function of the prior headers.
> This still holds in every clone of Bitcoin I'm aware of; sending it
> with the first header in a group probably makes sense so it can be
> checked independently.
>
> > with insufficient benefit.
>
> another >18% reduction in size beyond the removal of prev. is not
> insubstantial by any means.  I don't think it should lightly be
> ignored.
>
>
Omitting nBits entirely seems reasonable, I wrote up a possible
implementation here
.
The downside is that it is more complex because it leaks into the
validation code. The extra 4 byte savings is certainly nice though.


> Prev omission itself is not, sadly, magically compatible:  I am quite
> confident that if there is a bitcoin hardfork it would recover the
> nbits/4-guarenteed always-zero bits of prev to use as extra nonce for
> miners. This has been proposed many times, implemented at least once,
> and the current requirement for mining infrastructure to reach inside
> the coinbase txn to increment a nonce has been a reliable source of
> failures.  So I think we'd want to have the encoding able to encode
> leading prev bits.
>
> Many altcoins also change the header structures. If the better thing
> is altcoin incompatible, we should still do it. Doing otherwise would
> competitively hobble Bitcoin especially considering the frequent
> recklessly incompetent moves made by various altcoins and the near
> total lack of useful novel development we've seen come out of the
> clones.
>
> Probably the most important change in a new header message wouldn't be
> the encoding, but it would be changing the fetching mechanism so that
> header sets could be pulled in parallel, etc.
>
> I would rather not change the serialization of existing messages,
> nodes are going to have to support speaking both messages for a long
> time, and I think we already want a different protocol flow for
> headers fetching in any case.
>

Can you elaborate on how parallel header fetching might work? getheaders
requests could probably already be pipelined, where the node requests the
next 2,000 headers before processing the current batch (though would make
sense to check that they are all above min difficulty first).

I'm open to more ideas on how to optimize the header download or design the
serialization format to be more flexible, but I'm concerned that we forgo a
40-45% bandwidth savings on the current protocol for a long time because
something better might be possible later on or there might be a hard fork
that at some point requires another upgrade. I do recognize that supporting
multiple serialization formats simultaneously adds code complexity, but in
this case the change seems simple enough to me that the tradeoff is worth
it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] "Compressed" headers stream

[Gregory Maxwell via bitcoin-dev]

On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev
 wrote:
> Firstly, I don't like the idea of making the net header encoding dependent
> on the specific header validation rules that Bitcoin uses (eg. the fact that
> difficulty is only recalculated every 2016 blocks). This would be coupling

In the last proposal I recall writing up, there was a one byte flag on
each header to indicate what was included.

Nbits _never_ needs to be sent even with other consensus rules because
its more or less necessarily a strict function of the prior headers.
This still holds in every clone of Bitcoin I'm aware of; sending it
with the first header in a group probably makes sense so it can be
checked independently.

> with insufficient benefit.

another >18% reduction in size beyond the removal of prev. is not
insubstantial by any means.  I don't think it should lightly be
ignored.

Prev omission itself is not, sadly, magically compatible:  I am quite
confident that if there is a bitcoin hardfork it would recover the
nbits/4-guarenteed always-zero bits of prev to use as extra nonce for
miners. This has been proposed many times, implemented at least once,
and the current requirement for mining infrastructure to reach inside
the coinbase txn to increment a nonce has been a reliable source of
failures.  So I think we'd want to have the encoding able to encode
leading prev bits.

Many altcoins also change the header structures. If the better thing
is altcoin incompatible, we should still do it. Doing otherwise would
competitively hobble Bitcoin especially considering the frequent
recklessly incompetent moves made by various altcoins and the near
total lack of useful novel development we've seen come out of the
clones.

Probably the most important change in a new header message wouldn't be
the encoding, but it would be changing the fetching mechanism so that
header sets could be pulled in parallel, etc.

I would rather not change the serialization of existing messages,
nodes are going to have to support speaking both messages for a long
time, and I think we already want a different protocol flow for
headers fetching in any case.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] "Compressed" headers stream

[Jim Posen via bitcoin-dev]

I want to resurrect this thread from August/September because it seems like
a significant improvement for light clients at very little cost. From the
mailing list, it seems like this got stalled in determining how many more
bytes could be save in addition to the prev_block.

The ideas I've gathered from Greg Maxwell's forwarded email are:

1. Omit nBits altogether and have the receiving node determine it from
chain context.
2. Include nBits only on headers with a height that is a multiple of 2016
since it does not change in between.
3. Compress nTime to two bytes by using the bounds on allowed values from
the consensus rules.

I propose just moving ahead with only the exclusion of the prev_block, as
IMO the other savings are not worth the added complexity.

Firstly, I don't like the idea of making the net header encoding dependent
on the specific header validation rules that Bitcoin uses (eg. the fact
that difficulty is only recalculated every 2016 blocks). This would be
coupling together the two layers, breaking net compatibility for some alts,
and possibly making consensus rule changes even more difficult for a
savings with insufficient benefit. So if you buy that argument, I'm not in
favor of #2 or #3.

Option 1 is still viable, though it has some downsides. The implementation
leaks into the validation code, whereas calculating prev_block can occur
just at the net layer (see implementation below). Also, nodes would now be
*required* to sync the header chain from the genesis block, whereas they
had the option of starting from some checkpoint before.

So switching gears, I'd like to ask what the best way to actually implement
this change is. Solutions I can think of are:

1. New headers command name like "cmpctheaders" or "headersv2".
2. Change serialization of existing headers message in a new protocol
version.
3. Change serialization of existing headers message with new service bit.

I wrote up some proof-of-concept implementations in Core a) just omitting
prev_block

and b) omitting nBits as well
.
If people think a) is reasonable, I'll write up a BIP.


> Hi everyone, the Bitcoin headers are probably the most condensed and
> important piece of data in the world, their demand is expected to grow.
> When sending a stream of continuous block headers, a common case in IBD and
> in disconnected clients, I think there is a possible optimization of the
> transmitted data: The headers after the first could avoid transmitting the
> previous hash cause the receiver could compute it by double hashing the
> previous header (an operation he needs to do anyway to verify PoW). In a
> long stream, for example 2016 headers, the savings in bandwidth are about
> 32/80 ~= 40% without compressed headers 2016*80=161280 bytes with
> compressed headers 80+2015*48=96800 bytes What do you think? In
> OpenTimestamps calendars we are going to use this compression to give
> lite-client a reasonable secure proofs (a full node give higher security
> but isn't feasible in all situations, for example for in-browser
> verification) To speed up sync of a new client Electrum starts with the
> download of a file 
> ~36MB containing the first 477637 headers. For this kind of clients could
> be useful a common http API with fixed position chunks to leverage http
> caching. For example /headers/2016/0 returns the headers from the genesis
> to the 2015 header included while /headers/2016/1 gives the headers from
> the 2016th to the 4031. Other endpoints could have chunks of 20160 blocks
> or 201600 such that with about 10 http requests a client could fast sync
> the headers
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 31, Issue 22

[Ilan Oh via bitcoin-dev]

Reply to dead man's switch,

Since this topic as gone un-technical,

People can already place a timer on transactions with the script to send
funds if not moved for a given period,

And people are responsible adults, trying to take ahead of every possible
future human error from the protocol perspective looks more like french
socialism than bitcoinism

Le 11 déc. 2017 19:32, <bitcoin-dev-requ...@lists.linuxfoundation.org> a
écrit :

Send bitcoin-dev mailing list submissions to
bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
bitcoin-dev-requ...@lists.linuxfoundation.org

You can reach the person managing the list at
bitcoin-dev-ow...@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   1. Re: BIP - Dead Man's Switch (Radoslaw Biernacki)
   2. Re: BIP - Dead Man's Switch (Pieter Wuille)
   3. Re: BIP - Dead Man's Switch (Chris Riley)


--

Message: 1
Date: Mon, 11 Dec 2017 19:13:26 +0100
From: Radoslaw Biernacki <radoslaw.bierna...@gmail.com>
To: Teweldemedhin Aberra <tewelde...@gmail.com>,Bitcoin Protocol
Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - Dead Man's Switch
Message-ID:
<cadp3c4vfl8ye4c8t5nu_qpoolkdp+emwm_pxmbdb0nj0vbj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Aside from that such change would require a hard fork it also violates one
of basic rules of bitcoin, which has long term consequences for miners and
for whole Bitcoin economy. In short, after altering the supply limit it
would not be "bitcoin" anymore.

On Mon, Dec 11, 2017 at 6:30 PM, Teweldemedhin Aberra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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/
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_
source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_
source=link_campaign=sig-email_content=webmail_term=link>
> <#m_-612306741899295358_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-- next part --
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20171211/82180950/attachment-0001.html>

--

Message: 2
Date: Mon, 11 Dec 2017 10:26:40 -0800
From: Pieter Wuille <pieter.wui...@gmail.com>
To: Nick Pudar <n...@pudar.com>,Bitcoin Dev
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - Dead Man's Switch
Message-ID:
<CAPg+sBi9nYHCcN8ct=_iqwuxdfu1cpwbfbff8wpx-w+kf6h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Dec 11, 2017 10:23, "Nick Pudar via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

This topic has come up several times in recent years. While it is well
intentioned, it can have devastating outcomes for people that want to save
long term. If such a system were implemented, it would force people to move
funds around in order to not get nullified. In that process, it introduces
multiple opportunities for errors. Col

Re: [bitcoin-dev] BIP - Dead Man's Switch

[Luke Dashjr via bitcoin-dev]

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/
> 
> 
>  ign=sig-email_content=webmail_term=icon> Virus-free.
> www.avast.com
>  ign=sig-email_content=webmail_term=link>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - Dead Man's Switch

[Chris Riley via bitcoin-dev]

Hi,
1. If there are 16.4 million mined and 4 million are lost, that results in
12.4 million in circulation vs 14.4 million.
2. Satoshi addressed this as have numerous other people (
https://bitcointalk.org/index.php?topic=198.msg1647#msg1647 ) - lost coins
decrease supply, increasing value of the remaining coins.
3. This assumes this is a problem.  Bitcoin is divisible, 100 million,
potentially more if necessary. (
https://en.bitcoin.it/wiki/Help:FAQ#How_divisible_are_bitcoins.3F)
4. Why is it okay to steal bitcoins from people who's bitcoins have been
"dormant" for a fixed period, 10 years in your example?
5. What happens to bitcoins that, say, Hal Finney still had (if any) and he
put in cold storage while he is in ultimate cold storage (
https://en.wikipedia.org/wiki/Hal_Finney_(computer_scientist)#Death) ?
Ditto for someone, say, in a coma for 11 years, in jail for 11 years or any
other similar event?  Or a 20 year old sets aside coins for retirement.
The following year, the system is changed, and when he looks again after
not paying attention for a decade or two, they are gone.
6. This encourages censorship by miners for people attempting to move coins.
7. This has been discussed many times before and everyone is welcome to
fork bitcoin code and the block chain and convince people to follow this
chain and code.  Then you can see if you can get many people to agree that
this is a good idea.








On Mon, Dec 11, 2017 at 12:30 PM, Teweldemedhin Aberra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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/
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_2495265241835744459_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - Dead Man's Switch

[Pieter Wuille via bitcoin-dev]

On Dec 11, 2017 10:23, "Nick Pudar via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

This topic has come up several times in recent years. While it is well
intentioned, it can have devastating outcomes for people that want to save
long term. If such a system were implemented, it would force people to move
funds around in order to not get nullified. In that process, it introduces
multiple opportunities for errors. Cold storage should be able to stay
cold. I personally would be apprehensive about implementing this kind of a
system.


Furthermore, if it rewards miners with funds that are expired, it creates
terrible incentives. Miners in their best interest could choose to censor
transactions that move funds close to their expiration time, to increase
their own future rewards.

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - Dead Man's Switch

[Radoslaw Biernacki via bitcoin-dev]

Aside from that such change would require a hard fork it also violates one
of basic rules of bitcoin, which has long term consequences for miners and
for whole Bitcoin economy. In short, after altering the supply limit it
would not be "bitcoin" anymore.

On Mon, Dec 11, 2017 at 6:30 PM, Teweldemedhin Aberra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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/
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-612306741899295358_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - Dead Man's Switch

[Nick Pudar via bitcoin-dev]

This topic has come up several times in recent years. While it is well 
intentioned, it can have devastating outcomes for people that want to save long 
term. If such a system were implemented, it would force people to move funds 
around in order to not get nullified. In that process, it introduces multiple 
opportunities for errors. Cold storage should be able to stay cold. I 
personally would be apprehensive about implementing this kind of a system.

...via Android



From: Teweldemedhin Aberra via bitcoin-dev
Sent: Monday, December 11, 1:04 PM
Subject: [bitcoin-dev] BIP - Dead Man's Switch
To: bitcoin-dev@lists.linuxfoundation.org


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/


Virus-free.


www.avast.com




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

[Peter Todd via bitcoin-dev]

On Tue, Dec 05, 2017 at 07:39:32PM +, Luke Dashjr via bitcoin-dev wrote:
> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:
> > I recently submitted a pull request that would turn on RBF by default,
> > which triggered some discussion [2]. To ease the transition for merchants
> > who are reluctant to see their customers use RBF, Matt Corallo suggested
> > that wallets honor a no125=1 flag.
> > 
> > So a BIP-21 URI would look like this:
> > bitcoin:175t...45W?amount=20.3=1
> > 
> > When this flag is set, wallets should not use RBF, regardless of their
> > default, unless the user explicitly overrides the merchant's preference.
> 
> This seems counterproductive. There is no reason to ever avoid the RBF flag. 
> I'm not aware of any evidence it even reduces risk of, and it certainly 
> doesn't prevent double spending. Plenty of miners allow RBF regardless of the 
> flag, and malicious double spending doesn't benefit much from RBF in any case.

I'll second the objection to a no-RBF flag.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - Dead Man's Switch

[Douglas Roark via bitcoin-dev]

With all due respect, this isn't a BIP. It's idle speculation regarding
what one person considers to be a problem and others may not. Please
read https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki and
try again. Among other things:

- Convince us this is a real issue, and that your data is accurate.
Who's to say which coins are truly lost? Maybe the people controlling
the keys are just laying low, wish to use their coins in 2112, etc.
- Propose formulas for how the miners will take everything into account,
and explain why they're acceptable.
- Write code that implements your ideas.

Good luck!

-- 
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joro...@vt.edu
PGP key ID: 26623924



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP - Dead Man's Switch

[Teweldemedhin Aberra via bitcoin-dev]

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/



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev