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

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 alre

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

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 > secon

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

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. _

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

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 downsid

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

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 maintai

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

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 > > di

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

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

[bitcoin-dev] "Compressed" headers stream

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

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

> 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.linuxfo

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

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 v

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

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 r

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

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 wou

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

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, Teweldemedh

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

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

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

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 > > wh

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

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

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

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 elim