アルム　カールヨハン [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-04 to 2020-11-02
💬 Posted a total of 9 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:27:30

- reply

📅 Original date posted:2020-11-02
📝 Original message: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 PM アルム　カールヨハン <karl at dglab.com> wrote:
>
> 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, with "hard" rejects:
>
> > The BIP editor will not unreasonably reject a BIP. Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
>
> and "soft" rejects:
>
> > BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
>
> My proposal is that we disambiguate the second into "deferred" instead.
>
> Alternatively, we add a new status e.g. "Inactive".

2023-06-07 18:27:28

- reply

📅 Original date posted:2020-10-13
📝 Original message: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, with "hard" rejects:
> The BIP editor will not unreasonably reject a BIP. Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
and "soft" rejects:
> BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
My proposal is that we disambiguate the second into "deferred" instead.
Alternatively, we add a new status e.g. "Inactive".

2023-06-07 18:26:03

- reply

📅 Original date posted:2020-07-26
📝 Original message: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 verifier/creator" stuff.
This unfortunately means Signet will hard fork, but I don't think
anyone is using it seriously yet, so it shouldn't be an issue.
The BIP pull request is here: https://github.com/bitcoin/bips/pull/947
Feedback welcome.

2023-06-07 18:12:01

- reply

📅 Original date posted:2018-05-10
📝 Original message: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 9:56 AM, Segue via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning
> without running a fully-fledged bitcoin block chain? (Yubin Ruan)." The
> inquirer was asking because he didn't have much space to store the entire
> blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THIS note and slightly off-topic but relevant, why can't chunks of
> blockchain peel off the backend periodically and be archived, say on minimum
> of 150 computers across 7 continents?
>
> It seems crazy to continue adding on to an increasingly long chain to
> infinity if the old chapters (i.e. more than, say, 2 years old) could be
> stored in an evenly distributed manner across the planet. The same 150
> computers would not need to store every chapter either, just the index would
> need to be widely distributed in order to reconnect with a chapter if
> needed. Then maybe it is no longer a limitation in the future for people
> like Yubin. "
>
> It was suggested by a couple of lightning developers that I post this idea
> on the bitcoin-dev list. So, here I post :).
>
> Segue
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:11:03

- reply

📅 Original date posted:2018-03-05
📝 Original message:On Thu, Mar 1, 2018 at 5:11 AM, アルム　カールヨハン <karl at dglab.com> 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 CLTV could be overridden with graftroot.
I think I'm confused on this. To use graftroot it has to be a pubkey,
not a p2sh thing.
-Kalle.

2023-06-07 18:11:02

- reply

📅 Original date posted:2018-03-01
📝 Original message:On Wed, Feb 28, 2018 at 10:30 PM, Anthony Towns <aj at 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 time-lock).
>
> Making the graftroot key be a 2-of-2 muSig with an independent third party
> that commits to only signing CLTV scripts could avoid this. Making it
> 3-of-3 or 5-of-5 could be even better if you can find multiple independent
> services that will do it.
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 CLTV could be overridden with graftroot.
On Wed, Feb 28, 2018 at 11:36 PM, Adam Back <adam.back at gmail.com> wrote:
> Coincidentally I had thought of something similar to what Kalle posted
> about a kind of software only time-lock vault, and described the idea
> to a few people off-list. Re. Root incompatibility, if the key is
> deleted (as it must be) then a delegated signature can not be made
> that bypasses the CSV timeout restriction, so Root should not be
> incompatible with this. I think it would be disadvantageous to mark
> keys as Rootable vs not in a sighash sense, because then that is
> another privacy/fungibility loss eroding the uniformity advantage of
> Root when the delegate is not used.
1. Create TX1=(tx, sig) from UTXO A to p2sh B which has a CSV
timelock. Discard privkey A.
2. After broadcasting TX1, you need privkey B to spend it.
3. Use graftroot and privkey B with a script without timelock to spend B.
The robber can simply force you to execute step 3, since you have the
privkey to B.
> One drawback is deleting keys may itself be a bit difficult to assure
> with HD wallet seeds setup-time backup model.
That's a good point. Even more of a reason to include as part of
'freezing' a send to a new ephemeral key as 'initialization'. Sucks to
pay triple fees though (freeze ephemeral + unfreeze + actual use).
> As Anthony described I think, a simpler though less robust model would
> be to have a third party refuse to co-sign until a pre-arranged time,
> and this would have the advantage of not requiring two on-chain
> transactions.
I was hoping there was a way for a person to simply lock-up the major
portion of their coins easily.
As a sidenote: a security firm (e.g. one that comes to your house when
the alarm goes off) could have a service where seeing an unfreeze
transaction which you have told them about without you giving a heads
up beforehand is equal to alarm going off.
-Kalle.

2023-06-07 18:11:01

- reply

📅 Original date posted:2018-02-28
📝 Original message: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 new one are discarded instead. One extra
transaction, but reduces the risk of accidentally throwing away
`donations4mybook` vanity keys.
-Kalle.
On Wed, Feb 28, 2018 at 3:47 AM, アルム　カールヨハン <karl at dglab.com> wrote:
> 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 to
> a P2SH address with an OP_CSV attached to it, and then throw away the
> private keys.
>
> To spend the bitcoin, you would have to broadcast the transaction and
> wait the given amount of time, then use the new txout.
>
> There are several ways to shoot yourself in the foot trying to do this
> manually, but e.g. Bitcoin Core could handle this in a fairly
> straightforward manner by introducing two new commands, which I call
> freeze and unfreeze:
>
> bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default 1]
>
> E.g. bitcoin-cli freeze 10 5
> E.g. bitcoin-cli freeze ["abc123:1", "def346:0"] 3
>
> The unfreeze command would by default list all freezes:
>
> bitcoin-cli unfreeze
> txid days status
> bcd123 5 frozen
> dca999 3 frozen
>
> including the txid would broadcast the unfreeze and status would
> become 'thawing' until the amount becomes available:
>
> bitcoin-cli unfreeze bcd123
>
> bitcoin-cli unfreeze
> txid days status
> bcd123 5 thawing
> dca999 3 frozen
>
> The benefit of this is that it becomes physically impossible for you
> to spend the coins until you thaw them, and if this becomes standard
> enough, it should disincentivize potential robbers as it would be
> expected that you keep most of your assets locked up. They could of
> course hold you hostage until the period is over, which may be worse,
> but I think that kind of operation would be substantially more
> difficult than a simply rob-and-run.
>
> The drawback is that you have to broadcast a transaction in order to
> spend the content, and you cannot bump the fee so the transaction
> could get stuck in a high-fee situation.
>
> -Kalle.

2023-06-07 18:11:01

- reply

📅 Original date posted:2018-02-28
📝 Original message: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 to
a P2SH address with an OP_CSV attached to it, and then throw away the
private keys.
To spend the bitcoin, you would have to broadcast the transaction and
wait the given amount of time, then use the new txout.
There are several ways to shoot yourself in the foot trying to do this
manually, but e.g. Bitcoin Core could handle this in a fairly
straightforward manner by introducing two new commands, which I call
freeze and unfreeze:
bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default 1]
E.g. bitcoin-cli freeze 10 5
E.g. bitcoin-cli freeze ["abc123:1", "def346:0"] 3
The unfreeze command would by default list all freezes:
bitcoin-cli unfreeze
txid days status
bcd123 5 frozen
dca999 3 frozen
including the txid would broadcast the unfreeze and status would
become 'thawing' until the amount becomes available:
bitcoin-cli unfreeze bcd123
bitcoin-cli unfreeze
txid days status
bcd123 5 thawing
dca999 3 frozen
The benefit of this is that it becomes physically impossible for you
to spend the coins until you thaw them, and if this becomes standard
enough, it should disincentivize potential robbers as it would be
expected that you keep most of your assets locked up. They could of
course hold you hostage until the period is over, which may be worse,
but I think that kind of operation would be substantially more
difficult than a simply rob-and-run.
The drawback is that you have to broadcast a transaction in order to
spend the content, and you cannot bump the fee so the transaction
could get stuck in a high-fee situation.
-Kalle.

2023-06-07 17:56:52

- reply

📅 Original date posted:2017-03-04
📝 Original message:I am surprised nothing like this exists already, so am all for the idea.
Maybe I am misunderstanding, but I'm not sure you want to have
thousand separators and other locale stuff in there. All currencies
including USD are often shown in Swedish using space or dot as
thousand separator and comma as decimal separator, e.g. "1.234,56 USD"
or "1 234,56 USD". I.e. this is something that the locale of the
user's environment defines, not something the server should have
opinions about. It is also not ideal to propose a given format based
on the user's locale, as some users have preferences for this (I
personally use US locale for numbers, and a US person who is visiting
Sweden wouldn't want this to suddenly change).
-Kalle.
On Sat, Mar 4, 2017 at 12:27 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Investigating what it would take to add fiat currency information to Bitcoin
> Knots, I noticed Electrum currently has many implementations, one for each
> exchange rate provider, due to lack of a common format for such data.
>
> Therefore, I put together an initial draft of a BIP that could standardise
> this so wallets (or other software) and exchange rate providers can simply
> interoperate without a lot of overhead reimplementing the same thing many
> ways.
>
> One thing I am unsure about, is that currently this draft requires using XBT
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis, but those
> don't really have a pseudo-ISO currency code to fit in nicely...
>
> Current draft here:
> https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.mediawiki
>
> Thoughts? Anything critical missing? Ways to make the interface better?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev