Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-05-10 Thread アルム カールヨハン via bitcoin-dev
He can use pruning to only store the last X MB of the blockchain. It will store the UTXO set though, which is a couple of GBs. In total, a pruned node with pruning set to 1000 MB ends up using 4.5 GB currently, but it varies slightly due to the # of UTXOs in existence. On Thu, May 10, 2018 at

Re: [bitcoin-dev] Simple lock/unlock mechanism

2018-03-05 Thread アルム カールヨハン via bitcoin-dev
On Wed, Feb 28, 2018 at 10:30 PM, Anthony Towns <a...@erisian.com.au> wrote: > On Wed, Feb 28, 2018 at 04:34:18AM +0000, アルム カールヨハン via bitcoin-dev wrote: >> 1. Graftroot probably breaks this (someone could just sign the >> time-locked output with a script that has no t

Re: [bitcoin-dev] Simple lock/unlock mechanism

2018-03-05 Thread アルム カールヨハン via bitcoin-dev
On Thu, Mar 1, 2018 at 5:11 AM, アルム カールヨハン wrote: > That kind of defeats the purpose. If you go through the trouble of > doing that, you can just do multisig and skip the freezing part > entirely. A robber would have to get you and the cosigner to sign in > both cases, and the

Re: [bitcoin-dev] Simple lock/unlock mechanism

2018-02-28 Thread アルム カールヨハン via bitcoin-dev
A few p.s.'es: 1. Graftroot probably breaks this (someone could just sign the time-locked output with a script that has no time-lock). 2. Address reuse of discarded privkeys would be a problem. A way to alleviate might be that freezing includes a send to a new address and the privkeys for that

[bitcoin-dev] Simple lock/unlock mechanism

2018-02-28 Thread アルム カールヨハン via bitcoin-dev
With the recent trend of physically robbing people for bitcoin (or other cryptocurrencies), I thought it would be beneficial to introduce a standard for locking up a portion of your bitcoin in a simple 'gotta-wait-awhile' system. The idea is to simply create a transaction spending a set of UTXOs

[bitcoin-dev] RFC BIP-0002: Defer, not reject.

2020-10-13 Thread アルム カールヨハン via bitcoin-dev
Hello, I am making a minor proposed change to BIP-0002 https://github.com/bitcoin/bips/pull/1012 I propose that we change the 3-year-rule to allow anyone to change the status of a BIP to "Deferred", rather than "Rejected". Rejecting a BIP already has ambiguous meaning in BIP-0002 as it stands,

[bitcoin-dev] Signet update

2020-07-26 Thread アルム カールヨハン via bitcoin-dev
Hello, Some progress (courtesy of ajtowns!) has been made on the Signet proposal (BIP-325): * Block signatures are now verified as transactions Among other things, this means Signet is (probably) compatible with PSBT (thanks sipa!), and no longer requires the custom "simple signature

Re: [bitcoin-dev] RFC BIP-0002: Defer, not reject.

2020-11-02 Thread アルム カールヨハン via bitcoin-dev
Follow-up to this: there is now an alternative to this which proposes that the rejection criteria in BIP 2 is updated to require there to be an actual concern. This is here: https://github.com/bitcoin/bips/pull/1016 Please nod or something at either or both of them. On Tue, Oct 13, 2020 at 7:06