<unnamed>

Public Key

npub1r34khxrz9w39zpzezymqz04dcel95adfxf6qpjul9wdv2qn5vtps06s8vu

Profile Code

nprofile1qqspc6mtnp3zhgj3q3v3zdsp86kuvlj6wk5nyaqqew0jhxk9qf6x9scpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswrk7nn

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 23:14:09 UTC

- reply

📅 Original date posted:2022-10-04
📝 Original message:> Hi,
>
> Thanks for sharing your thoughts on packaged transaction relay.
Hello, thanks for the reply.
>> The sole objective, as expressed in the OP proposal, is to:
>> "Propagate transactions that are incentive-compatible to mine, even
>> if they don't meet minimum feerate alone."
>
> I actually do think there are additional goals we should include in any protocol
> change involving transaction relay, such as ensuring that we minimize
> bandwidth waste as much as possible (as I mentioned in a previous message
> in this thread).
Yes - there is always the presumption of an optimally-performing protocol (not limited to bandwidth), this is just a restatement from the OP.
The OP fails to eliminate orphan announcement, fails to prevent packages with insufficient fee from getting stuck in the same manner as txs (without explicitly re-announcing them again in an even larger package of higher feerate), and results in orphaned package announcements for the same reason (a static package is effectively just a larger tx).
Due to the resulting orphaning, a node must allow its peer to continue to broadcast unverifiable orphans to it, potentially chasing ancestry. So in addition to bandwidth waste, there is also an inherent problem of bandwidth DOS. These are problems specifically addressed by packaged relay.
[Regarding bandwidth waste: I've pointed out in years past that breaking the Bitcoin versioning scheme creates a requirement that any unknown message type be considered valid. Up until a recently-deployed protocol change, it had always been possible to validate messages by type. I noticed recently that validating nodes have been dropping peers at an increasing rate (a consequence of that deployment). Despite being an undocumented compatibility break, it is now unfortunately a matter of protocol that a peer must allow its peers to waste its bandwidth to remain compatible - something which we should eliminate.]
> While I understand your proposal seeks to improve on an idea of static
> packages in favor of dynamic package construction based on knowledge a
> node should have of its peers, I think the main drawback of your proposal is
> that it doesn't take into account the complexities of what a peer's "minimum
> feerate" might mean. The consequence of this is that it's not generally
> possible for a node to accurately guess whether a given transaction should
> be sent in a package to a given peer, or not, and so in addition to any
> "packaged transaction relay" mechanism that is implemented by a
> transaction announcer, we'd still need to add protocol support for a receiving
> peer to retrieve a package as well.
It is certainly possible that there is ambiguity in BIP133 (and BIPs that modify it). However it's not clear to me which such ambiguity you are referring to. There is no guessing proposed.
> First of all, a node's feerate is a dynamic value. BIP 133 allows for nodes to
> send feefilter messages at any time during the lifetime of a peer connection.
> If we were to compare the feerate of ancestors of a relayed transaction to
> the feerate in place at a peer as indicated by feefilter messages, and use that
> determine whether those ancestors would have been successfully relayed or
> not, then doing so accurately would seem to require caching relay success for
> each transaction, for each peer, at the time such transaction is relayed (or
> perhaps caching feefilter values that are received from a peer?). This seems
> likely to be undesirable,
This is a possible implementation. What makes it undesirable?
> and, at any rate, is more complex than merely comparing a pair of feerates.
There are no necessary protocol changes (though a new INV type is ideal), so the relative complexity you are implying could only arise from implementation. While implementation considerations are relevant, achieving simplicity in the protocol is presumably the priority. Further, implementation complexity must be considered from what is necessary to actually achieve the objectives, and not from the perspective of any given implementation.
Merely comparing a pair of feerates produces the problems described above, which includes not resolving the central problem, so this is an apples-to-oranges comparison. It's also more complex than doing nothing, but that also doesn't resolve the problem.
> But even more fundamental than feerates being dynamic is that feerate
> itself is not a well-defined concept when applied to arbitrary transaction
> (sub-)graphs, and this is at the crux of the difficulty in coming up with
> proposals that would meet the objective of ensuring that transactions which
> are incentive-compatible to mine all get relayed successfully across the
> network. Here are a couple examples that illustrate this:
>
> - Let A be a low feerate transaction (below any peer's minimum feerate). Let
> B and C be descendants of A (but are otherwise unrelated). Suppose these
> transactions are relayed to a node in the order A, B, C. In the algorithm you
> proposed, I believe the determination for whether C should be announced
> to a given peer as a package (A, C) or as a singleton would either (1) depend
> on whether the package (A, B) was sufficient to meet the peer's feerate,
Yes
> or (2) waste bandwidth by engaging in packaged relay whenever A was already
> successfully relayed as part of a package. Both of these approaches seem
> undesirable.
>
> - Let A be a high fee, but low feerate transaction.
Low feerate means low fee (as high/low can only be relative to size), it's not clear how these can both be true.
> Suppose B is a transaction
> that conflicts with A, has a high feerate, but lower total fee. In this situation,
> two different nodes that learned of these two transactions in opposite order
> [(A, B) vs (B, A)] might be expected to have differing mempools -- this at
> least would be the case in the BIP 125 algorithm (which requires that both
> feerate and total fee must increase when replacing an existing transaction),
As a node knows which txs it has relayed to its peer, order of arrival is inconsequential.
> and at any rate it's not obvious from the information given which would be
> more optimal to include in a block, as that depends on factors that go beyond
> just these two transactions.
Block inclusion in not pertinent, either may be included.
> Suppose further that a new transaction C is
> relayed on the network, which is a child of B and very high feerate, such that
> B + C have higher fee and higher feerate than A, when taken together. In
> this case we'd want our relay protocol to ensure that even nodes which saw
> A first should still have a chance to consider transaction C, but the packaging
> design you propose (which would compare transaction B's feerate to the
> peer's, and conclude packaging is unnecessary because B's feerate might
> already exceed the peer's feerate) would not facilitate this.
Given that A and B are conflicts, A and B+C are conflicts. This is no different than the original conflict of A and B, and decided based on the required BIP125 fee increment. If A arrives first, B must be an increment over A, and vice versa. Upon the arrival of C, given prior acceptance of both A and B, B+C must be an increment over A, as the conflict arises from A/B.
> To summarize, the point I'd make from these examples is that we should not
> expect that "feerate" (whatever that means) alone will be a sufficient
> predictor of what is in our peer's mempools.
Predicting a peer's set of confirmable transactions ("mempool") is not the objective or a requirement. As far as I can tell it is sufficient to achieve requirements to the extent there are no unpublished policies.
Upon startup and connection to a peer, a node may have an empty mempool. In this case there will be no orphan or redundant announcements from the peer.
A node with a populated mempool may connect to a peer. In that case the peer will receive announcements from the peer for txs which it may already have. This will also occur due to multiple peer connections. Redundancy is not within the scope of this or the OP proposals (there are other proposals for limiting this redundancy in both scenarios to the extent desirable).
Once a node has been connected to the network for some amount of time, there will be no orphans or connection-specific redundancies announced to it. This provides a basis for the node to drop non-conforming peers (that support packaged relay), improving protection against bandwidth-wasting peers.
Any node which implements unpublished policies can expect to receive orphan announcements. This raises the question of whether the protocol should incorporate a facility for such a node to chase down orphans in the case where it is orphaning them by deleting their ancestors, even though it publishes that it accepts them based on feerate/rbf. This would imply that there is some other discretionary aspect of transactions that, as a matter of protocol, should be considered for relay.
Any such aspect internal to a tx would be economically-irrational to consider (which includes censorship), in which case it would seem preferrable to let such nodes simply accept the fact that they are creating orphans for themselves.
Any such aspect external to the tx would also be economically-irrational (mining wants the greatest possible fee opportunity), but may be a consequence of resource limitations. Storing confirmable txs in RAM constrains such resources by orders of magnitude, and an assumption that an implementation must do this would be an error (some do not). Yet storage remains finite, so this remains a possible though marginal consideration given the presumption that all accepted txs are both confirmable and satisfy feerate/rbf policy. In the case where a node is discarding previously accepted and yet-unconfirmed txs, the node accepts the possibility that this will result in it receiving orphan announcements.
The rational way to reduce the size of the mempool is to raise the published feerate, discarding txs that no longer conform. While this was not specifically described in the fairly informal proposal, the receipt of a reduced peer feerate message can cause a node to update its state for that peer, eliminating the possibility of orphan announcements to it.
> So while there may be some
> situations where a transaction relayer might be able to usefully package up a
> transaction with its dependencies (perhaps in narrowly defined situations),
> there will also always be situations where this isn't possible, and what I
> conclude from that is that it should be helpful to add to the protocol some
> way for the recipient of a transaction to request the dependencies directly.
I don't think this has been shown, but finding such issues is of course why we discuss it.
> Taken together, I roughly understand Gloria's efforts here to be a
> combination of these two approaches: add some amount of packaged
> transaction relay for simple cases (ie where the transaction graph has been
> sufficiently narrowed, to minimize bandwidth waste while reducing latency),
> and also allow for a fallback mechanism where the recipient of a transaction
> can efficiently retrieve dependencies. There seems to be a tradeoff
> involving latency, bandwidth, and robustness of these two approaches (and
> maybe also implementation complexity), so I think it's natural to expect that
> it will take some discussion and understanding of what practices are common
> on the network and what behaviors wallet or other software might adopt,
> given potential protocol changes, to figure out how best to balance these
> ideas.
The problems that I see with static packaging are:
1) Does not fully resolve the problem - a static package itself can get stuck for the same reason as a tx.
2) Requires wallet formation of a static packages - to resolve what is fundamentally a network issue.
3) Adds a complex new protocol to achieve what can be accomplished with almost no protocol change.
4) Is not bandwidth optimal, as it continues to relay/chase orphans (singular and packaged).
5) Is not DOS optimal, as it requires allowance for orphans and redundancies.
Regarding complexity - searching and marking a DAG is basic CS, and there isn't much else to the necessary implementation. There are no new messages, just a version bump and a preferably a new INV type. In terms of performance and therefore any possible increase to relay latency, this is easily measured in terms of complexity. Whether this would be a latency increase or decrease in relation to the OP is unclear.
The complexity of the search for is linear in the size of the mempool subgraph (1) induced by the traversal of ancestors from the potential package's last tx, and (2) reduced by the set of txs known to the peer. (2) includes both txs sent to and received from the peer. This would appear to be a marginal cost.
A draft of the search algorithm is available here:
https://github.com/libbitcoin/libbitcoin-network/wiki/Iterative-Channel-Package-Computation
Best,
e

2023-06-07 23:08:48 UTC

- reply

📅 Original date posted:2022-05-18
📝 Original message:Good evening ZmnSCPxj,
Sorry for the long delay...
> Good morning e,
>
> > Good evening ZmnSCPxj,
> >
> > For the sake of simplicity, I'll use the terms lender (Landlord), borrower
> > (Lessor), interest (X), principal (Y), period (N) and maturity (height after N).
> >
> > The lender in your scenario "provides use" of the principal, and is paid
> > interest in exchange. This is of course the nature of lending, as a period
> > without one's capital incurs an opportunity cost that must be offset (by
> > interest).
> >
> > The borrower's "use" of the principal is what is being overlooked. To
> > generate income from capital one must produce something and sell it.
> > Production requires both capital and time. Borrowing the principle for the
> > period allows the borrower to produce goods, sell them, and return the
> > "profit" as interest to the lender. Use implies that the borrower is spending
> > the principle - trading it with others. Eventually any number of others end up
> > holding the principle. At maturity, the coin is returned to the lender (by
> > covenant). At that point, all people the borrower traded with are bag holders.
> > Knowledge of this scam results in an imputed net present zero value for the
> > borrowed principal.
>
> But in this scheme, the principal is not being used as money, but as a billboard
> for an advertisement.
>
> Thus, the bitcoins are not being used as money due to the use of the fidelity
> bond to back a "you can totally trust me I am not a bot!!" assertion.
> This is not the same as your scenario --- the funds are never transferred,
> instead, a different use of the locked funds is invented.
>
> As a better analogy: I am borrowing a piece of gold, smelting it down to make
> a nice shiny advertisement "I am totally not a bot!!", then at the end of the
> lease period, re-smelting it back and returning to you the same gold piece
> (with the exact same atoms constituting it), plus an interest from my business,
> which gained customers because of the shiny gold advertisement claiming "I
> am totally not a bot!!".
>
> That you use the same piece of gold for money does not preclude me using
> the gold for something else of economic value, like making a nice shiny
> advertisement, so I think your analysis fails there.
> Otherwise, your analysis is on point, but analyses something else entirely.
Ok, so you are suggesting the renting of someone else's proof of "burn" (opportunity cost) to prove your necessary expense - the financial equivalent of your own burn. Reading through the thread, it looks like you are suggesting this as a way the cost of the burn might be diluted across multiple uses, based on the obscuration of the identity. And therefore identity (or at least global uniqueness) enters the equation. Sounds like a reasonable concern to me.
It appears that the term "fidelity bond" is generally accepted, though I find this an unnecessarily misleading analogy. A bond is a loan (capital at risk), and a fidelity bond is also capital at risk (to provide assurance of some behavior). Proof of burn/work, such as Hash Cash (and Bitcoin), is merely demonstration of a prior expense. But in those cases, the expense is provably associated. As you have pointed out, if the burn is not associated with the specific use, it can be reused, diluting the demonstrated expense to an unprovable degree.
I can see how you come to refer to selling the PoB as "lending" it, because the covenant on the underlying coin is time constrained. But nothing is actually lent here. The "advertisement" created by the covenant (and its presumed exclusivity) is sold. This is also entirely consistent with the idea that a loan implies capital at risk. While this is nothing more than a terminology nit, the use of "fidelity bond" and the subsequent description of "renting" (the fidelity bond) both led me down another path (Tamas' proposal for risk free lending under covenant, which we discussed here years ago).
In any case, I tend to agree with your other posts on the subject. For the burn to be provably non-dilutable it must be a cost provably associated to the scenario which relies upon the cost. This provides the global uniqueness constraint (under cryptographic assumptions of difficulty).
Best,
e
> Regards,
> ZmnSCPxj

2023-06-07 23:08:47 UTC

- reply

📅 Original date posted:2022-05-04
📝 Original message:Good evening ZmnSCPxj,
For the sake of simplicity, I'll use the terms lender (Landlord), borrower (Lessor), interest (X), principal (Y), period (N) and maturity (height after N).
The lender in your scenario "provides use" of the principal, and is paid interest in exchange. This is of course the nature of lending, as a period without one's capital incurs an opportunity cost that must be offset (by interest).
The borrower's "use" of the principal is what is being overlooked. To generate income from capital one must produce something and sell it. Production requires both capital and time. Borrowing the principle for the period allows the borrower to produce goods, sell them, and return the "profit" as interest to the lender. Use implies that the borrower is spending the principle - trading it with others. Eventually any number of others end up holding the principle. At maturity, the coin is returned to the lender (by covenant). At that point, all people the borrower traded with are bag holders. Knowledge of this scam results in an imputed net present zero value for the borrowed principal.
While the lack of usability is a cost to the lender, it is not a benefit to the borrower. The lender incurs no risk, and will obtain no reward - as the loan is of no value. Failure to deploy capital is an opportunity cost, and locking it up is not deployment.
Now, even if we accept the generous (economically irrational) assumption that money must increase in price (i.e. trades from more goods) over any given period, we are still left with the observation that the presumed appreciation would accrue to the lender absent lending, making it pointless.
e
> -----Original Message-----
> From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Sent: Tuesday, May 3, 2022 7:37 PM
> To: Eric Voskuil <eric at voskuil.org>
> Cc: Chris Belcher <belcher at riseup.net>; Bitcoin Protocol Discussion <bitcoin-
> dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for
> BIP39 seeds
>
> Good morning e,
>
>
> > It looks like you are talking about lending where the principal return is
> guaranteed by covenant at maturity. This make the net present value of the
> loan zero.
>
> I am talking about lending where:
>
> * Lessor pays landlord X satoshis in rent.
> * Landlord provides use of the fidelity bond coin (value Y) for N blocks.
> * Landlord gets the entire fidelity bond amount (Y) back.
>
> Thus, the landlord gets X + Y satoshis, earning X satoshis, at the cost of having Y
> satoshis locked for N blocks.
>
> So I do not understand why the value of this, to the landlord, would be 0.
> Compare to a simple HODL strategy, where I lock Y satoshis for N blocks and
> get Y satoshi back.
> Or are you saying that a simple HODL strategy is of negative value and that
> "zero value" is the point where you actively invest all your savings?
> Or are you saying that HODL strategy is of some value since it still allows you
> to spend funds freely in the N blocks you are HODLing them, and the option to
> spend is of value, while dedfinitely locking the value Y for N blocks is equal to
> the value X of the rent paid (and thus net zero value)?
>
> Regards,
> ZmnSCPxj

2023-06-07 23:00:18 UTC

- reply

📅 Original date posted:2021-10-26
📝 Original message:Agree ZmnSCPxj
Hi lisa,
I'm all for removing it from memory. :) Did that a while ago. We just call it the transaction pool.
There will always be unconfirmed transactions floating around (even just from reorgs). Best to store them somewhere. Disk is cheap, block distribution (e.g. compact) works better if you have them already prevalidated, even if you aren't going to mine on them.
How you get them technically is not so important. There will always be a set of unconfirmed transactions, it's conceptual. But above all, anonymity is very important - on both ends. This is why transactions have integral fees. Anyone can get paid to mine, just need the txs.
Mining may be semi-restricted set is today, it may not be tomorrow. Imagine China everywhere, just like financial controls already are. That's when you see what Bitcoin can do from a security standpoint.
Treating miners as someone else is a poor security architecture. Everyone should look like a potential miner on the network, and a potential spender.
I think you are thinking of it a bit backwards. A node is a big pool of connected transactions. Block headers come along occasionally, and impose order on a subset of them.
e
> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf
> Of ZmnSCPxj via bitcoin-dev
> Sent: Tuesday, October 26, 2021 1:02 AM
> To: lisa neigut <niftynei at gmail.com>; Bitcoin Protocol Discussion <bitcoin-
> dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
>
>
> Good morning lisa,
>
> > Hi all,
> >
> > In a recent conversation with @glozow, I had the realization that the
> mempool is obsolete and should be eliminated.
> >
> > Instead, users should submit their transactions directly to mining pools,
> preferably over an anonymous communication network such as tor. This can
> easily be achieved by mining pools running a tor onion node for this express
> purpose (or via a lightning network extension etc)
> >
> > Mempools make sense in a world where mining is done by a large number
> of participating nodes, eg where the block template is constructed by a
> majority of the participants on the network. In this case, it is necessary to
> socialize pending transaction data to all participants, as you don’t know which
> participant will be constructing the winning block template.
> >
> > In reality however, mempool relay is unnecessary where the majority of
> hashpower and thus block template creation is concentrated in a semi-
> restricted set.
> >
> > Removing the mempool would greatly reduce the bandwidth requirement
> for running a node, keep intentionality of transactions private until
> confirmed/irrevocable, and naturally resolve all current issues inherent in
> package relay and rbf rules. It also resolves the recent minimum relay
> questions, as relay is no longer a concern for unmined transactions.
> >
> > Provided the number of block template producing actors remains beneath,
> say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can
> independently + directly submit their transactions to. In fact, merely allowing
> users to select their own list of endpoints to use alternatively to the mempool
> would be a low effort starting point for the eventual replacement.
> >
> > On the other hand, removing the mempool would greatly complicate solo
> mining and would also make BetterHash proposals, which move the block
> template construction away from a centralized mining pool back to the
> individual miner, much more difficult. It also makes explicit the target for DoS
> attacks.
>
> Unfortunately, this requires that miners have a persistent identity by which
> they can be contacted.
> While pseudonymity is possible, we all know that in practice, it can be easily
> pierced.
> For instance, consider that the injunction against address reuse is a
> recognition that a persistent pseudonym is a privacy leak.
>
> Ideally, the mining set should be as anonymous as possible, as some attacks
> are possible with sufficient hashpower, and making the miners keep a
> persistent identity by which they can be found may enable easier state co-
> option of mines.
> The strongest man on Earth cannot destroy his enemy if he does not know
> who and where his enemy is; so with enemies of Bitcoin and the miners of
> Bitcoin.
> (granted, near every darned mining pool self-identifies, sigh, wtf)
>
> Ideally, the set of relaying nodes hides the miners.
> Of course, in practice we can have a good guess of which relaying nodes are
> miners and which are not -- those who get blocks earlier are probably miners.
> Against this, we should note that this method of identification is probabilistic
> and not absolute (whereas miners advertising their services so they can be
> contacted and given unconfirmed transactions are a *definite* flag "I am a
> miner").
> And there is always the chance, however slim, that some node that has not
> been getting blocks "early" suddenly decides to buy a mining rig and start
> mining.
>
> In short: what you propose is to switch to side fee markets (as I understand it).
> Non-side fees are simply an anonymity layer, by which neither the miner nor
> the transactor need to know the identity of each other, they simply broadcast
> to the wider world.
> This anonymity layer remains important, however, as they help maintain the
> fee market: https://github.com/libbitcoin/libbitcoin-system/wiki/Side-Fee-
> Fallacy
>
>
> Ultimately, my objection here is simply that this requires miners to identify
> themselves.
> In practice, miners already identify themselves (even though they really,
> really should not), so this objection may be moot at this point.
>
> (Not to mention: something like P2Pool, as-is, would not work well in that
> model; you would need to implement a mempool for those as well)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:56:42 UTC

- reply

📅 Original date posted:2021-07-06
📝 Original message:> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this
Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.
> more than enough.
Arbitrary and subjective.
A business raises money (investment) so that it can spend more than it
previously had. This is net "insolvency" until (and assuming) it produces
and earns over time an amount sufficient to cover its capitalization and
time value.
These sort of schemes are relevant only to what Rothbard calls a money
"warehouse" (a literal vault), which is explicitly not a "bank" (banks
lend). Warehousing Bitcoin is a strange idea to start with. And given that
they are so larded with trust and race conditions it's hardly an improvement
over holding your own keys.
e
> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud <billy.tetrud at gmail.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proof of reserves - recording
>
> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proof
>
> to be honest, if any exchange supported that proof, it would be more than
> enough.
>
> there's really no way to prevent a smash-and-grab, but this does prevent a
> slow-leak
>
>
> On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev <bitcoin-
> dev at lists.linuxfoundation.org> wrote:
> >
> > I had the idea recently for proof of reserves done in a way that can be
used
> to verify reserves are sufficient on an ongoing basis. I'm curious if
there are
> any current approaches out there to proof of reserves that are similar.
> >
> > The idea is to have users create actual private keys using a seed in
pretty
> much the normal way. Users would generate a public key from this seed to
> represent their account, and would give the public key to the custodian to
> represent their account in a public record of account balances.
> >
> > When a user's account is credited, the custodian would update a map of
> addresses (created from the public key of each account) to balances - this
> map could be structured into a merkle tree in the usual "merkle approach".
> The custodian would also store funds on one or more HD wallets (each with
> many addresses) and create a proof that they own each HD wallet. The proof
> could be as simple as a single signature created with the xpub for the
wallet,
> which would be sufficient for proving ownership over the whole list/tree
of
> addresses.
> >
> > These two structures (the map and the HD wallet) would be combined and
> hashed, and the hash published in an on chain transaction (possibly along
> with a URI where the full data can be found), on something like a daily
basis.
> Software for each user could continuously validate that their account has
a
> balance that matches what it's supposed to have, and could also verify
that
> owned addresses have funds that have at least as many coins as promised to
> accounts. If these things aren't verifiable (either because the balances
total
> to more than the HD wallet contains, or because of data unavailability),
> people can raise hell about it.
> >
> > To give user's additional proving ability, a receipt system could be
added.
> Users could request a receipt for any balance update. Eg the user would
> create a message with a timestamp, their custodial "address", and the new
> balance. The user would sign this receipt and send it to the custodian,
who
> would also sign it and send it back. This way, if something goes wrong, a
user
> can use this signed receipt to show that the custodian did in fact promise
a
> new updated balance at a particular time (which would cover the case that
> the custodian records the wrong value in their map). Conversely, the
receipt
> would be useful to honest custodians as well, since they could show the
> user's signed receipt request in the case a user is trying to lie about
what
> balance they should have. There is still the case that the custodian
simply
> refuses to return a signed receipt, in which case the user's only recourse
is to
> yell about it immediately and demand a receipt or a refund.
> >
> > Why record it on chain? Doing that gives a clear record of proof of
reserves
> that can be verified later by anyone in the future. It prevents a
custodian
> from being able to change history when it suits them (by creating a new
> records with false timestamps in the past). Many of these records could be
> aggregated together and recorded in the same transaction (with a single
> hash), so a single transaction per day could record the records of all
> participating custodians. If all custodians are using a standard system,
one can
> cross verify that addresses claimed by one custodian aren't also claimed
by
> another custodian.
> >
> > Even tho the user is responsible for their keys in order to properly
verify,
> losing the keys isn't that big of a deal, since they could simply create a
new
> seed and give a new public key to the custodian - who would have other
> identifying information they could use to validate that they own the
account.
> So it places less responsibility on the user, while still introducing
people, in a
> light-weight way, to self custody of keys.
> >
> > Having a record like this every day would reduce the possibility of
> shenanigans like taking a short term loan of a large amount of
> cryptocurrency. Sure, they could take a 10 minute loan once per day, but
it
> would also be possible to trace on-chain transactions so you could tell if
such
> a thing was going on. I wonder if there would be some way to include the
> ability to prove balances held on the lightning network, but I suspect
that
> isn't generally possible.
> >
> > In any case, I'm curious what people think of this kind of thing, and if
> systems with similar properties are already out there.
> >
> >
> >
> >
> > _______________________________________________
> > 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 22:55:36 UTC

- reply

📅 Original date posted:2021-06-30
📝 Original message:All good questions.
> Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants?
It’s important that people understand that “economic” does not refer to people interested in, HODLing, coding, or selling Bitcoin. It is only those who are *presently accepting* it. We refer to these as “economic nodes”. Those are the people with the economic power to reject coin that they consider invalid. Only their validation is of any economic consequence in the event of a split. I see no reason to assume that the economy is any less centralized than mining is pooled. Today the support of the economy would be best measured by meeting with exchange operators. If they did not go along, any unenforced soft fork (split) would isolate everyone who thought they could continue to trade their coin on exchanges.
I’d also question the use of the term “majority”. It applies to hash power, by design, but not to the economy. A split of any size is possible, requiring no majority. All it requires is other people to trade with.
Exchanges are highly regulated and compliant institutions. Mining operations are heavily pooled. Neither of these is inherently better than the other. Everyone can have a say by being a miner or being a merchant. Subeconomies can split, majority hash power can censor (which is the exact mechanism of soft fork enforcement). These ideas are straightforward and hardly worthy of debate. The interesting question is how one gets others to go along with his new coin. Make no mistake, any rule change (soft or hard) is a new coin. If hash power doesn’t enforce the new rules of a soft fork, the chain is split just as if it was a hard fork.
I’m sure people will continue to try and devise ways to figure out who wants to come along, to try and convince people (including exchanges and miners) to do so, to reassure them that everyone else will “have to”, and to mislead them about the actual behavior and risks. We’ve seen permanent splits, and we’ve seen hash power enforced soft forks. We’re likely to see more of both. But as core devs we have a responsibility to inform people, honestly, and let them decide. My only beef with this whole process has been that a widespread belief had formed, supported by far too many core devs (and even embedded in the text of deployed BIPs), that soft forks are inherently “backward compatible”. This is unequivocally not true. The only such compatibility is majority hash power enforcement of a soft fork. This is not a matter of opinion, it’s the core innovation of Bitcoin. Proof of Work settles the question of who has authority to order transactions. Majority hash power has that authority. Merchants can split again and again, but their miners will still have that authority. If one wants a say, one can mine.
e
From: Billy Tetrud <billy.tetrud at gmail.com>
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric at voskuil.org>
Cc: Jorge Timón <jtimon at jtimon.cc>; Luke Dashjr <luke at dashjr.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
@Jorge
>I don't think we should avoid splits at all costs.
I absolutely agree that we shouldn't avoid splits at all costs. There are some costs too high to pay to avoid a split. If an economic majority started wanting to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard fork away from that mess with a minority chain.
> I don't think we should avoid splits when possible,
I want to see why exactly we disagree about avoiding chain splits "when possible". Are you really saying that we should just hard fork every time instead of soft fork? Should we even bother to get widespread buy in at all, or should we just release the software, hardfork away, and let anyone that wants to follow us follow us later? Are you not at all worried about the costs associated with an increased orphan rate and reorg rate? Are you not worried that an update might happen too fast and that a significant fraction of people that could have come along with us to the new update might be left behind because they didn't have time to evaluate the changed rules?
Do you agree that, in a conversation about rule changes, some people want it their way no matter what and will hardfork to get the rules they want, and some people want it their way, but only if enough other people agree to follow those rules too? Some people might want a rule change, but aren't willing to follow, say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people exist?
If you do, then I don't understand why you disagree that we should avoid chain splits even "when possible". Maybe you could elaborate as to what you mean there.
@Luke
Are you in agreement with Jorge here that we should not even attempt to avoid chain splits?
> The only alternative to a split in the problematic scenarios are 1) concede centralised miner control over the network, and 2) have inconsistent enforcement of rules by users who don't agree on what the correct rules are, again leading to centralised miner control over the network.
There is not simply a binary "do or do not". There is also timing. Non-contentious changes can happen fast. Contentious changes need more time for discussion, preparation, or coordination, even if the eventual outcome is the same. Do you disagree that timing issues can be important, that delays can be useful and help to avoid chain splits? Do you agree that miners have a (large) incentive to follow the economic majority? Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants? Will that mechanism continue to be accurate into the future?
I'm asking these questions to try and figure out why we disagree here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/cdb30f7e/attachment.html>

2023-06-07 18:29:39 UTC

- reply

📅 Original date posted:2021-03-01
📝 Original message:On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> Only headers need to be downloaded sequentially so downloading relevant blocks from one node is totally possible with gaps in between.
In fact this is exactly how libbitcoin v4 works. We download and store blocks in parallel. In the case of a restart block gaps are repopulated. Given that headers are validated, we go after the most responsive nodes. Based on standard deviation, we drop the slowest peers and rebalance load to new/empty channels. We make ordered but not necessarily sequential requests. There is no distinction between “initial” block download, a restart, or a single or few blocks at the top. So it’s referred to as continuous parallel block download.
But we don’t prune. Personally I consider this counterproductive. Apart from the complexity, it’s not healthy. And the chain grows linearly with storage cost falling exponentially, leading to a straightforward conclusion.
e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/568af3cd/attachment.html>

2023-06-07 18:29:26 UTC

- reply

📅 Original date posted:2021-03-03
📝 Original message:> consensus requires the ledger to be honest does not prove that it is honest.
Actually, that’s exactly what it does. A logical/mathematical requirement (necessity) is also called a proof.
e
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
Sent: Tuesday, March 2, 2021 7:06 PM
To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>; Daniel Edgecumbe <email at esotericnonsense.com>
Subject: Re: [bitcoin-dev] Taproot NACK
"Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured."
Good Afternoon,
Requiring little argument I concur, privacy allows that you do not have snoops and researchers following you around looking in your purse as you transact. For the general public, how much you carry in your purse and where you get it from is none of their business. However, your employer is required to report to the government a record of pay, or at least maintain that record, and the store where you made a purchase similarly to keep records so that taxes can be paid. From their perspective, you do not need to know how much they keep in their drawer. Bitcoin directly allows your purse to be private and for the transaction ledger to take the scrutiny anyone should be able to apply to prove the ledger is honest. Maintaining an argument that consensus requires the ledger to be honest does not prove that it is honest.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au <http://www.willtech.com.au>
www.go-overt.com <http://www.go-overt.com>
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this email if misdelivered.
_____
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Daniel Edgecumbe via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK
Any "transparency" in the blockchain, beyond that required for a participant to determine valid ownership, can only reasonably be thought of as a bug.
Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured.
Bitcoin is digital cash.
Daniel Edgecumbe | esotericnonsense
email at esotericnonsense.com <mailto:email at esotericnonsense.com> | https://esotericnonsense.com
On Mon, Mar 1, 2021, at 22:37, Eric Voskuil via bitcoin-dev wrote:
> To be clear, is this a NACK because Taproot reduces “transparency”
> (increases privacy) on the chain (“maintaining consensus” is obviously
> an argument against any protocol change, so that’s a red herring)?
>
> And is it your theory that only an “honest” (statute abiding) person
> should have privacy, and not against the state, and/or that mixers are
> sufficient privacy?
>
> Personally, I’m not moved by such an argument. What do you think is the
> value proposition of Bitcoin?
>
> e
>
> > On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> >
> >
> > Good Afternoon,
> >
> > I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
> >
> > My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
> >
> > The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
> >
> > My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
> > <ip.bitcointalk.org.png>
> >
> > [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> > https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png <https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw> &t=622&c=gTi7r1cfh-yynw
> > from this thread https://bitcointalk.org/index.php?topic=5267588
> >
> >
> > The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
> > https://github.com/jambler-io/bitcoin-mixer
> >
> > The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
> > https://jambler.io/become-partner.php
> >
> > I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
> >
> > If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
> >
> > KING JAMES HRMH
> > Great British Empire
> >
> > Regards,
> > The Australian
> > LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > of Hougun Manor & Glencoe & British Empire
> > MR. Damian A. James Williamson
> > Wills
> >
> > et al.
> >
> >
> > Willtech
> > www.willtech.com.au <http://www.willtech.com.au>
> > www.go-overt.com <http://www.go-overt.com>
> > and other projects
> >
> > earn.com/willtech
> > linkedin.com/in/damianwilliamson
> >
> >
> > m. 0487135719
> > f. +61261470192
> >
> >
> > This email does not constitute a general advice. Please disregard this email if misdelivered.
> > *From:* Ariel Lorenzo-Luaces <arielluaces at gmail.com <mailto:arielluaces at gmail.com> >
> > *Sent:* Monday, 1 March 2021 12:07 AM
> > *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
> > *Subject:* Re: [bitcoin-dev] Taproot NACK
> >
> > Hello LORD HIS EXCELLENCY JAMES HRMH
> >
> > I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com <http://www.go-overt.com>
> >
> > At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
> >
> > Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
> >
> > Cheers
> > Ariel Lorenzo-Luaces
> > On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> >> Good Evening,
> >>
> >> Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin> on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
> >>
> >> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
> >>
> >> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
> >>
> >> KING JAMES HRMH
> >> Great British Empire
> >>
> >> Regards,
> >> The Australian
> >> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> >> of Hougun Manor & Glencoe & British Empire
> >> MR. Damian A. James Williamson
> >> Wills
> >>
> >> et al.
> >>
> >>
> >> Willtech
> >> www.willtech.com.au <http://www.willtech.com.au>
> >> www.go-overt.com <http://www.go-overt.com>
> >> and other projects
> >>
> >> earn.com/willtech
> >> linkedin.com/in/damianwilliamson
> >>
> >>
> >> m. 0487135719
> >> f. +61261470192
> >>
> >>
> >> This email does not constitute a general advice. Please disregard this email if misdelivered.
> >> *From:* Jeremy <jlrubin at mit.edu <mailto:jlrubin at mit.edu> >
> >> *Sent:* Sunday, 28 February 2021 3:14 AM
> >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
> >> *Subject:* Re: [bitcoin-dev] Taproot NACK
> >>
> >> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
> >>
> >> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
> >>
> >> Do you have a source on your reporting?
> >>
> >> You may wish to rescind your nack.
> >>
> >>
> >> --
> >> @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin>
> >>
> >>
> >> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> >>> Good Afternoon,
> >>>
> >>> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
> >>>
> >>> If that is the case I offer a full NACK and let me explain.
> >>>
> >>> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
> >>>
> >>> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
> >>>
> >>> KING JAMES HRMH
> >>> Great British Empire
> >>>
> >>> Regards,
> >>> The Australian
> >>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> >>> of Hougun Manor & Glencoe & British Empire
> >>> MR. Damian A. James Williamson
> >>> Wills
> >>>
> >>> et al.
> >>>
> >>>
> >>> Willtech
> >>> www.willtech.com.au <http://www.willtech.com.au>
> >>> www.go-overt.com <http://www.go-overt.com>
> >>> and other projects
> >>>
> >>> earn.com/willtech
> >>> linkedin.com/in/damianwilliamson
> >>>
> >>>
> >>> m. 0487135719
> >>> f. +61261470192
> >>>
> >>>
> >>> This email does not constitute a general advice. Please disregard this email if misdelivered.
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > <ip.bitcointalk.org.png>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto: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/20210303/51f2aabd/attachment-0001.html>