Federico Tenga [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-07-13 to 2023-04-16
💬 Posted a total of 7 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-09 12:49:34

- reply

📅 Original date posted:2018-03-17
📝 Original message:
You can try pruning, you will still have to validate the whole chain so it
takes time, but you won't need to store all the blockchain on your disk.
On 17 March 2018 at 10:02, Yubin Ruan <ablacktshirt at gmail.com> wrote:
> I just don't have so much space for a storing the whole blockchain on my
> laptop.
>
> Yubin
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180317/870e7667/attachment.html>

2023-06-07 23:20:26

- reply

📅 Original date posted:2023-04-16
🗒️ Summary of this message: RGB Lightning implementation based on LDK available at https://github.com/RGB-Tools/rgb-lightning-sample. RGB aims to build a programmability layer for Bitcoin and Lightning.
📝 Original message:To add some context to the conversation, I would like to point out that
another RGB lightning implementation exists based on LDK, you may want to
check it out to have a better picture of how RGB works on LN:
https://github.com/RGB-Tools/rgb-lightning-sample
On Sun, 16 Apr 2023 at 07:35, David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Dr Orlovsky,
>
> Thank you for writing about your interesting project. Some replies
> inline below:
>
> On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
> > RGB v0.10 can be downloaded and installed as described on
> > <https://rgb.tech>
> > website, which also contains a number of user and developer guidelines.
> > RGB source code can be found on <https://github.com/RGB-WG>
>
> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/
>
> > My goal with RGB was not just to enable assets on Lightning, but that
> > of a much larger scope: to build a programmability layer for Bitcoin
> > and Lightning, which may unlock other cases than just tokens - DAOs,
> > decentralized identities and other things that bitcoin itself was
> > lacking.
>
> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in
> multiparty protocols, as previously described on this list[1] by Ruben
> Somsen? To give my own example of the problem:
>
> - Bob doesn't believe that there's a number which can be multiplied by 2
> to produce 4. He's willing to pay a bounty for proof that he's wrong
> but Bitcoin does not currently provide a multiplication opcode, so he
> can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
>
> - Bob hears that RGB has turing-complete scripting, so he buys some
> random tokens that have an RGB contract which allows him to encumber
> them by any AlumVM script. He then creates a Bitcoin transaction
> signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
> solution to (x * 2 == 4) to spend his RGB-based tokens. He publishes
> a PSBT for the transaction along with the RGB data needed to claim the
> tokens.
>
> - Anyone on the network can now claim the BTC without knowing the
> solution, destroying the RGB-based tokens.
>
> - If, instead, Bob hears that Mallory knows the solution, he could sign
> a
> PSBT with the default SH_ALL to her, but then Mallory could take the
> BTC without solving the problem, again destroying the RGB-based
> tokens.
>
> - Or, in another case, Bob hears that Alice knows the solution, but he
> doesn't want to risk his tokens being destroyed, so he refuses to sign
> a transaction paying Alice until she provides him the answer. When
> Alice does provide him the answer, and he realizes it's so simple, he
> changes his mind about paying her and doesn't sign his transaction to
> her. She has no recourse.
>
> It seems to me, based on my understanding of Somsen's original insight,
> that client-side validation by itself cannot enforce conditions in a
> trustless multiparty setting.
>
> I think that implies that it's only possible to enforce conditions in a
> consensus system (or in a trust-dependent system), which would have
> significant implications for the future direction of your work, as you
> wrote in your email:
>
> > We're also working on the design of a layer 1 which will be perfect for
> > the
> > client-side-validated applications (“how to design a blockchain today
> > if we
> > knew about client-side-validation/single-use-seals”). This should be
> > very
> > compact (order of one signature per block) ultra-scalable
> > (theoretically
> > unlimited no of tx in a block) chain which can run systems like RGB -
> > with
> > Bitcoin UTXO set migrated into RGB [...]
>
> * * *
>
> Looking at other parts of your email:
>
> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations? While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation. Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.
>
> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review. For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN. In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\<test\>' | wc -l
> 7
> /tmp/lnp-node$ git grep -i '\<test\>' | wc -l
> 4
>
> ~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
> 2008
> ~/repos/cln$ git grep -i '\<test\>' | wc -l
> 1459
> ~/repos/lnd$ git grep -i '\<test\>' | wc -l
> 3547
> ~/repos/eclair$ git grep -i '\<test\>' | wc -l
> 2576
>
> I realize those are all projects by larger teams than that which works
> on RGB, but a difference of three orders of magnitude is very surprising
> to me. Do you have out-of-tree testing or am I missing something else?
> I did my best to earnestly search both your repository and your GitHub
> issues and PRs. All I found was that a small amount of previous unit
> testing was removed, and that several issues mentioning the need for
> testing were closed without referencing a resolution.
>
> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that. I focused on the ones
> discussing LNP, as LN is something I know fairly well, and I admit that
> I skimmed them quite fast, but I couldn't find any demos where you
> progressed beyond using LNP to open a channel with another node. E.g.,
> they seemed to stop at the same point as this demo:
>
> https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
>
> > Despite 4 years of active development, weekly community calls, talks on
> > all mainstream bitcoin-only evens and conferences, the awareness about
> > RGB
> > in the bitcoin community is still very small
>
> My understanding of the basic goal of RGB from years ago was that it
> would allow ordinary users to define new assets on Bitcoin in a way that
> would allow those assets to be transferred over LN. As far as I can
> tell, it doesn't do that yet, not even in a way that's accessible to a
> power user such as myself. Even for that original goal, there are
> several problems outstanding---problems which will likely require
> significant research and experimentation to overcome, e.g.[2].
>
> Instead of tackling those problems and building upon existing wallet and
> LN libraries, I see an ambitious effort at reimplementation and massive
> scope creep. The payoff for that effort could be a huge change that
> affects how we use Bitcoin and LN for decades to come. But it also
> seems possible that the ambition and scope creep may be preventing the
> project from currently serving many of the people who were most excited
> about it in the first place. Awareness may be limited because the
> near-term benefits for most people who invest time in learning about RGB
> also seems limited.
>
> Thanks again for writing about your research for this mailing list,
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003540.html
> [2]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003549.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20230416/b611f172/attachment-0001.html>

2023-06-07 18:16:55

- reply

📅 Original date posted:2019-03-07
📝 Original message:On Thu, 7 Mar 2019 at 11:13, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If Satoshi wanted the currency units named after him, he would simply
> have done it. I think this behaviour seems creepy and is harmful to
> Bitcoin.
>
I don't believe the will of Satoshi is particularly relevant on this
matter. Having a term everybody can converge on to express small amounts is
very important to improve the user experience, and satoshis seem to have
more chances to achieve this than scientific notations.
My main concern with satoshis as a unit is that it may sound weird/funny to
native Japanese speakers. It could probably be useful to have the opinion
of some of them on this topic.
Regarding the BIP to formalise the symbol for satoshi, I think that maybe
is better to wait for something to emerge with more widespread usage (e.g.
already used by some wallets or service providers). The linked proposal
does not seem to have sufficient support to be proposed as a standard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190307/8be1fb29/attachment-0001.html>

2023-06-07 18:13:51

- reply

📅 Original date posted:2018-07-24
📝 Original message:Hello everyone,
With my team we are working on a walleting application which ideally will
generate a bech32 address when receiving from a bech32 compatible wallet,
and a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.
However, it is of course impossible for the payee to know in advance the
technological capabilities of the payer, so a solution could be to encode
in a Bitcoin URI both bech32 and P2SH addresses in a way that legacy
wallets only see the P2SH address, while new wallets can also see the
bech32 address and use it to perform the transaction.
In particular, to keep compatibility with BIP21, the <address> field of the
URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.
<segwitaddress> or <bech32address>), which will be ignored by legacy
wallets, can be used to encode the bech32 address. The assumption here is
that the wallets using such scheme will monitor incoming transaction both
on the P2SH address and on the bech32 address.
I did some research around and I did not find any proposal addressing the
same issue, so my questions are (i) does anybody already proposed something
going in the same direction and (ii) do you see any major drawback in the
BIP21 compatible scheme proposed in this message?
Thanks in advance,
Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180724/28e07878/attachment.html>

2023-06-07 18:07:58

- reply

📅 Original date posted:2017-11-30
📝 Original message:The main issue that I see with this proposal is that miners can still spam
the network for free even with high sat/byte fee levels. They can first
choose the sat/byte rate that maximize their profit, and then include a lot
of spam transactions at that rate that will only pay fees to themselves,
effectively spamming the chain for free and increasing the cost of running
a node.
On 30 Nov 2017 03:40, "Ben Kloester via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Something similar to this has been proposed in this article by Ron Lavi,
Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/
015093.html
They only discussed changing the fee structure, not removing the block size
limit, as far as I know.
"Redesigning Bitcoin's fee market"
https://arxiv.org/abs/1709.08881
*Ben Kloester*
On 30 November 2017 at 11:47, William Morriss via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Comrades,
>
> Long term, tx fees must support hash power by themselves. The following is
> an economic approach to maximize total fee collection, and therefore
> hashpower.
>
> *Goals*
> Maximize total transaction fees
> Reduce pending transaction time
> Reduce individual transaction fees
>
> *Challenges*
> Validators must agree on the maximum block size, else miners can cheat and
> include extra transactions.
> Allowing too many transactions per block will increase the cost of the
> mining without collecting much income for the network.
>
>
> *Problem*
> In the transaction market, users are the demand curve, because they will
> transact less when fees are higher, and prefer altcoins. The block size is
> the supply curve, because it represents miners' willingness to accept
> transactions.
> Currently, the supply curve is inelastic:
>
> Increasing the block size will not affect the inelasticity for any fixed
> block size. The downsides of a fixed block size limit are well-known:
> - Unpredictable transaction settlement time
> - Variable transaction fees depending on network congestion
> - Frequent overpay
>
> *Proposal*
> 1. Miners implicitly choose the market sat/byte rate with the cheapest-fee
> transaction included in their block. Excess transaction fees are refunded
> to the inputs.
> 2. Remove the block size limit, which is no longer necessary.
>
> *Benefits*
> - Dynamic block size limit regulated by profit motive
> - Transaction fees maximized for every block
> - No overpay; all fees are fair
>
> Miners individually will make decisions to maximize their block-reward
> profit.
> Miners are incentivized to ignore low-fee transactions because they would
> shave the profits of their other transactions and increase their hash time.
> Users and services are free to bid higher transaction fees in order to
> reach the next block, since their excess bid will be refunded.
>
> The block size limit was added as a spam-prevention measure, but in order
> for an attacker to spam the network with low-fee transactions, they would
> have to offset the marginal cost of reducing the price with their own
> transaction fees. Anti-spam is thus built into the marginal system without
> the need for an explicit limit.
>
> Rarely, sections of the backlog would become large enough to be
> profitable. This means every so many blocks, lower-fee transactions would
> be included en masse after having been ignored long enough. Low-fee
> transactions thus gain a liveness property not previously enjoyed: low-fee
> transactions will eventually confirm. Miners targeting these transactions
> would be at a noteworthy disadvantage because they would be hashing a
> larger block. I predict that this scheme would result in two markets: a
> backlog market and a real-time market. Users targeting the backlog market
> would match the price of the largest backlog section in order to be
> included in the next backlog block.
>
> *Examples*
>
> Scenario 1
> Sat/byte Bytes Reward
> 400 500000 200000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1500000 150000000
> 50 5000000 250000000
> 20 10000000 200000000
> A miner would create a 5MB block and receive 0.25 BTC
>
> Scenario 2
> Sat/byte Bytes Reward
> 400 600000 240000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1800000 180000000
> 50 4000000 200000000
> 20 10000000 200000000
> A miner would create a 600KB block and receive 0.24 BTC
>
> Thanks,
> William Morriss
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at 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/20171130/f185452e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/f185452e/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/f185452e/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marginal.png
Type: image/png
Size: 21403 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/f185452e/attachment-0005.png>

2023-06-07 18:04:26

- reply

📅 Original date posted:2017-07-13
📝 Original message:On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Can you explain why you wish to do this? It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.
>
I believe that a good reason not to wish your node to be segwit compliant
is to avoid having to deal with the extra bandwidth that segwit could
require. Running a 0.14.2 node means being ok with >1MB blocks, in case
segwit is activated and widely used. Users not interested in segwit
transactions may prefer to keep the cost of their node lower.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/df014a46/attachment.html>

2023-06-07 18:04:09

- reply

📅 Original date posted:2017-07-27
📝 Original message:Hi ZmnSCPxj,
Few thoughts about your proposal:
1- I kinda like the idea and I would probably use it, but still I believe
it is a very limited use case and probably most wallet providers will not
be interested in supporting it.
2- Early adopters and people highly involved in the community may
appreciate the "hodl" part in the redemption code, but it could cause
confusion in normal users not understanding the reference.
Regarding the time-zone I think the best option is to stick the UTC
standard, using UTC+14 could be confusing since it is very unusual and we
are not used to deal with it.
On 12 July 2017 at 10:30, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning mailinglist,
>
> I am saddened at the lack of attention to this BIP proposal. I know that
> it is not as interesting as the debates on where Bitcoin will go in the
> future and what needs to be prepared for even greater mainstream adoption,
> but I think my BIP proposal does have at least some value to long-term
> investors.
>
> So far I have seen only a single public feedback:
>
> https://www.reddit.com/r/Bitcoin/comments/6lzpvz/bip_hodl/djxzbvi/
>
> Basically, the point in that feedback is mostly that the computed timelock
> should be UTC+0 0000h of the given human-readable date.
>
> I would like to respectfully ask the mailing list about which option is
> best:
>
> 1. (current) Use the earliest timezone as of now, UTC+14 0000h of the
> given human-readable date. Pro: No matter where you are in the world, as
> soon as the given date arrives, the fund can be spent. Con: For most of
> the world, the fund can be spent on some time the day before, or even two
> days before for UTC-11 and UTC-12 timezones.
>
> 2. Use the standard timezone UTC+0 0000h of the given human-readable
> date. Pro: standard time. Con: for half of the world, the fund is not
> spendable until some time into the given date, for the other half, it will
> be spendable at an earlier date.
>
> 3. Allow indicating a timezone to the human-readable part. Pro: gives
> control over the user's expected local time. Con: additional field and
> effectively more control, need to handle also strange timezones that have
> 0.5 hour difference from UTC, need to encode positive and negative
> preferably without using + and -, as those may break double-click selection.
>
> I hope to get some feedback from this list.
>
> Regards,
> ZmnSCPxj
>
> -------- Original Message --------
> Subject: [bitcoin-dev] [BIP Proposal] Standard address format for
> timelocked funds
> Local Time: July 8, 2017 9:13 AM
> UTC Time: July 8, 2017 1:13 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>
>
> <pre>
> BIP: ?
> Title: Standard address format for timelocked funds
> Author: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Comments-Summary: ?
> Comments-URI: ?
> Status: ?
> Type: ?
> Created: 2017-07-01
> License: CC0-1.0
> </pre>
>
> == Abstract ==
>
> <code>OP_CHECKLOCKTIMEVERIFY</code> provides a method of
> locking funds until a particular time arrives.
> One potential use of this opcode is for a user to precommit
> himself or herself to not spend funds until a particular
> date, i.e. to hold the funds until a later date.
>
> This proposal adds a format for specifying addresses that
> precommit to timelocked funds, as well as specifying a
> redemption code to redeem funds after the timelock has
> passed.
> This allows ordinary non-technical users to make use of
> <code>OP_CHECKLOCKTIMEVERIFY</code> easily.
>
> == Copyright ==
>
> This BIP is released under CC0-1.0.
>
> == Specification ==
>
> This proposal provides formats for specifying an
> address that locks funds until a specified date,
> and a redemption code that allows the funds to be
> swept on or after the specified date.
>
> At minimum, wallet software supporting this BIP must
> be capable of sweeping the redemption code on or after
> the specified date.
> In addition, the wallet software should support sending
> funds to the timelocked address specified here.
> Finally, wallet software may provide a command to create
> a pair of timelocked address and redemption code.
>
> Addresses and redemption codes are encoded using
> [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
> Bech32 encoding].
>
> === Timelocked Address Format ===
>
> The human-readable part of the address is composed of:
>
> # The four characters <code>hodl</code>.
> # A date, in <code>YYYYMMDD</code> form. For example,
> the date August 1, 2017 is encoded as <code>20170801</code>.
> # A network code, either <code>tb</code> for testnet,
> or <code>bc</code> for Bitcoin mainnet.
>
> The data part of the address is composed of:
>
> # A version quintet (5 bits), which must be 0 for this
> BIP.
> # A public key hash, 32 quintets (160 bits). As is
> usual for Bitcoin, this is big-endian.
>
> This is to be interpreted as follows:
>
> # The given date is the first day that the funds in
> the given address may be redeemed.
> # The funds are owned by whoever controls the private
> key corresponding to the public key hash given.
>
> === Redemption Code ===
>
> The human-readable part of the redemption code is
> composed of:
>
> # The four characters <code>hedl</code>.
> # A date, in <code>YYYYMMDD</code> form.
> # A network code, either <code>tb</code> for testnet,
> or <code>bc</code> for Bitcoin mainnet.
>
> The data part of the address is composed of:
>
> # A version quintet (5 bits), which must be 0 for this
> BIP.
> # A private key, 52 quintets (260 bits). This is the
> 256-bit private key, prepended with 4 <code>0</code>
> bits, in big-endian order. 
>
> This is to be interpreted as follows:
>
> # The given date is the first day that the funds in
> the given address may be redeemed.
> # The private key unlocks the funds.
>
> === Lock Time Computation ===
>
> Given a particular lock date <code>YYYYMMDD</code>, the
> actual lock time is computed as follows:
>
> # The day before the lock date is taken. For example,
> if the lock date is <code>20180101</code> or
> January 1, 2018, we take the date December 31, 2017.
> # We take the time 1000h (10:00 AM, or 10 in the morning)
> of the date from the above step.
>
> This lock time is then translated to a
> Unix epoch time, as per POSIX.1-2001 (which removes the
> buggy day February 29, 2100 in previous POSIX revisions).
> The translation should use, at minimum, unsigned 32-bit
> numbers to represent the Unix epoch time.
>
> The Unix epoch time shall then be interpreted as an
> <code>nLockTime</code> value, as per standard Bitcoin.
> Whether it is possible to represent dates past 2038
> will depend on whether standard Bitcoin can represent
> <code>nLockTime</code> values to represent dates past
> 2038.
> Since <code>nLockTime</code> is an unsigned 32-bit
> value, it should be possible to represent dates until
> 06:28:15 UTC+0 2106-02-07.
> Future versions of Bitcoin should be able to support
> <code>nLockTime</code> larger than unsigned 32-bit,
> in order to allow even later dates.
>
> The reason for using an earlier lock time than the
> specified date is given in the Rationale section of
> this BIP.
>
> === Payment to a Timelocked Address ===
>
> An ordinary P2SH payment is used to provide funds to a
> timelocked address.
>
> The script below is used as the <code>redeemScript</code>
> for the P2SH payment:
>
> <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
> OP_DUP OP_HASH160 <publickeyhash> OP_EQUALVERIFY OP_CHECKSIG
>
> Once the <code>redeemScript</code> is derived, the hash is
> determined, and an ordinary P2SH output with the below
> <code>scriptPubKey</code> used:
>
> OP_HASH160 <redeemScripthash> OP_EQUAL
>
> In case of SegWit deployment, SegWit-compatible wallets
> should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
> the output they would normally use in that situation.
>
> Obviously, a timelocked address has an equivalent
> Bitcoin <code>3</code> (P2SH) address.
> A simple service or software that translates from a
> public timelocked address to a P2SH address can be
> created that makes timelocking (but not redemption)
> backwards compatible with wallets that do not support
> this BIP.
>
> This proposal recommends that wallets supporting payment
> to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
> reuse the same interface for paying to such addresses as
> paying into timelocked addresses of this proposal.
>
> === Redemption of a Timelocked Redemption Code ===
>
> To sweep a timelocked redemption code after the timelock,
> one must provide the given <code>redeemScript</code> as
> part of the <code>scriptSig</code>, of all unspent
> outputs that pay to the given <code>redeemScript</code>
> hash.
>
> When sweeping a timelocked redemption code, first the
> wallet must extract the private key from the redemption
> code, then derive the public key, the public key hash,
> the <code>redeemScript</code>, and finally the
> <code>redeemScript</code> hash.
>
> Then, the wallet must find all unspent outputs that pay
> to the <code>redeemScript</code> hash via P2SH (and, in the
> case of SegWit deployment, via P2SH-P2WSH and P2WSH).
>
> For each such output, the wallet then generates a
> transaction input with the below <code>scriptSig</code>, as
> per usual P2SH redemptions:
>
> <signature> <pubkey> <redeemScript>
>
> The wallet then outputs to an address it can control.
>
> As the Script involved uses <code>OP_CHECKLOCKTIMEVERIFY</code>,
> the <code>nSequence</code> must be 0 and the
> <code>nLockTime</code> must be equal to the computed
> lock time.
> This implies that the transaction cannot be transmitted
> (and the funds cannot be sweeped)
> until after the given lock time.
>
> The above procedure is roughly identical to sweeping an
> ordinary, exported private key.
>
> This proposal recommends that wallets supporting a sweep
> function should reuse the same interface for sweeping
> individual private keys (wallet import format) for sweeping
> timelocked redemption codes.
>
> == Motivation ==
>
> A key motivation for this BIP is to allow easy use of
> <code>OP_CHECKLOCKTIMEVERIFY</code> by end-users.
>
> The below are expected use cases of this proposal:
>
> # A user wants to purchase an amount of Bitcoin,
> and subsequently wait for an amount of time before
> cashing out.
> The user fears that he or she may have "weak hands",
> i.e. sell unfavorably on a temporary dip, and thus
> commits the coins into a timelocked fund that can
> only be opened after a specific date.
> # A user wants to gift an amount of Bitcoins to
> an infant or minor, and wants the fund to not be spent
> on ill-advised purchases until the infant or minor
> reaches the age of maturity.
> # A user may wish to prepare some kind of monthly subsidy
> or allowance to another user, and prepares a series of
> timelocked addresses, redeemable at some set date on
> each month, and provides the private redemption codes to
> the beneficiary.
> # A user may fear duress or ransom for a particular
> future time horizon, and voluntarily impose a lock time
> during which a majority of their funds cannot be spent.
>
> == Rationale ==
>
> While in principle, this proposal may be implemented as a
> separate service or software, we should consider the long
> time horizons that may be desired by users.
> A user using a particular software to timelock a fund may
> have concerns, for example, of specifying a timelock
> 18 years in the future for a gift or inheritance to a
> newborn infant.
> The software or service may no longer exist after 18 years,
> unless the user himself or herself takes over maintenance
> of that software or service.
> By having a single standard for timelocked funds that is
> shared and common among multiple implementations of Bitcoin
> wallets, the user has some assurance that the redemption code
> for the funds is still useable after 18 years.
> Further, a publicly-accessible standard specifying how the
> funds can be redeemed will allow technically-capable users
> or beneficiaries to create software that can redeem the
> timelocked fund.
>
> This proposal provides a timelock at the granularity of a
> day.
> The expectation is that users will have long time
> durations of months or years, so that the ability to
> specify exact times, which would require specifying the
> timezone, is unneeded.
>
> The actual timeout used is 1000h of the day before the
> human-readable date, so that timezones of UTC+14 will
> definitely be able to redeem the money starting at
> 0000h of the human-readable date, local time (UTC+14).
> Given the expectation that users will use long time
> durations, the fact that timezones of UTC-12 will
> actually be able to redeem the funds on 2200h UTC-12
> time two days before can be considered an acceptable
> error.
>
> The human-readable date is formatted according to
> [https://www.iso.org/iso-8601-date-and-time-format.html
> ISO standard dates], with the dashes removed.
> Dashes may prevent double-click selection, making
> usability of these addresses less desirable.
> 
>
> The <code>bc</code> or <code>tb</code> is after the
> date since the date is composed of digits and the bech32
> separator itself is the digit <code>1</code>. One
> simply needs to compare <code>hedlbc202111211...</code>
> and <code>hedl20211121bc1...</code>.
>
> A version quintet is added in case of a future
> sociopolitical event that changes interpretation of
> dates, or changes in scripting that would allow for more
> efficient redemptions of timelocked funds (which would
> change the <code>redeemScript</code> paid to), or changes
> in the size and/or format of lock times, and so on.
> Such changes are unlikely, so the version is a quintet in
> the bech32 data part rather than a substring in the
> human-readable part.
>
> The public address format uses the <code>hodl</code> as
> the start of the code, while the private key (the
> redemption code) uses <code>hedl</code>.
> This provides a simple mnemonic for users:
> "Pay into the <code>hodl</code> code to hold your
> coins until the given date.
> After you've held the coins (on or after the given date)
> use the <code>hedl</code> code to redeem the coins."
> The obvious misspelling of "hodl" is a homage to the common
> meme within the Bitcoin community.
> 
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at 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/20170727/45b458bf/attachment-0001.html>