Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Ricardo Filipe via bitcoin-dev]

I believe Zman meant issuer.

raymo via bitcoin-dev  escreveu
no dia segunda, 28/06/2021 à(s) 18:45:
>
> Hi Greg,
> You are right, the whole scenario is:
> there is an issuer which own a UTXO
> issuers get fiat money or goods or services from creditor in exchange of
> a transaction.
> the transactions are intended to circulate in Sabu protocol instead of
> sending to Bitcoin network.
> creditor can not sign the transaction at all. instead he can ask issuer
> to change the balances (transaction outputs) and transfer some of his
> money to other creditor...
> here is complete paper to read it carefully:
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
> Cheers
> Raymo
>
>
> On 2021-06-28 17:29, Tao Effect wrote:
> > Hi ZmnSCPxj & Raymo,
> >
> >> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev
> >>  wrote:
> >>
> >> Good morning Raymo,
> >>
> >>> Hi ZmnSCPxj,
> >>
> >>> […]
> >> What prevents the creditor from signing a transaction that is
> >> neither a valid MT nor a GT?
> >>
> >> Nothing.
> >
> > How would the creditor create such a transaction? They need the
> > issuer’s private key, so they can’t create it? Am I
> > misunderstanding the scenario you’re describing? If so could you
> > give a more detailed description?
> >
> > Cheers,
> > Greg
> ___
> 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 Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Ricardo Filipe via bitcoin-dev]

As said before, you are free to create the BIP in your own repository
and bring it to discussion on the mailing list. then you can do a PR

Lonero Foundation via bitcoin-dev
 escreveu no dia sábado,
6/03/2021 à(s) 08:58:
>
> I know Ethereum had an outlandishly large percentage of nodes running on AWS, 
> I heard the same thing is for Bitcoin but for mining. Had trouble finding the 
> article online so take it with a grain of salt. The point though is that both 
> servers and ASIC specific hardware would still be able to benefit from the 
> cryptography upgrade I am proposing, as this was in relation to the 
> disinfranchisemet point.
>
> That said, I think the best way to move forward is to submit a BIP pull 
> request for a draft via GitHub using BIP #2's draft format and any questions 
> people have can be answered in the reqeust's comments. That way people don't 
> have to get emails everytime there is a reply, but replies still get seen as 
> opposed to offline discussion. Since the instructions say to email 
> bitcoin-dev before doing a bip draft, I have done that. Since people want to 
> see the draft beforehand and it isn't merged manually anyways, I think it is 
> the easiest way to handle this.
>
> I'm also okay w/ continuing the discussion on bitcoin-dev but rather form a 
> discussion on git instead given I don't want to accidentally impolitely 
> bother people given this is a moderated list and we already established some 
> interest for at least a draft.
>
> Does that seem fine?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland  
> wrote:
>>
>> > A large portion of BTC is already mined through AWS servers and non-asic 
>> > specific hardware anyways. A majority of them would benefit from a hybrid 
>> > proof, and the fact that it is hybrid in that manner wouldn't 
>> > disenfranchise currently optimized mining entities as well.
>>
>> My instincts tell me that this is an outlandish claim. Do you have 
>> supporting evidence for this?
>>
>> Keagan
>>
>> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev 
>>  wrote:
>>>
>>> Actually I mentioned a proof of space and time hybrid which is much 
>>> different than staking. Sorry to draw for the confusion as PoC is more 
>>> commonly used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Work as 
>>> it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of being 
>>> both CPU compatible and memory-hard compatible. There are lots of benefits 
>>> outside of the realm of efficiency, and I already looked into numerous 
>>> fault tolerant designs as well and what others in the cryptography 
>>> community attempted to propose. The actual argument you have only against 
>>> this is the Proof of Memory fallacy, which is only partially true. Given 
>>> how the current hashing algorithm works, hard memory allocation wouldn't be 
>>> of much benefit given it is more optimized for CPU/ASIC specific mining. 
>>> I'm working towards a hybrid mechanism that fixes that. BTW: The way 
>>> Bitcoin currently stands in its cryptography still needs updating 
>>> regardless. If someone figures out NP hardness or the halting problem the 
>>> traditional rule of millions of years to break all of Bitcoin's 
>>> cryptography now comes down to minutes. Bitcoin is going to have to 
>>> eventually radically upgrade their cryptography and hashing algo in the 
>>> future regardless. I want to integrate some form of NP complexity in 
>>> regards to the hybrid cryptography I'm aiming to provide which includes a 
>>> polynomial time algorithm in the cryptography. More than likely the first 
>>> version of my BTC hard fork will be coded in a way where integrating such 
>>> complexity in the future only requires a soft fork or minor upgrade to its 
>>> chain.
>>>
>>> In regards to the argument, "As a separate issue, proposing a hard fork in 
>>> the hashing algorithm will invalidate the enormous amount of capital 
>>> expenditure by mining entities and disincentivize future capital 
>>> expenditure into mining hardware that may compute these more "useful" 
>>> proofs of work."
>>>
>>> A large portion of BTC is already mined through AWS servers and non-asic 
>>> specific hardware anyways. A majority of them would benefit from a hybrid 
>>> proof, and the fact that it is hybrid in that manner wouldn't 
>>> disenfranchise currently optimized mining entities as well.
>>>
>>> There are other reasons why a cryptography upgrade like this is beneficial. 
>>> Theoretically one can argue BItcoin isn't fully decentralized. It is few 
>>> unsolved mathematical proofs away from being entirely broken. My goal 
>>> outside of efficiency is to build cryptography in a way that prevents such 
>>> an event from happening in the future, if it was to ever happen. I have 
>>> various research in regards to this area and work alot with distributed 
>>> 

Re: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?

[Ricardo Filipe via bitcoin-dev]

I believe you are looking for HD wallets.

Nathan Worsley via bitcoin-dev 
escreveu no dia terça, 2/04/2019 à(s) 18:06:
>
> To whom it may concern,
>
> I believe a missing feature in Bitcoin is the ability to have an "integrated 
> address", where the address resolves into a Bitcoin address, and also a 
> transaction message or some other kind of identifier.
>
> By having this feature we could enhance the security of exchange cold-wallet 
> systems, by allowing them to easily receive all payments to a single address 
> from an infinite number of customers. We would also greatly simplify the 
> process of setting up and managing exchange cold-wallet systems, because we 
> would eliminate the "sweeping" step required to move multiple customer 
> deposits from a hot address into a single cold address.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

[Ricardo Filipe via bitcoin-dev]

one year seems too long. i think with the BIP-148 experience you have
we could easily get there in 6 months at most.

Luke Dashjr via bitcoin-dev 
escreveu no dia segunda, 1/04/2019 à(s) 01:33:
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
>   https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
>   https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> Luke
>
>
> 
>   BIP: ?
>   Layer: Applications
>   Title: Signed USD Price Indicator
>   Author: Luke Dashjr 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: Standards Track
>   Created: 2019-04-01
>   License: BSD-2-Clause
> 
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to the
> price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing, weight
> calculation, and so on, the output count must be incremented by one. Prior to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero, and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> 
>   BIP: ?
>   Layer: Consensus (soft fork)
>   Title: $50k USD/BTC Minimum Price
>   Author: Luke Dashjr 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: Standards Track
>   Created: 2019-04-01
>   License: BSD-2-Clause
>   Requires: usdprice
> 
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions. Using
> this, 

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

[Ricardo Filipe via bitcoin-dev]

You can do it on 2nd layer solutions such as the lightning network,
with their own format.
On the base layer you cannot do it without a hard fork, or it would
undermine the invariants of bitcoin.

2017-12-12 8:24 GMT+00:00 Teweldemedhin Aberra :
> How?
>
>
>
> From: Ricardo Filipe
> Sent: Tuesday, December 12, 2017 4:44 AM
> To: Teweldemedhin Aberra; Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] BIP - Dead Man's Switch
>
>
>
> yes
>
>
>
> 2017-12-12 1:10 GMT+00:00 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/
>
>>> >
>
>>> >
>
>>> >
>
>>> >
>>> > 
>>> > 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
>
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Ricardo Filipe via bitcoin-dev]

start double checking the last few bytes instead?

2017-10-30 8:56 GMT+00:00 shiva sitamraju via bitcoin-dev
:
> Hi,
>
> When I copy and paste bitcoin address, I double check the first few bytes,
> to make sure I copied the correct one. This is to make sure some rogue
> software is not changing the address, or I incorrectly pasted the wrong
> address.
>
>
> With Bech32 address, its seems like in this department we are taking as step
> in the backward direction. With the traditional address, I could compare
> first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see and
> compare which is likely to be same anyway. Note that most users will only
> compare the first few bytes only (since addresses themselves are very long
> and will overflow in a mobile text box).
>
> Is there anyway to make the Bech32 addresses format more visually distinct
> (atleast the first few bytes) ?
>
> ___
> 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] A roadmap to a better header format and bigger block size

[Ricardo Filipe via bitcoin-dev]

I believe i've seen Luke say this several times before, but there are
several more things that the majority of the devs agree should be in
bitcoin.
I would suggest to compile that list for your stage 3, so that you can have
an hardfork that fixes most of those things, and there should be some
repository with those changes deployed.

2016-02-09 14:16 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> I would like to present a 2-3 year roadmap to a better header format and
> bigger block size
>
> Objectives:
>
> 1. Multistage rule changes to make sure everyone will have enough time to
> upgrade
> 2. Make mining easier, without breaking existing mining hardware and the
> Stratum protocol
> 3. Make future hardfork less disruptive (with Luke-Jr's proposal)
>
> Stage 1 is Segregated Witness (BIP141), which will not break any existing
> full or light nodes. This may happen in Q2-Q3 2016
>
> Stage 2 is fixes that will break existing full nodes, but not light nodes:
> a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
> roadmap), potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. (optional) Move segwit's commitments to the header Merkle tree. This is
> optional at this stage as it will be fixed in Stage 3 anyway
> This may happen in Q1-Q2 2017
>
> Stage 3 is fixes that will break all existing full nodes and light nodes:
> a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
> rules and activation logic should be included already
> b. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure. All existing mining hardware with
> Stratum protocol should work.
> c. Reclaiming unused bits in header for mining. All existing mining chips
> should still work. Newly designed chips should be ready for the new rule.
> d. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. Light nodes (usually less tech-savvy users) will have longer time to
> upgrade
> b. The stage 2 is opt-in for full nodes.
> c. The stage 3 is opt-in for light nodes.
>
> Cons:
> a. The stage 2 is not opt-in for light nodes. They will blindly follow the
> longest chain which they might actually don't want to
> b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
> likely to have lower value.
> c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
> likely to have lower value. (However, this is not a concern as no one
> should
> be mining on the old chain at that time)
>
> ---
> An alternative roadmap would be:
>
> Stage 2 is fixes that will break existing full nodes and light nodes.
> However, they will not follow the minority chain
> a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure.
> This may happen in mid 2017 or later
>
> Stage 3 is fixes that will break all existing full nodes and light nodes.
> a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
> again, as the rules and activation logic should be included already
> b. Reclaiming unused bits in header for mining. All existing mining chips
> should still work.
> c. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. The stage 2 and 3 are opt-in for everyone
> b. Even failing to upgrade, full nodes and light nodes won't follow the
> minority chain at stage 2
>
> Cons:
> a. Non-upgraded full/light nodes will follow the old chain at Stage 3,
> which
> is likely to have lower value. (However, this is not a concern as no one
> should be mining on the old chain at that time)
> b. It takes longer to implement stage 2 to give enough time for light node
> users to upgrade
>
> ---
>
> In terms of safety, the second proposal is better. In terms of disruption,
> the first proposal is less disruptive
>
> I would also like to emphasize that it is miners' responsibility, not the
> devs', to confirm that the supermajority of the community accept changes in
> Stage 2 and 3.
>
> Reference:
> Matt Corallo's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
> html
> Luke-Jr's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
> html
>
>
>
>
>
> ___
> 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] Forget dormant UTXOs without confiscating bitcoin

[Ricardo Filipe via bitcoin-dev]

I really like ideas that tackle this issue. The question imho is what is
the incentive to run a "Full UTXO node" instead of a pruned or archive node.
For starters, it would be nice to know what would be the savings for Full
UTXO nodes over archive nodes right now.
Also, what advantages would this have over "archive pruned nodes: nodes
that store X blocks of the whole blockchain before 42". Seems like an
interesting intermediate use case to me too.

2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe 
> wrote:
>
>> What is the current behavior / cost that this proposal is trying to
>> avoid? Are ancient utxos required to be kept in memory always in a fully
>> validating node, or can ancient utxos get pushed out of memory like a
>> normal LRU caching db?
>>
>
> I don't see why it must be kept in memory. But storage is still a problem.
> With the 8 year limit and a fixed max block size, it indirectly sets an
> upper limit for UTXO set.
>
>
> Chris Priest via bitcoin-dev :
>
>> This isn't going to kill bitcoin, but it won't make it any better.
>>
>
> Do you believe that thousands of volunteer full nodes are obliged to store
> an UTXO record, just because one paid US$0.01 to an anonymous miner 100
> years ago? It sounds insanely cheap, isn't it? My proposal (or similar
> proposal by Peter Todd) is to solve this problem. Many commercial banks
> have a dormant threshold less than 8 years so I believe it is a balanced
> choice.
>
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 42 blocks
>
> Currently, if one holds nothing but a private key, he must consult either
> an archive node or a full UTXO node for the latest UTXO state to spend his
> coin. We currently do not have any lite UTXO node, and such node would not
> work properly beyond block 42.
>
> With the softfork I described in my original post, if the UTXO is created
> within the last 42 blocks, the key holder may consult any type of full
> node, including a lite UTXO node, to create the transaction.
>
> If the UTXO has been confirmed by more than 42 blocks, a lite UTXO
> node obviously can't provide the necessary information to spend the coin.
> However, not even a full UTXO node may do so. A full UTXO node could tell
> the position of the UTXO in the blockchain, but can't provide all the
> information required by my specification. Only an archive node may do so.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 42).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 42).
>
> It is not possible to construct the membership prove I require without
> these information. It is designed this way, so that lite UTXO nodes won't
> need to store any dormant UTXO records: not even the hash of individual
> dormant UTXO records. If the blockchain grows to insanely big, it may take
> days or weeks to retrieve to records. However, I don't think this is
> relevant as one has already left his coins dormant for >8 years. Actually,
> you don't even need the full blockchain. For (1), all you need is the
> 42 blocks from Y to Y+42 minus any witness data, as you don't need
> to do any validation. For (2), you just need the coinbase of Y+420001 to
> present, where any spending would have been committed, and retrieve the
> full block only if a spending is found.
>
> So the Bitcoin Bank (miners) is not going to shred your record and
> confiscate your money. Instead, the Bank throws your record to the garage
> (raw blockchain). You can search for your record by yourself, or employ
> someone (archive node) to search it for you. In any case it incurs costs.
> But as thousands of bankers have kept your record on their limited desk
> space for 8 years for free (though one of them might receive a fraction of
> a penny from you), you shouldn't complain with any moral, technical, or
> legal reason. And no matter what users say, I believe something like this
> will happen when miners and full nodes can't handle the UTXO set.
>
> I'd like to see more efficient proposals that archive the same goals.
>
> p.s. there were some typos in my original. The second sentence of the
> second paragraph should be read as "For every block X+42, it will
> commit to a hash for all UTXOs generated in block X."
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
>