<unnamed>

Public Key

npub18df3zgqr9zt5ah42zpd34rmq6fp7v57vvwmtk20krhrfdczp38ks5xccej

Profile Code

nprofile1qqsrk5c3yqpj396wm64pqkc63asdyslx20xx8d4m98mpm35kupqcnmgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqu65ra7

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:06:20 CEST

- reply

📅 Original date posted:2017-09-27
📝 Original message:A better solution is to just have the sending wallet check to see if the
address you are about to send to has been used before. If it's a fresh
address, it sends it through without any popup alert. If the address has
history going back a certain amount of time, then a popup comes up and
notifies the sender that they are sending to a non-fresh address that may
no longer be controlled by the receiver anymore.
Also, an even better idea is to set up an "address expiration service".
When you delete a wallet, you first send off an "expiration notice" which
is just a message (signed with the private key) saying "I am about to
delete this address, here is my new address". When someone tries to send to
that address, they first consult the address expiration service, and the
service will either tell them "this address is not expired, proceed", or
"this address has been expired, please send to this other address
instead...". Basically like a 301 redirect, but for addresses. I don't
think address expiration should be part of the protocol.
On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen;
> there
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing
> deposits.
> This also makes it difficult operationally to rotate private keys. I
> personally
> have even lost funds in the past due to people sending me BTC to addresses
> that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
>
> To help combat this problem, I suggest that we add a UI-level expiration
> time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time
> is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and
> terminology
> questions. Notably, the entire notion of addresses is flawed from a user
> point
> of view: their experience with them should be more like "payment codes",
> with a
> code being valid for payment for a short period of time; wallets should
> not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds
> themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> Both options have the advantage of working well at the UI level regardless
> of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the advantage of
> making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using
> at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Chris Priest
786-531-5938
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/e853137e/attachment.html>

2023-06-07 19:56:30 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On 2/22/17, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Reposting something that came up recently in a private discussion with some
> academics:
>
> Concretely, let's define a prunable MMR with the following grammar. This
> definition is an improvement on whats in the python-proofmarshal by
> committing
> to the number of items in the tree implicitly; an obvious max-log2(n)-sized
> proof-of-tree-size can be obtained by following the right-most nodes:
>
> Maybe(T) := UNPRUNED <T> | PRUNED <Commitment(T)>
>
> FullNode(0) := <Value>
> FullNode(n) := <Maybe(FullNode(n-1)> <Maybe(FullNode(n-1))>
>
> PartialNode(0) := SOME <FullNode(0)> | NONE
> PartialNode(n) := <Maybe(FullNode(n-1))> <Maybe(PartialNode(n-1))>
>
> MMR := FULL <N> <FullNode(n)> | PARTIAL <N> <PartialNode(n)>
>
> Basically we define it in four parts. First we define Maybe(T) to represent
> pruned and unpruned (hash only) data. Secondly we define full nodes within
> 2^n
> sized trees. Third we define partial nodes. And finally we define the MMR
> itself as being either a full or partial node.
>
> First of all, with pruning we can define a rule that if any operation
> (other
> than checking commitment hashes) attempts to access pruned data, it should
> immediately fail. In particular, no operation should be able to determine
> if
> data is or isn't pruned. Equally, note how an implementation can keep track
> of
> what data was accessed during any given operation, and prune the rest,
> which
> means a proof is just the parts of the data structure accessed during one
> or
> more operations.
>
> With that, notice how proving the soundness of the proofs becomes trivial:
> if
> validation is deterministic, it is obviously impossible to construct two
> different proofs that prove contradictory statements, because a proof is
> simply
> part of the data structure itself. Contradiction would imply that the two
> proofs are different, but that's easily rejected by simply checking the hash
> of
> the data.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
What problem does this try to solve, and what does it have to do with bitcoin?

2023-06-07 19:55:10 CEST

- reply

📅 Original date posted:2017-01-06
📝 Original message:Its a method for determining the probability that a valid tx will be
mined in a block before that tx actually gets mined, which is useful
when accepting payments in situations when you can't wait for the full
confirmation. No one is saying all tx validation should be performed
by querying miners mempools, that's ridiculous. Obviously once the tx
gets it's first confirmation, you go back to determining validity the
way you always have. There is no "security catastrophe".
Even if you're running a full node, you can't know for certain that
any given tx will make it into a future block. You can't be certain
the future miner who finally does mine that tx will mine your TXID or
another TXID that spends the same inputs to another address (a double
spend). The only way to actually know for certain is to query every
single large hashpower mempool.
On 1/4/17, Eric Voskuil <eric at voskuil.org> wrote:
> On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
>> On 1/3/17, Jonas Schnelli via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> There are plenty, more sane options. If you can't run your own full-node
>>> as a merchant (trivial), maybe co-use a wallet-service with centralized
>>> verification (maybe use two of them), I guess Copay would be one of
>>> those wallets (as an example). Use them in watch-only mode.
>>
>> The best way is to connect to the mempool of each miner and check to
>> see if they have your txid in their mempool.
>>
>> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
>> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
>> https://bw.com/api/is_in_mempool?txid=334847bb...
>> https://bitfury.com/api/is_in_mempool?txid=334847bb...
>> https://btcc.com/api/is_in_mempool?txid=334847bb...
>>
>> If each of these services return "True", and you know those services
>> so not engage in RBF, then you can assume with great confidence that
>> your transaction will be in the next block, or in a block very soon.
>> If any one of those services return "False", then you must assume that
>> it is possible that there is a double spend floating around, and that
>> you should wait to see if that tx gets confirmed. The problem is that
>> not every pool runs such a service to check the contents of their
>> mempool...
>>
>> This is an example of mining centralization increasing the security of
>> zero confirm.
>
> A world connected up to a few web services to determine payment validity
> is an example of a bitcoin security catastrophe.
>
> e
>
>

2023-06-07 19:48:43 CEST

- reply

📅 Original date posted:2016-02-06
📝 Original message:Its mostly a problem for exchanges and miners. Those entities need to
be on the network 100% of the time because they are using the network
100% of the time. A normal wallet user isn't taking payments every few
minutes like the exchanges are. "Getting booted off the network" is
not something to worry about for normal wallet users.
If miners aren't up to date, that is the biggest problem. A sudden
drop in hashpower will effect the network for all users, including
normal wallet users (by them having to wait longer for confirmations).
Miners must not be booted off the network ever. Hashpower voting is
the best way to make sure this never happens.
On 2/6/16, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
> wrote:
>> None of the reasons you list say anything about the fact that "being
>> lost"
>> (kicked out of the network) is a problem for those node's users.
>
> That's because its not.
>
> If you have a node that is "old" your node will stop getting new blocks.
> The node will essentially just say "x-hours behind" with "x" getting larger
>
> every hour. Funds don't get confirmed. etc.
>
> After upgrading the software they will see the new reality of the network.
>
> Nobody said its a problem, because its not.
>
> --
> Tom Zander
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:48:41 CEST

- reply

📅 Original date posted:2016-02-07
📝 Original message:Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure. Most wallets these days are Block agnostic.
Essentially, if a client has been built using a library that abstracts
away the block, then that client's *code* does not need to be updated
to handle this blocksize limit change. An example is any service using
the Bitcore javascript library. Any wallet built using Bitcore does
not need any changes to handle a blocksize upgrade. I have one project
that is live that was built using Bitcore. Before, during, and after
the fork, I do not need to lift a finger *codewise* to keep my project
still working. Same goes for projects that are built using
pybitcointools, as well as probably a few other libraries.
A wallet using Bitcore also has to work in tandem with a blockchan
api. Bitcore itself does not provide any blockchain data, you have to
get that somewhere else, such as a Node API. That API has to be based
on a Node that is following the upgraded chain. My wallet for instance
is built on top of Bitpay Insight. If bitpay doesn't upgrade their
Node to follow the 2MB chain, then I must either...
1) Change my wallet to use my own Bitpay Insight. (Insight is open
source, so you can host you own using any Node client you want)
2) Switch to another API, such as Toshi or Bockr.io, or
Blokchain.Info, or ... (there are dozens to choose from)
A blockchain service such as a blockexplorer does need to be upgraded
to handle a blocksize hardfork. The only work required is updating
their node software so that the MAX_BLOCKSIZE parameter is set to 2MB.
This can be done by either changing the source code themselves, or by
installing an alternate client such as XT, Classic, or Unlimited.
On 2/6/16, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Gavin
>
> It would probably be a good idea to have a security considerations
> section, also, is there a list of which exchange, library, wallet,
> pool, stats server, hardware etc you have tested this change against?
>
> Do you have a rollback plan in the event the hard-fork triggers via
> false voting as seemed to be prevalent during XT? (Or rollback just
> as contingency if something unforseen goes wrong).
>
> How do you plan to monitor and manage security through the hard-fork?
>
> Adam
>
> On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Responding to "28 days is not long enough" :
>>
>> I keep seeing this claim made with no evidence to back it up. As I said,
>> I
>> surveyed several of the biggest infrastructure providers and the btcd
>> lead
>> developer and they all agree "28 days is plenty of time."
>>
>> For individuals... why would it take somebody longer than 28 days to
>> either
>> download and restart their bitcoind, or to patch and then re-run (the
>> patch
>> can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
>>
>> For the Bitcoin Core project: I'm well aware of how long it takes to
>> roll
>> out new binaries, and 28 days is plenty of time.
>>
>> I suspect there ARE a significant percentage of un-maintained full
>> nodes--
>> probably 30 to 40%. Losing those nodes will not be a problem, for three
>> reasons:
>> 1) The network could shrink by 60% and it would still have plenty of open
>> connection slots
>> 2) People are committing to spinning up thousands of supports-2mb-nodes
>> during the grace period.
>> 3) We could wait a year and pick up maybe 10 or 20% more.
>>
>> I strongly disagree with the statement that there is no cost to a longer
>> grace period. There is broad agreement that a capacity increase is needed
>> NOW.
>>
>> To bring it back to bitcoin-dev territory: are there any TECHNICAL
>> arguments why an upgrade would take a business or individual longer than
>> 28
>> days?
>>
>>
>> Responding to Luke's message:
>>
>>> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>>> > wrote:
>>> >> Blog post on a couple of the constants chosen:
>>> >> http://gavinandresen.ninja/seventyfive-twentyeight
>>> >
>>> > Can you put this in the BIP's Rationale section (which appears to be
>>> > mis-named
>>> > "Discussion" in the current draft)?
>>
>>
>> I'll rename the section and expand it a little. I think standards
>> documents
>> like BIPs should be concise, though (written for implementors), so I'm
>> not
>> going to recreate the entire blog post there.
>>
>>>
>>> >
>>> >> Signature operations in un-executed branches of a Script are not
>>> >> counted
>>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>>> >> for a
>>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>>> >> top
>>> >> of the execution stack, it is counted as one signature operation. If
>>> >> it
>>> >> is
>>> >> satisfied by the public key nearest the bottom of the execution
>>> >> stack,
>>> >> it
>>> >> is counted as twenty signature operations. Signature operations
>>> >> involving
>>> >> invalidly encoded signatures or public keys are not counted towards
>>> >> the
>>> >> limit
>>> >
>>> > These seem like they will break static analysis entirely. That was a
>>> > noted
>>> > reason for creating BIP 16 to replace BIP 12. Is it no longer a
>>> > concern?
>>> > Would
>>> > it make sense to require scripts to commit to the total accurate-sigop
>>> > count
>>> > to fix this?
>>
>>
>> After implementing static counting and accurate counting... I was wrong.
>> Accurate/dynamic counting/limiting is quick and simple and can be
>> completely
>> safe (the counting code can be told the limit and can "early-out"
>> validation).
>>
>> I think making scripts commit to a total accurate sigop count is a bad
>> idea-- it would make multisignature signing more complicated for zero
>> benefit. E.g. if you're circulating a partially signed transaction to
>> that
>> must be signed by 2 of 5 people, you can end up with a transaction that
>> requires 2, 3, 4, or 5 signature operations to validate (depending on
>> which
>> public keys are used to do the signing). The first signer might have no
>> idea who else would sign and wouldn't know the accurate sigop count.
>>
>>>
>>> >
>>> >> The amount of data hashed to compute signature hashes is limited to
>>> >> 1,300,000,000 bytes per block.
>>> >
>>> > The rationale for this wasn't in your blog post. I assume it's based
>>> > on
>>> > the
>>> > current theoretical max at 1 MB blocks? Even a high-end PC would
>>> > probably take
>>> > 40-80 seconds just for the hashing, however - maybe a lower limit
>>> > would
>>> > be
>>> > best?
>>
>>
>> It is slightly more hashing than was required to validate block number
>> 364,422.
>>
>> There are a couple of advantages to a very high limit:
>>
>> 1) When the fork is over, special-case code for dealing with old blocks
>> can
>> be eliminated, because all old blocks satisfy the new limit.
>>
>> 2) More importantly, if the limit is small enough it might get hit by
>> standard transactions, then block creation code (CreateNewBlock() /
>> getblocktemplate / or some external transaction-assembling software) will
>> have to solve an even more complicated bin-packing problem to optimize
>> for
>> fees paid.
>>
>> In practice, the 20,000 sigop limit will always be reached before
>> MAX_BLOCK_SIGHASH.
>>
>>
>>>
>>> >
>>> >> Miners express their support for this BIP by ...
>>> >
>>> > But miners don't get to decide hardforks. How does the economy express
>>> > their
>>> > support for it? What happens if miners trigger it without consent from
>>> > the
>>> > economy?
>>
>>
>> "The economy" does support this.
>>
>>
>>>
>>> >
>>> > If you are intent on using the version bits to trigger the hardfork, I
>>> > suggest
>>> > rephrasing this such that miners should only enable the bit when they
>>> > have
>>> > independently confirmed economic support (this means implementations
>>> > need a
>>> > config option that defaults to off).
>>
>>
>> Happy to add words about economic majority.
>>
>> Classic will not implement a command-line option (the act of running
>> Classic
>> is "I opt in"), but happy to add one for a pull request to Core, assuming
>> Core would not see such a pull request as having any hostile intent.
>>
>>
>>> >
>>> >> SPV (simple payment validation) wallets are compatible with this
>>> >> change.
>>> >
>>> > Would prefer if this is corrected to "Light clients" or something.
>>> > Actual SPV
>>> > wallets do not exist at this time, and would not be compatible with a
>>> > hardfork.
>>
>>
>> Is there an explanation of SPV versus "Light Client" written somewhere
>> more
>> permanent than a reddit comment or forum post that I can point to?
>>
>>>
>>> >
>>> >> In the short term, an increase is needed to continue the current
>>> >> economic
>>> >> policies with regards to fees and block space, matching market
>>> >> expectations
>>> >> and preventing market disruption.
>>> >
>>> > IMO this sentence is the most controversial part of your draft, and it
>>> > wouldn't suffer a loss to remove it (or at least make it subjective).
>>
>>
>> Happy to remove.
>>
>>>
>>> > I would also prefer to see any hardfork:
>>> >
>>> > 1. Address at least the simple tasks on the hardfork wishlist (eg,
>>> > enable some
>>> > disabled opcodes; fix P2SH for N-of->15 multisig; etc).
>>
>>
>> Those would be separate BIPs. (according to BIP 1, smaller is better)
>>
>> After this 2MB bump, I agree we need to agree on a process for the next
>> hard
>> fork to avoid all of the unnecessary drama.
>>
>>> > 2. Be deployed as a soft-hardfork so as not to leave old nodes
>>> > entirely
>>> > insecure.
>>
>>
>> I haven't been paying attention to all of the
>> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
>> mean.
>> Is THAT written up somewhere?
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> _______________________________________________
>> 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
>

2023-06-07 19:47:00 CEST

- reply

📅 Original date posted:2015-12-20
📝 Original message:On 12/19/15, jl2012 <jl2012 at xbt.hk> wrote:
> Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到:
>> Block witholding attacks are only possible if you have a majority of
>> hashpower. If you only have 20% hashpower, you can't do this attack.
>> Currently, this attack is only a theoretical attack, as the ones with
>> all the hashpower today are not engaging in this behavior. Even if
>> someone who had a lot of hashpower decided to pull off this attack,
>> they wouldn't be able to disrupt much. Once that time comes, then I
>> think this problem should be solved, until then it should be a low
>> priority. There are more important things to work on in the meantime.
>>
>
> This is not true. For a pool with 5% total hash rate, an attacker only
> needs 0.5% of hash rate to sabotage 10% of their income. It's already
> enough to kill the pool
>
>
This begs the question: If this is such a devastating attack, then why
hasn't this attack brought down every pool in existence? As far as I'm
aware, there are many pools in operation despite this possibility.

2023-06-07 19:46:56 CEST

- reply

📅 Original date posted:2015-12-20
📝 Original message:Then shouldn't this be something the pool deals with, not the bitcoin protocol?
On 12/19/15, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> Peter was referring to pool-block-withholding, not selfish mining.
>
> On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>Block witholding attacks are only possible if you have a majority of
>>hashpower. If you only have 20% hashpower, you can't do this attack.
>>Currently, this attack is only a theoretical attack, as the ones with
>>all the hashpower today are not engaging in this behavior. Even if
>>someone who had a lot of hashpower decided to pull off this attack,
>>they wouldn't be able to disrupt much. Once that time comes, then I
>>think this problem should be solved, until then it should be a low
>>priority. There are more important things to work on in the meantime.
>>
>>On 12/19/15, Peter Todd via bitcoin-dev
>><bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> At the recent Scaling Bitcoin conference in Hong Kong we had a
>>chatham
>>> house rules workshop session attending by representitives of a super
>>> majority of the Bitcoin hashing power.
>>>
>>> One of the issues raised by the pools present was block withholding
>>> attacks, which they said are a real issue for them. In particular,
>>pools
>>> are receiving legitimate threats by bad actors threatening to use
>>block
>>> withholding attacks against them. Pools offering their services to
>>the
>>> general public without anti-privacy Know-Your-Customer have little
>>> defense against such attacks, which in turn is a threat to the
>>> decentralization of hashing power: without pools only fairly large
>>> hashing power installations are profitable as variance is a very real
>>> business expense. P2Pool is often brought up as a replacement for
>>pools,
>>> but it itself is still relatively vulnerable to block withholding,
>>and
>>> in any case has many other vulnerabilities and technical issues that
>>has
>>> prevented widespread adoption of P2Pool.
>>>
>>> Fixing block withholding is relatively simple, but (so far) requires
>>a
>>> SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We
>>should
>>> do this hard-fork in conjunction with any blocksize increase, which
>>will
>>> have the desirable side effect of clearly show consent by the entire
>>> ecosystem, SPV clients included.
>>>
>>>
>>> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
>>> witholding attacks are a good thing, as in their model they can be
>>used
>>> by small pools against larger pools, disincentivising large pools.
>>> However this argument is academic and not applicable to the real
>>world,
>>> as a much simpler defense against block withholding attacks is to use
>>> anti-privacy KYC and the legal system combined with the variety of
>>> withholding detection mechanisms only practical for large pools.
>>> Equally, large hashing power installations - a dangerous thing for
>>> decentralization - have no block withholding attack vulnerabilities.
>>>
>>> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>>>
>>_______________________________________________
>>bitcoin-dev mailing list
>>bitcoin-dev at lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

2023-06-07 19:46:14 CEST

- reply

📅 Original date posted:2015-12-13
📝 Original message:> In none of these cases do you lose anything.
Nor do you gain anything. Archive nodes will still need to exist
precisely because paper wallets don't include UTXO data. This is like
adding the ability to partially seed a movie with bittorrent. You
still need someone who has the whole thing has to be participating in
order for anyone to play the movie.
This isn't going to kill bitcoin, but it won't make it any better.
Every paper wallet would have to be re-printed with UTXO data
included. It doesn't even solve the core problem because someone can
still flood the network with lots of UTXOs, as long as they spend them
quickly.
On 12/13/15, Gregory Maxwell <greg at xiph.org> wrote:
> On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202 at ohiou.edu> wrote:
>> Lets say it's 2050 and I want to sweep a paper wallet I created in
>> 2013. I can't just make the TX and send it to the network, I have to
>> first contact an "archive node" to get the UTXO data in order to make
>> the TX. How is this better than how the system works today?
>
> You already are in that boat. If your paper wallet has only the
> private key (as 100% of them do today). You'll have no idea what coins
> have been assigned to it, or what their TXids are. You'll need to
> contact a public index (which isn't a service existing nodes provide)
> or synchronize the full blockchain history to find it. Both are also
> sufficient for jl2012's (/Petertodd's STXO), they'd only be providing
> you with somewhat more data. If instead, you insist that you'd
> already be running a full node and not have to wait for the sync, then
> again you'd also be your own archive. In none of these cases do you
> lose anything.
>

2023-06-07 19:46:13 CEST

- reply

📅 Original date posted:2015-12-13
📝 Original message:I don't like this scheme at all. It doesn't seem to make bitcoin
better, it makes it worse.
Lets say it's 2050 and I want to sweep a paper wallet I created in
2013. I can't just make the TX and send it to the network, I have to
first contact an "archive node" to get the UTXO data in order to make
the TX. How is this better than how the system works today?
Since many people are going to be holding BTC long term (store of
value of a first-class feature of bitcoin), this scheme is going to
effect pretty much all users.
These archive nodes will be essential to network's operation. If there
are no running archive nodes, the effect on the network is the same as
the network today without any full nodes.
Anyways, UTXO size is a function of number of users, rather than a
function of time. If tons of people join the network, UTXO still will
increase no matter what. All this change is going to do is make it
harder for people to use bitcoin. A person can still generate 1GB of
UTXO data, but as long as they spend those UTXOs within the amount
they are still using those resources.
IMO, wildcard inputs is still the best way to limit the UTXO set.
On 12/12/15, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> have run a node/kept their utxo before they were aware of this change and
>> then realise miners have discarded their utxo. Oops?
>
> I believe you have misunderstood jl2012's post. His post does not
> cause the outputs to become discarded. They are still spendable,
> but the transactions must carry a membership proof to spend them.
> They don't have to have stored the data themselves, but they must
> get it from somewhere-- including archive nodes that serve this
> purpose rather than having every full node carry all that data forever.
>
> Please be conservative with the send button. The list loses its
> utility if every moderately complex idea is hit with reflexive
> opposition by people who don't understand it.
>
> Peter Todd has proposed something fairly similar with "STXO
> commitments". The primary argument against this kind of approach that
> I'm aware of is that the membership proofs get pretty big, and if too
> aggressive this trades bandwidth for storage, and storage is usually
> the cheaper resource. Though at least the membership proofs could be
> omitted when transmitting to a node which has signaled that it has
> kept the historical data anyways.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:45:12 CEST

- reply

📅 Original date posted:2015-11-24
📝 Original message:Here is the problem I'm trying to solve with this idea:
Lets say you create an address, publish the address on your blog, and
tell all your readers to donate $0.05 to that address if they like
your blog. Lets assume you receive 10,000 donations this way. This all
adds up to $500. The problem is that because of the way the bitcoin
payment protocol works, a large chunk of that money will go to fees.
If one person sent you a single donation of $500, you would be able to
spend most of the $500, but since you got this coin by many smaller
UTXO's, your wallet has to use a higher tx fee when spending this
coin.
The technical reason for this is that you have to explicitly list each
UTXO individually when making bitcoin transactions. There is no way to
say "all the utxos". This post describes a way to achieve this. I'm
not yet a bitcoin master, so there are parts of this proposal that I
have not yet figured out entirely, but I'm sure other people who know
more could help out.
**OP_CHECKWILDCARDSIGVERIFY**
First, I propose a new opcode. This opcode works exactly the same as
OP_CHECKSIGVERIFY, except it only evaluates true if the signature is a
"wildcard signature". What is a wildcard signature you ask? This is
the part that I have not yet 100% figured out yet. It is basically a
signature that was created in such a way that expresses the private
key owners intent to make this input a *wildcard input*
** wildcard inputs **
A wildcard input is defined as a input to a transaction that has been
signed with OP_CHECKWILDCARDSIGVERIFY. The difference between a
wildcard input and a regular input is that the regular input respects
the "value" or "amount" field, while the wildcard input ignores that
value, and instead uses the value of *all inputs* with a matching
locking script.
** coalescing transaction"
A bitcoin transaction that