Nostr notes by

📅 Original date posted:2018-12-27 📝 Original message: ...

2023-06-09T14:53:37+02:00

In reply to nevent1q…50s8
_________________________

📅 Original date posted:2018-12-27
📝 Original message:
ZmnSCPxj,

Brilliant reasoning. I sum it up to make it more accessible:

Failing to route on purpose can be used to opt out of a previously agreed exchange of two differents assets.
A rational actor will opt out if the exchange is no longer fair. Anyone who grants an option for free heads financial disaster.

This is not an issue for same asset exchange, as in payment routing, since the exchange remains fair at any later time point.

Although there is no escape from above reasoning, a market maker could still be profitable as long as the option is worth less than the bid-ask spread.
Therefore the issue does not mean that LN cross asset exchange is not feasible, but that there is lower bound on bid-ask spread, that of the option premium.

Tamas Blummer

> On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network
>
> Introduction
> ============
>
> In theory, the Lightning Network could potentially perform "seamless" currency conversions, allowing a payer to spend one currency to pay a payee requesting for another currency.
> However, a significant technical barrier prevents implementation of such feature as of current designs (late 2018) for Lightning.
>
> The root cause of this significant technical barrier is the use of hashlocked timelocked contracts to route payments.
> HTLCs can be used across cryptocurrency systems to transfer value between them.
> From this point-of-view, every single Lightning Network channel is a cryptocurrency system whose custodians are two entities, who are the only entities who can use the system (the single Lightning Network channel).
> HTLCs allow cross-system trades to be performed, so that participation on any single Lightning Network channel can be leveraged to participation over the entire Lightning Network.
>
> However, HTLCs can also be used to construct American Call Options.
> Further, due to UX concerns, on the Lightning Network, there is no cost incurred in merely setting up HTLCs for routing.
> By using the low-level HTLCs provided as primitives by Lightning Network, one can set up American Call Options.
> These on-Lightning American Call Options, however, can be "purchased" for free (gratis), thus potentially earning money in a completely risk-free manner.
> Abusing this gratis ability means that any Lightning Network node advertising cross-asset on-Lightning exchange will find large amounts of its liquidity tied up in stalled forwarding payments (in reality, American Call Options) with a risk of monetary loss in case of large fluctuations in exchange rate.
>
> Hashlocked Timelocked Contracts as American Call Options
> ========================================================
>
> An American CallOption is a right (but not obligation) to purchase an asset at a specific price, on or before an expiration date.
> HTLCs allow building American Call Options.
>
> Suppose we have Bitcoin, and some other asset, and both are on blockchains that support the same hash function and can define HTLCs.
> It is unimportant if both are on the same blockchain, or on different blockchains, since HTLCs can work across cryptocurrency systems.
>
> An American Call Option has these properties:
>
> 1. `P` = the price at which the asset can be purchased.
> 2. `E` = the date at which the option expires.
>
> Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 Widget (WJT) on the WJT blockchain.
> We would then do the below ritual:
>
> 1. You provide me a hash of some secret preimage that only you know.
> 2. You make an HTLC on the Bitcoin blockchain.
> The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day.
> 3. I make an HTLC on the WJT blockchain.
> The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`.
>
> On or before `E`, you can claim the WJT on the WJT blockchain by providing a transaction that reveals the preimage.
> Since the preimage is now revealed, I can then claim the Bitcoins of price `P` on the Bitcoin blockchain.
> Alternately, you can simply not exercise this right, and at time `E` I would then reclaim my WJT, and at time `E` + 1 day you would reclaim your bitcoins.
>
> Of course, I want to *sell* this contract to you, so you would have to pay me some bitcoins before we set up the above.
> A multi-stage construction of transactions that go through HTLC-like constructs can be done on both blockchains to ensure that the above contracts appear on both chains only if the payment for the actual contract (i.e. the "premium") is done, and to enforce that both contracts appear if the premium is paid, but that is beyond the scope of *this* writeup, which will focus on how Lightning Network HTLCs can form the above construction without any premium being paid.
>
> HTLCs For Routing
> =================
>
> HTLCs can be used to enforce trades across different cryptocurrency systems.
> This property is used to allow routing of payments across different channels.
> Each channel is its own cryptocurrency system.
>
> Suppose I, ZmnSCPxj, am an intermediate node on Lightning, and I wanted to sell you my service of facilitating payments on Lightning.
> Suppose you want to pay to somebody, who, for the sake of convenience, we shall randomly call YAIjbOJA.
> As it happens, I have a channel with you, and a channel with YAIjbOJa.
>
> You need to pay YAIjbOJA `P` bitcoins.
> We then perform the below ritual:
>
> 1. YAIjbOJA provides you a hash, whose preimage only YAIjbOJA knows.
> 2. On your channel with me, you set up an HTLC.
> The value is `P`+1 bitcoin (the 1 being my fee), the hash is the hash you were given, and the timelock is 2 days from now.
> 3. On my channel with YAIjbOJA, I set up an HTLC.
> The value is `P`, the hash is the same hash as above, and the timelock is 1 day from now.
>
> (in reality, the timelocks are parameterized and selected by the payer (you), and LN nodes will impose some "reasonable" limits on the timelocks; but the first HTLCs set up must have longer timelocks than the later HTLCs)
>
> Afterward, YAIjbOJA may claim, or may not claim, the money in the HTLC by releasing (or not releasing) the hash to me.
> If YAIjbOJA claims the money, then I can take the hash and claim the money, plus fee, from you.
> If not, then this is a payment failure and I will then cancel the HTLC you offered using standard Lightning Network primitives.
>
> In general, we expect that YAIjbOJA wants to have the money because every randomly-generated imaginary entity likes money.
> Thus, in the case of payments, YAIjbOJA has a strong incentive to claim the money without waiting for the timelock to expire or nearly expire.
> We can see that in practice, on the current Lightning Network, HTLCs are often very transient and will be quickly claimed, despite having long timelocks.
>
> This speed may mislead us into thinking that such convenience may be possible across different assets.
>
> Cross-Asset Lightning Nodes Offer Premium-Free American Call Options
> ====================================================================
>
> Suppose that Lightning Network supports multiple assets.
> Each channel has a single asset.
> Some nodes will advertise themselves as providing exchange capability, taking one asset on one channel and exchanging it for another asset on a different channel.
>
> Suppose I advertise myself as such an exchange.
> Suppose you want to pay to YAIjbOJA for 1 WJT, but have no WJT on hand to pay YAIjbOJA, only bitcoins.
> As it happens, I have a bitcoin channel with you and a WJT channel with YAIjbOJA.
> I advertise myself as exchanging `P` bitcoins for 1 WJT as of the current time.
>
> Further suppose that in reality, YAIjbOJA is *you*, random Internet person reading my thoughts.
>
> You, your fake persona YAIjbOJA, and me, then perform the following ritual:
>
> 1. YAIjbOJA (really you) provides you with a hash whose preimage only YAIjbOJA (actually you) know. (i.e. you just make it up)
> 2. On the bitcoin channel with me, you set up an HTLC.
> The value is `P`+1 bitcoin (the 1 being my fee), the hash is the hash that "YAIjbOJA" gave you (i.e. you really just made it up), and the timelock is 2 days from now.
> 3. On the WJT channel with YAIjbOJA (really you), I set up an HTLC.
> The value is 1 WJT, the hash is the hash you gave me, and the timelock is 1 day from now.
>
> The above is now the same as the setup for an American Call Option with expiration of 1 day from now.
> Further, within certain limits, you can set up the expiration of the American Call Option to be longer or shorter.
> Thus, I have inadvertently given you an American Call Option, for *no premium* (completely gratis), when my only intent was to facilitate cross-currency Lightning Network payments.
>
> Suppose that the price of 1 WJT rises far above the price of `P`+1 bitcoins before the expiration (1 day from now).
> In such a case, "YAIjbOJA" (really you) will then release the hash and acquire the 1 WJT.
> You then close this channel and claim the WJT onchain, then sell it immediately to earn more than the `P`+1 bitcoins you paid.
> Alternatively, presumably I would have a new exchange rate I would be willing to exchange WJT for, and you can just send the WJT with the new exchange rate immediately over the Lightning Network.
>
> Suppose that the price of WJT does not rise.
> Since this is an option and *not* a future, "YAIjbOJA" (really you) will simply claim that the payment errored somewhere and cancel the HTLCs.
> Since even payment errors are not unwrappable and are onion-wrapped, I cannot determine whether the payment really errored, or you were just setting up an American Call Option that you have now decided not to exercise.
>
> Premium-free American Call Options Are Risk-free Earning Pumps
> ==============================================================
>
> Traditionally, options are analyzed assuming that the option itself has a price, the premium.
> This premium is the risk of the user of the option.
> If the user of the option does not exercise the option before the expiration, then the premium is a pure loss of the user.
>
> However, the above setup does not involve any payment when the option is not exercised.
> Payment failures are "free" (gratis) on the Lightning Network.
> However, payment failures are also the non-exercised branch of the American Call Option that can be set up on a cross-currency on-Lightning exchange.
>
> Because the American Call Option is premium-free, even if the expiration is very near, rational entities will still construct such options.
> Extreme volatility may occur in short time frames, especially in the realm of digital assets.
>
> Thus, it is strongly likely that, if cross-asset exchange nodes on Lightning Network exist, they will be exploited to create risk-free American Call Options.
> They will find that significant liquidity will be tied up in such American Call Options, and find that they will lose funds especially at times of volatility.
>
> We can try to mitigate this, but the solutions below all have significant drawbacks.
>
> 1. We could force that setting up the HTLCs requires payment.
> This forces the above American Call Options to have a premium.
> The effect, however, is that routing failure is not free.
> The current Lightning Network works despite not everyone publishing the balances of channels, precisely because routing failure is free.
> We only need to have one route succeed in order to actually successfully pay to the payee.
> With non-free routing failure, we cannot try many routes until one succeeds.
> * Suppose we limited this only to cross-asset exchanges.
> It would still require accurate knowledge of channel balances.
> This is because if a payment fails on a hop *after* the exchange, the payer still loses money from that attempt to the exchange node.
> 2. Exchange nodes could increase their fees.
> This would create a wider "spread" of buying and selling assets.
> This spread would increase friction in crossing assets.
> Also, this would only reduce risk; if the exchange rate is volatile enough, then the option could still be exercised for riskless earnings.
> Rational entities will still tie up most of the liquidity on the exchange on riskless American Call Options; even if the exchange rate is very stable, they lose nothing.
> 3. Exchange nodes could limit the timelock of cross-asset swaps.
> This would increase friction in crossing assets, since a timelock limit also imposes a limit to the route length.
> If one asset is much stronger than the other, then the weaker asset will find its part of the Lightning Network to be strongly centralized around the exchanges between the two assets.
> Payees of the weaker asset will strongly prefer to be at most one hop away from exchanges in order to viably receive payments from payers who are using the stronger asset.
> Again, rational entities will also still tie up most of the liquidity on the exchange on riskless American Call Options; again, even if the exchange rate is very stable in short time frames, they lose nothing anyway.
>
> Conclusion
> ==========
>
> HTLCs allow creation of American Call Options.
> The same HTLCs are used in Lightning Network to route across channels.
> If using a single asset, there is no issue related to time.
> Regardless of the value of bitcoin relative to any other asset, in the future, 1 BTC is 1 BTC.
>
> However, across assets, the ability of HTLCs to create American Call Options becomes troublesome.
> These can then be exploited to earn money from exercise of the option.
> Further, because Lightning UX would be degraded otherwise, payment failures are free (gratis), leading to the American Call Options also being free of premium.
> This means that creating such options would be riskless, allowing potential earnings upon any strong volatility of exchange rates.
>
> This implies that a multi-asset Lightning Network may not be economically viable.
> Instead, Lightning Network would strongly prefer having a single asset across the network.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2019-09-21 📝 Original message:Hi ...

2023-06-07T20:20:41+02:00

In reply to nevent1q…xz7r
_________________________

📅 Original date posted:2019-09-21
📝 Original message:Hi Aleksey,

Yes, BIP158 uses the block hash to seed the hash function, which makes distinct block filters non-aggregatable
for common values. Aggregate fiters on ranges of blocks would have to use some other seed and then
achive significant savings using the same design.

I think that the most likely use of filters is to decide if a newly announced block should be downloaded and
not scanning over the entire chain, where aggregate filters would help. I also suspect that whole chain
scans would be better served with plain sequential reads in map-reduce style.

Typical clients do not care of filters for blocks before the birth date of their wallet’s keys, so they skip over the
majority of history which is a bigger saving than any aggregate filter.

I wish we get a filter committed as commitment would unlock more utility than any marginal savings through
more elaborate design.

Tamas Blummer

> On Sep 19, 2019, at 19:20, admin--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello list,
>
> Here is a link for a draft of a BIP for compact probabilistic block filters alternative of BIP 158
>
> https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing <https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing>;
>
> Summary:
>
> - BIP 158 false positive rate is low, we can achieve lower bandwidth with higher false positive rate filter while sync blockchain
>
> - BIP 158 not do not support filter batching by design of used parameters for siphash and Golomb coding optimal parameters
>
> - Alternative compression with delta coding and splitting data to 2 bit string sequences. First for data without prefixes, second one for information about bit length written to first sequence.
> Second sequence have a lot of duplicates, compressed with 2 round of Huffman algorithm. (Effectivity about 98% vs Golomb with optimal parameters)
>
> - Block filters batching reduce filter size significantly
>
> - Separation of filters by address type allows lite client not to download redundant information without compromising privacy.
>
> - Lite client filters download strategy: get biggest filter (smallest blocks/size rate) for blocks range, in case positive test -> get medium filters to reduce blocks range -> get block filters for affected range -> download affected blocks over TOR
>
> Implementation (python): https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172 <https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172>;
>
> Exactly information from mainnet about size for separated filters by address types and batch size will be added within few days.
>
> Thanks for any feedback.
> Aleksey Karpov
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190921/ecea43cc/attachment.html>;

📅 Original date posted:2019-07-26 📝 Original message:Hi ...

2023-06-07T20:19:42+02:00

In reply to nevent1q…2slt
_________________________

📅 Original date posted:2019-07-26
📝 Original message:Hi Chris,

yes, fidelity bonds can impose cost to make sybill attacks more expensive therefore less likely.
I prefer the flavor with CHECKSEQUENCEVERIFY which imposes opportunity cost, just as effective
as burning, but is sustainable.

Imposing opportunity costs however requires larger time locked amounts than burning and the
user might not have sufficient funds to do so. This is however not a restriction but an opportunity
that can give rise to an additional market of locking UTXOs in exchange of a payment.

This would give rise to a transparent interest rate market for Bitcoin an additional huge benefit.

Regards,

Tamas Blummer

> On Jul 25, 2019, at 13:47, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> JoinMarket[1] can be sybil attacked today at relatively low cost which
> can destroy its privacy. Bitcoins can be sacrificed with burner outputs
> and time-locked addresses (also called fidelity bonds), and this can be
> used to greatly improve JoinMarket's resistance to sybil attacks.
>
> With real-world data and realistic assumptions we calculate that under
> such a fidelity bond system an adversary would need to lock up
> 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner
> addresses to have a good chance of sybil attacking the system if it were
> added to JoinMarket.
>
> This increased resistance to sybil attacks would most likely cause
> coinjoin fees to rise. I think the added cost is worth it for the
> greatly improved privacy, because today miner fees are the biggest cost
> to JoinMarket takers not coinjoin fees which are very low. Users should
> definitely share their opinion on fees after reading the document.
>
> ## Introduction
>
> JoinMarket creates a market for coinjoins, allowing anyone to create
> equal-amount coinjoins for any amount they want at any time they want.
> In return they pay a fee for the liquidity made available to them. The
> project has existed since 2015 and has probably created hundreds of
> thousands of coinjoins since then. Today there is available liquidity
> for creating coinjoins with amounts up to about 400 btc per coinjoin output.
>
> ### Sybil attacks
>
> JoinMarket, like many other schemes where participants are free to
> anonymously enter, can be targetted by sybil attacks. In JoinMarket this
> would work by an attacker running lots of maker bots which attempt to be
> all the makers in every coinjoin. If successful the attacker would have
> enough information unmix every coinjoin.
>
> One way to solve the problem of sybil attacks is centralization. For
> example coinjoins could be constructed on a centralized server. Then
> random anonymous participants cant sybil attack because they can't
> control the coinjoin construction, but this comes at the cost that the
> server can sybil attack very easily. So this solution is probably a bad
> tradeoff.
>
> In general, sybil attacks are solved by making them expensive. For
> example, bitcoin mining resists sybil attacks because it requires a
> provable sacrifice of electricity to mine. A bitcoin user can calculate
> the actual monetary value that an attacker must spend in order to
> reverse their transaction.
>
> Likewise in JoinMarket such a sybil attack is not free either as the
> attacker needs to own enough bitcoins to run enough maker bots for all
> the coinjoins.
>
> ### Today's low cost for sybil attacks
>
> A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a
> Market for Anonymity.” (2016).] calculates the requirement of such a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
>
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
>
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
>
> Apart from the cost to sybil attack being low, there is also the odd
> situation that smaller coinjoin amounts receive less sybil protection
> than large ones. It costs 100x less to sybil attack a transaction of 0.1
> btc than one of 10 btc. Why should smaller amounts receive less
> sybil-resistance and therefore less privacy?
>
> ### Liquidity
>
> When creating this project, it was expected that many more people would
> enter the market as makers and so the cost of a sybil attack would be
> very high. That has not happened. One reason is that everyone who wants
> to create a coinjoin is able to even for large amounts. The fundamental
> problem is that takers are paying-for and getting liquidity, but not
> necessarily sybil-resistance.
>
> Another smaller reason for the low cost of sybil attacks is that many
> people don't want to store too many bitcoins on an computer connected to
> the internet.
>
> What is needed is a way to increase the cost of running in a maker in a
> way that retains the anonymity and is attractive to long-term holders of
> bitcoin. This can be done using time-locked addresses.
>
> ## Fidelity bonds
>
> In bitcoin, a fidelity bond [3] is a mechanism where bitcoin value is
> deliberately sacrificed to make a cryptographic identity expensive to
> obtain. The sacrifice is done in a way that can be proven to a third party.
>
> A way to create a fidelity bond is to burn an amount of bitcoins by
> sending to a OP_RETURN output. Another kind is time-locked addresses
> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
> sacrificed is time rather than money, but the two are related because of
> the time-value-of-money.
>
> Under this system, makers would sacrifice an amount of bitcoins and
> publish a proof along with their coinjoin offers. Takers would choose
> maker offers based on the sacrificed amount (as well as other factors),
> knowing that a sybil attacker would also have to sacrifice a certain
> amount of coins in order to unmix the taker's coinjoins. The sacrifice
> would be an objective measurement that can't be faked and which can be
> verified by anybody (just like, for example PoW mining)
>
> Note that a long-term holder (or hodler) of bitcoins can buy time-locked
> fidelity bonds essentially for free, assuming they never intended to
> transact with their coins much anyway. A long-term holder probably won't
> want to attack a system like JoinMarket which makes his own investment
> coins more private and more fungible.
>
> ### Fidelity bonds in cold storage
>
> The private keys of fidelity bonds can be kept offline. Signatures
> potentially only need to be made when the timelock expires (every 6
> months for example), or only once in the case of OP_RETURN burned coins.
> This allows JoinMarket's sybil resistance to increase without the hot
> wallet risk.
>
> Burned coin signatures should still have a lifetime, in case the private
> key associated with the IRC nick (which is online) is stolen, so that
> the thief of that privkey can't impersonate the maker indefinitely. The
> signature linking the burned coins and IRC nick could expire after
> perhaps 6 months.
>
> ### Anonymity
>
> Under this scheme makers would need to publish the transactions of their
> fidelity bonds to the entire world. Those transactions could be subject
> to blockchain analysis. So before makers do this they should make sure
> their coins are anonymous (possibly by mixing with JoinMarket). Also if
> they ever want to use their coins for something else apart from fidelity
> bonds they should mix them.
>
> ### Value of a fidelity bond
>
> See the other document (Financial mathematics of joinmarket fidelity
> bonds)[4] for a formula expressing the value of a fidelity bond.
>
> The value of a fidelity bond made by sending V bitcoins to a burner
> address is:
>
> V^2
>
> The amount of bitcoins is squared to get the fidelity bond value. This
> has the effect that economic-rational makers have a strong incentive to
> lump up all their coin sacrifices together into one maker bot, not to
> split it up over several bots.
>
> The value of a fidelity bond made by locking up V bitcoins in a
> time-locked address for time period T is:
>
> V^2 (exp(rT) - 1)^2
>
> To get an idea of the numbers, if we burn 2 btc then the value of the
> fidelity bond is 4 BTC^2. If we lock up 100 BTC for one year, and have a
> bitcoin interest rate r = 0.001 (0.1%) per year, then the value of that
> fidelity bond is 0.01 BTC^2 which is the same as burning 0.1 BTC. That
> is a relatively small valued bond. It can be increased by locking up
> more bitcoins for longer (up to and including permanant locking via a
> burner transaction).
>
> ## Taker algorithm for choosing makers
>
> I suggest the following taker peer choosing algorithm: obtain the list
> of offers and discard offers which the taker's user deems are too
> expensive. One of the remaining offers is randomly chosen with weighting
> determined by the fidelity bond value. Once an offer is chosen it is
> removed from the list, and another offer is again randomly chosen, this
> is repeated until the taker has chosen the desired number of
> fidelity-bonded maker's offers.
>
> Some people run makers not for profit but for their own privacy.
> Therefore not all makers should be required to have bonds, because such
> privacy-makers are useful to include in coinjoins too. We could have
> taker allow say, an eighth (12.5%), of their coinjoin peers to be makers
> without bonds. They can be chosen randomly from the orderbook without
> any weighting based on fidelity bond values. Of course these are easy to
> fake by an adversary so they dont contribute much to sybil resistance.
>
> ### Cost of sybil attacks
>
> See the other document (Cost of sybil attacks) for discussion and
> calculations on the sybil resistance given by the above maker-choosing
> algorithm.
>
> It can be calculated that the fidelity bond system dramatically
> increases the cost of a sybil attack. With real-world data and realistic
> assumptions we can calculate that a sybil attacker would need to lock up
> 30,000-80,000 bitcoins for 6 months, or send 45-120 bitcoins to burner
> addresses to have a good chance of attacking the system by being all the
> counterparties in everyone's coinjoin.
>
> ## Effect of fidelity bonds on CoinJoin fees
>
> Someone might ask "why would anyone lock up coins for months or more,
> let alone burn coins forever, just to run a maker bot". The only way
> this would even happen is if makers can generate a higher income that
> justifies the fidelity bond sacrifice. That higher income can only come
> from taker's coinjoin fees (or possibly coinswap fees one day). We can
> expect that makers with higher valued fidelity bonds will demand higher
> coinjoin fees. So a big question is whether takers will accept paying
> higher coinjoin fees. I think they will, because right now coinjoin fees
> are only 10-1000 satoshi, and a far biggest cost of coinjoins is the
> miner fee not the coinjoin fee. I'm pretty sure takers will recognize
> that they get what they pay for, and that additional privacy is well
> worth the cost. Any other takers reading this should definitely let me
> know what they think.
>
> ## Technical ideas
>
> JoinMarket's wallet could also create time-locked addresses. Locktimes
> should be fixed to be midnight on the first day of each month, then each
> public key corresponds to 12 addresses per year (1200 addresses per
> century) which is very practical to all be monitored as watch-only
> addresses. These wallets can be created offline and could safely hold
> time-locked bitcoins.
>
> The timelocked addresses public key can be used to sign an IRC nickname
> proving that the nickname is the real owner of the TXO. OP_RETURN
> outputs used for burning coins can include a pubkey hash used for the
> same thing.
>
> We don't want the cold storage keypairs to be held online. We can design
> the system that the time-locked address keypair is held offline but it
> signs another key pair which is held online. Every time the IRC bot
> connects it can use this intermediate keypair to sign the IRC nickname
> proving ownership. The signature from the time-locked address to the
> intermediate keypair can be made to have an expiry date (for example 6
> months). This all means that the time-locked bitcoins can be held
> offline but still be used to prove ownership of an IRC nickname.
>
> The existance of the UTXO of a time-locked coin can be proved by
> revealing the TXID and vout, which full nodes can use to query the UTXO
> set to check that the coin exists. SPV clients would need a merkle proof
> as well. Burned coins and spent time-locked coins could have their
> existence proved by sharing the transaction which created them along
> with a block height and transaction position for an unpruned node, or a
> merkle proof for a pruned node or SPV client. Note that from the point
> of view of a pruned node, a merkle proof is a fully-verified proof of
> existance of a transaction. It is not a proof with just SPV-security.
>
> ## Links / References
> [1] https://github.com/JoinMarket-Org/joinmarket-clientserver
> [2] https://github.com/JoinMarket-Org/joinmarket/issues/693
> [3] https://en.bitcoin.it/wiki/Fidelity_bonds
> [4] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
> [5]
> https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybil-attacks
> [6] First ever mention of fidelity bonds I found. The idea is basically
> invented by Peter Todd: https://bitcointalk.org/index.php?topic=134827.0
> [7] Old idea for combining fidelity bonds with mixers:
> https://bitcointalk.org/index.php?topic=172047.0
> [8] Suggestion that is very close to the fidelity bonds idea. He talks
> about requiring a deposit from makers, but nobody is able to come up
> with a way to make such a deposit decentralized and trustless:
> https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=1
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190726/1ca45f01/attachment-0001.sig>;

📅 Original date posted:2019-07-04 📝 Original message:Hi ...

2023-06-07T20:19:08+02:00

In reply to nevent1q…4y3h
_________________________

📅 Original date posted:2019-07-04
📝 Original message:Hi Eric,

there are some other ways to impose cost on use without direct billing, e.g.:

- Burn Bitcoins to use the service, as you mentioned. This could work and would benefit remaining Bitcoin owner, but is unsustainable.

- Pay high fees in self dealing transactions. This could work and would benefit miner.

- Time lock own Bitcoins. This is forgoing control of an UTXO for a time period, which implies opportunity cost. This could be done with CLTV (OP_HODL). It damages the current owner but benefits no one. The problem is one might not have substantial UTXO to imply high enough opportunity cost.

- Pay someone else to time lock. This is paying someone to lock an UTXO for a time span. Payment and time lock could be combined in the same transaction.

- Transferable borrowed Bitcoin. This needs the covenant. This benefits those who consciously give up control for a time span. Its advantage is that since transferable it can be sold if no longer needed, thereby shortening the term of the original arrangement. It coul be re-rented for a shorter time period.

Tamas Blummer

> On Jul 4, 2019, at 18:43, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi ZmnSCPxj,
>
> Generalizing a bit this appears to be the same with one exception. The amount of encumbered coin is relevant to an external observer. Of course the effective dust limit is the maximum necessary encumbrance otherwise.
>
> In the case of simple tracking, the market value of the coin is not relevant, all that is required is a valid output. Hence the devolution to 1 sat tracking. In your scenario the objective is to establish a meaningful cost for the output.
>
> A community of people using this as a sort of hashcash spam protection can raise the amount of encumbered coin (i.e. advertising threshold price) required in that context. The cost of this encumberance includes not only at least one tx fee but market cost of the coin rental.
>
> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 encumbered coin, the same is achieved by burning .1 coin. In other words the renter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coin for one year.
>
> As with Bitcoin mining, it is the consumed cost that matters in this scenario, (i.e., not the hash rate, or in this case the encumbered coin face value). Why would the advertiser not simply be required to burn .1 coin for the same privilege, just as miners burn energy? Why would it not make more sense to spend that coin in support of the secondary network (e.g. paying for confirmation security), just as with the burning of energy in Bitcoin mining?
>
> e
>
>> On Jul 3, 2019, at 23:57, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> Good morning Eric,
>>
>>
>>>> and thanks to you and ZmnSCPxj we now have two additional uses cases for UTXOs that are only temporarily accessible to their current owner.
>>>
>>> Actually you have a single potentially-valid use case, the one I have presented. The others I have shown to be invalid (apart from scamming) and no additional information to demonstrate errors in my conclusions have been offered.
>>
>> I presented another use case, that of the "Bitcoin Classified Ads Network".
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
>>
>> Advertisements are "backed" by an unspent TXO.
>> In order to limit their local resource consumption, nodes of this network will preferentially keep advertisements that are backed by higher UTXO values divided by advertisement size, and drop those with too low UTXO value divided by advertisement size.
>>
>> Thus, spammers will either need to rent larger UTXO values for their spam, paying for the higher rent involved, or fall back to pre-Bitcoin spamming methods.
>> Thus I think I have presented a use-case that is viable for this and does not simply devolve to "just burn a 1-satoshi output".
>>
>> I still do not quite support generalized covenants as the use-case is already possible on current Bitcoin (and given that with just a little more transaction introspection this enables Turing-completeness), but the basic concept of "renting a UTXO of substantial value" appears sound to me.
>>
>>
>> Regards,
>> ZmnSCPxj

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190704/b4487436/attachment.sig>;

📅 Original date posted:2019-07-02 📝 Original message:Hello ...

2023-06-07T20:19:06+02:00

In reply to nevent1q…scn3
_________________________

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,

> On Jul 2, 2019, at 12:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, July 2, 2019 5:30 PM, Tamas Blummer <tamas.blummer at gmail.com <mailto:tamas.blummer at gmail.com>> wrote:
>
>> The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
>
> No it would not :)

You are right. I noticed after sending my reply and then I sent two other. I apologize for being noisy.

Let me consolidate my thinking, here.

If there is a use for UTXOs with temporary control, then those who want that use will pay for it.

A user of a service that requires temporary control UTXOs would need to cover:

1. fees required by the service
2. the opportunity cost of temporary ownership paid to the original holder who gave up control.

If the service is operated by an entity billing user then it can use UTXOs of minimal value for its operation and practically ignore opportunity interest.
This is the case with theater tickets just and other simple colored coin like use of Bitcoin. Also in case of the unchained advertizement, if the service bills its user
for its internal re-allocation of an UTXO, then why would it need to use significant value temorary control UTXOs? Actually why not use plain UTXOs, to start with?

If however the service is a common good, a network without owner and therefore not billing on behalf of someone, but wants to protect itself from spam, then it is could require temporary access to significant value UTXOs and thereby induce opportunity cost to user. Alternatively it could require burning ordinary UTXOs. Burning indirectly benefits all HODLer, temporary control benefits those who consciously gave up control. I dislike burning as it is unsustainable.

If the implementation of temporary use is enforced by consenus such that it is transitive, then temporary use could be re-rented or sold to recover opportunity cost for no longer needed temporary access, making it useable for an other service.

Temporary access UTXOs with covenants allows us to build spam limited public services that are not owned by an operator and financially benefit HODLer offering them riskless interest.

Tamas Blummer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190702/3b7b41ad/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190702/3b7b41ad/attachment-0001.sig>;

📅 Original date posted:2019-07-02 📝 Original message:Hello ...

2023-06-07T20:19:05+02:00

In reply to nevent1q…24rn
_________________________

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,

To be more precise, the value of the UTXO is severaly damaged that it is governed by rules of a de-facto side chain with different rules.
Therefore its value to those renting it from the advertizer is just that of the advertizement, which is not neccesarily following the opportunity cost.

The covenant supported temporary access is transitive, therefore anyone who is in temporary control of an UTXO can recover its cost by sub-renting.
The opportunity (riskless) interest provides a baseline of value on top of which you may have utility that is the advertizement.

Regards,

Tamas Blummer

> On Jul 2, 2019, at 11:30, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> Hello ZmnSCPxj,
>
>> On Jul 2, 2019, at 10:12, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> As a counterargument, I observe that committing to the advertisement on the UTXO is similar to committing to a SCRIPT on a UTXO.
>> And I observe the Graftroot idea, wherein we commit to a public key on the UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that unlocks the UTXO for spending.
>>
>> By analogy, in my "advertising" scheme, instead of committing the advertisement on the UTXO, I can instead commit a public key (for example, the hash of the "advertiser pubkey" is used to tweak the onchain public key).
>> Then we use this advertiser pubkey to admit advertisements on the advertising network.
>>
>> This advertiser pubkey is used to sign an "advertisement chain", which is a merklized singly-linked list whose contents are the actual advertisements, each node being signed using the advertiser pubkey.
>> To ensure that the advertiser does not sign multiple versions of this chain, we can have the signing nonce be derived from the height of the advertchain, such that signing the same height multiple times leads to private key revelation.
>
> The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
> This is not the trustless separation the covenant achives.
>
> Regards,
>
> Tamas Blummer
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190702/46768c00/attachment.sig>;

📅 Original date posted:2019-07-02 📝 Original message:Good ...

2023-06-07T20:19:04+02:00

In reply to nevent1q…arl9
_________________________

📅 Original date posted:2019-07-02
📝 Original message:Good morning Eric and ZmnSCPxj,

> On Jul 2, 2019, at 05:45, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Eric, and Tamas,
>
>> In the case of tracking an asset that becomes worthless at a specific time, one could value a record of ownership, and the ability to trade ownership of the asset during the period. Consider colored coin type tracking of a theater ticket for a specific show, where the ticket is worthless by the end of the show.
>
> As it happens, I was playing around with another idea I am developing.
> And it involves something very much similar, but distinct.
>
> In particular, currencies are worthless unless exchanged for things of value to existent beings.
> And the discovery of things of value is enabled by advertising.
> The idea I am developing, is that of a "Bitcoin Classified Ads Network", wherein ordinary P2PKH UTXOs (or P2WPKH equivalents) embed a commitment to an advertisement.
> A secondary network of nodes (separate from the Bitcoin network) transmits the actual advertisements, as well as the UTXOs being used to commit to them.
> This secondary network would then reject/purge advertisements once the UTXO is spent on the Bitcoin blockchain.
> This makes advertising costly (for the opportunity cost of locking some money in a UTXO until one has acquired actual paying custom) while reducing impact on Bitcoin blockchain space (commitment to the advertisment is in the same space as the ownership of the coin).
> Changing the advertisement one makes is possible, at the cost of paying for a transaction in the Bitcoin blockchain to spend the old UTXO and publish a new UTXO now committing to the new advertisement.
>
> Of note is that I also derived that it would be beneficial, for some HODLers to offer their funds for the purpose of making these advertisements.

All above aligns with my intuition that: on one side giving up temporary control of UTXOs represent opportunity cost and on the receiver side having temporary control can unlock utility they would pay for.
If the techical setup is trustless and return of control to those who gave it up temporarilty is certain, then this in combination means that HODLer are able to earn riskless interest by giving up control of their UTXOs temporarily.

> Some service or product provider would agree with an advertiser to lock some coins of the advertiser for a limited amount of time, in exchange for payment upfront, with the coin address committing to the indicate advertisement of the service or product provider.
> This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) public key, with the service/product provider embedding a commitment to its advertisement to its own key, and a pre-signed `nLockTime` transaction that lets the advertiser recover the money.
>
> This is in fact a similar use to the "theater ticket" case you mentioned, yet distinct.
> In the case of the Bitcoin Classified Ads Network, it is the intermediate addresses used before reclamation by the advertiser that is valuable, as they also serve as commitments to advertisements, attesting to the (probable) validity of the advertisement and making spam have a cost.
> Given that nodes of the Bitcoin Classified Ads Network will have memory limits, advertisements whose "lockup-rate" (i.e. the amount of value of the backing UTXO, divided by the size of the advertisement) are low could be evicted from memory before advertisements with high lockup-rate, and thus be less likely to propagate across the network.
> Thus service/product providers would want to increase their "marketing budget" to be less likely to be evicted from nodes of the Bitcoin Classified Ads Network, which is beneficial as it increases the minimum practical lockup-rate needed to spam the network, thus making spam costly.
>
> My current plan is that the provider can contact the advertiser in order to effect changes to their advertisement.
> Then the provider and the advertiser sign a new timelocked reclamation transaction, then sign a transaction moving from the old advertisement to the new advertisement (presumably there is some protocol for ensuring the advertiser gets paid for this, such as an HTLC that can be triggered by an onchain payment or by an LN payment; I have the details in my processing space but require some time to serialize to human-readabe format).
>
> Arguably, this example seems to show that generalized covenants are not needed in fact, if transfers of coin require paying to the issuer/lender of the coin.
> Generalized covenants allows the provider (or ticket-holder in your example) to effect transfers from one advertisement to another (or one ticket-holder to another in your example) without cooperation with the advertiser (or ticket-issuer in your example).
> This would be otherwise needed if we lock using a 2-of-2 address that has a timelocked transaction to reclaim the funds.

Yes, your example does not need the covenant as the one who gave up temporary control is still involved in any motion of the UTXO, therefore able to enforce own interest that reclaiming the UTXOs remains possible.

A covenant is needed only if it is against the interest of all parties involved in transfers of the UTXO, in which case consensus must enforce that it is carried forward.
The added strength of the covenant is that the one who gives up temporary control does not have to be involved in using the UTXO until it is given back.

Note that the advertizing service provider would need temporary access to UTXOs of signficant value, so opportunity cost and thereby cost of advertizing becomes significant.
Covenants would allow the separation of the advertizing service from HODLer funding it with significant UTXOs.
HODLer could give temporary control to the service and the service could broker those to others, but the original HODLer was sure to receive the UTXOs back and the HODLer would not be bothered with the operation of the service.

The covenant I proposed would add an alternate taproot validation path stacked onto previously existing ones.
This means that one could give others temporary access for a shorter time period than one’s own temporary access.
One could however not override the delayed access secured for the HODLer.

Does this remind you of something? Yes, the service provider would act like a bank, matching depositor, the HODLer, with those who need temporary control of UTXO for advertizing purposes.
This shows why temporary control with covenant can be understood as loan in a full reserve banking, which started my exploration of this topic.

Current technical means do not allow trustless and hands-off coordination of provider of UTXOs (that is capital) with provider of arbitary services that monetize the use of Bitcoin’s unforgable registry.
In other words we need covenants to enable Bitcoin applications to trustlessly and flexibly deal with foreign capital.

One other thing the consensus would have to ensure is that inputs with covenants are merged only into outputs with same covenant.
Which makes UTXOs with a particular covenants obey rules earlier known for colored coins and transactions moving it form a distinct embedded chain.
Adding same covenant establishes fungible coinbases of same embedded chain and dropping the covenant makes them again fungible with common UTXOs.

I could not be more excited of what boost this could give to the Bitcoin economy, unlocking the use of its unforgeable registry to track any asset with the same security guarantees it offers for its own cash token.

Best to you,

Tamas Blummer

>
> Regards,
> ZmnSCPxj

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190702/4f51afba/attachment.sig>;

📅 Original date posted:2019-07-02 📝 Original message:Hello ...

2023-06-07T20:19:04+02:00

In reply to nevent1q…najv
_________________________

📅 Original date posted:2019-07-02
📝 Original message:Hello ZmnSCPxj,

> On Jul 2, 2019, at 10:12, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> As a counterargument, I observe that committing to the advertisement on the UTXO is similar to committing to a SCRIPT on a UTXO.
> And I observe the Graftroot idea, wherein we commit to a public key on the UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that unlocks the UTXO for spending.
>
> By analogy, in my "advertising" scheme, instead of committing the advertisement on the UTXO, I can instead commit a public key (for example, the hash of the "advertiser pubkey" is used to tweak the onchain public key).
> Then we use this advertiser pubkey to admit advertisements on the advertising network.
>
> This advertiser pubkey is used to sign an "advertisement chain", which is a merklized singly-linked list whose contents are the actual advertisements, each node being signed using the advertiser pubkey.
> To ensure that the advertiser does not sign multiple versions of this chain, we can have the signing nonce be derived from the height of the advertchain, such that signing the same height multiple times leads to private key revelation.

The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
This is not the trustless separation the covenant achives.

Regards,

Tamas Blummer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190702/8a8984f5/attachment-0001.sig>;

📅 Original date posted:2019-06-28 📝 Original message:Hi ...

2023-06-07T20:18:55+02:00

In reply to nevent1q…lzhc
_________________________

📅 Original date posted:2019-06-28
📝 Original message:Hi Eric,

Thank you for your questions as they show what concepts need further explanation, so you understand the potential of this proposal and how it is helpful to the ecosystem.

Riskless zero bond is in fact the most basic concept of financial engineering. Yes, there are engineers of finance, those who create and price financial derivatives (e.g. options, swaps) and structure products such as e.g. ABS, CDO etc.
I used to be one of them.

A zero bond formalizes the observation that 1 unit of currency in the future has different value than 1 unit available now. It is called riskless if it is certain to receive the payment in the future.
If we put this difference of vaue in relation to the amount then we get the “risk freee rate of return”, that you heard of.

E.g if one is willing to exchange 1 BTC unconditionally available now for 1.1 BTC certainly available in a year but not earlier, then the implied “risk free rate of return” is apparently 10% pa. for Bitcoins.

The transaction I construct in the first example achives exactly this, because:

Bob forgoes his ability to use his unconditionally available coins by giving them to Alice with a covenant that ensures that Bob will receive them back later.
Bob does this because Alice pays for this in advance.

Alice can further transfer the coins encumbered by the covenant, but they will unconditionally return to Bob in the future.

The utility of these encumbered coins is that they prove that the loan is fully covered by reserves.

How valuable this utility is will be decided by the market and that value will be interest received by those who temporarily give up control. I am guess the value will be low but positive.

Lending does not mandate fractional or full reserves. These are choices the market or regulators enforce. Full reserve banking is not a fiction but is how things worked before introduction of gold receipts. A bank could only lend gold coins it possesed. Perils of fractional reserve were felt repeatedly by the Bitcoin ecnomy e.g. in the collaps of MtGox.

The idea to return to full reserve banking is not unique to gold bugs or Bitcoin but recently a popular vote was initiated in Switzerland to force Swiss banks to full reserves with respect to lending. This popular vote achived 24% support [1] which is quite remarkable if considered that the topic is not trivial as also our exchange shows.

I published today a writing in medium, that explains the concept of fractional vs. full reserve banking in conjunction with this proposal. Please read: https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479 <https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479>;

I would welcome feedback on the generalized covenant construct or its implementation, as I think it can open up much more uses than the few examples I gave.

Tamas Blummer

[1] Vollgeld Initiative: https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html <https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html>;
> On Jun 28, 2019, at 19:25, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi Tamas,
>
> There are a number of economic assumptions contained herein. While I understand you would like to focus on implementation, the worst bugs are requirements bugs. IMO these should be addressed first. I’ve addressed some possible issues inline.
>
>> On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> I start with a formalisation of loans as common in finance:
>>
>> A zero bond is a contract between two parties Alice and Bob whereby Alice receives an amount less than P and has to pay back P at a later time point called maturity.
>> The difference between the amount received and P is the interest implied by the contract. E.g. receiving 1 Bitcoin (<P) and agree to pay back 1.1 (=P) in a year is the same as getting a loan with 10% p.a. interest.
>>
>> The inherent risk in the contract is that Alice may not honor the agreement or be bankrupt by then.
>>
>> If we could programmatically guarantee that Alice honors the contract then we would be able to create a riskless zero bond, the fundation of financial engineering.
>
> I’m not aware of the basis of this statement. While people use the term “risk free rate of return” there has never actually been such a thing. It’s not clear to me how a unicorn has been the foundation of “financial engineering”, but I’m not also clear and what is intended by “engineering” in this sense. Generally engineering is the implementation of higher level concepts. It is those concepts that constitute requirements here.
>
> At a minimum, interest cannot be guaranteed by this proposal, which implies that at best it guarantees, setting aside changes in purchasing power, a return of principle minus economic interest on that principle (ie opportunity cost). Given that purchasing power changes over time, risk increases with the term of the loan. As such this is not riskless - both volatility and opportunity cost remain as risks.
>
>> A systemic problem with loans is that the lender might operate on fractional reserve, that is lending more than his capital.
>
> This is not a systemic problem, this is the very nature of lending. Fractional reserve is simply a state banking term used to describe the fact that people invest (lend) a fraction of their savings and hoard the rest. It matters not that banks or individuals do this, credit expansion is inherent in economy. Without it there is no investment and therefore no production whatsoever.
>
>> Unchecked inflation of money supply through fractional reserve is creating a mess in the world we live in. Bitcoin could overcome this mess implementing this proposal!
>
> You seem to be conflating state banking with the effects of investing. Taxpayer support for bank investment creates both a moral hazard (and the resulting misallocation of capital to state-favored projects, creating the famed economic “business cycle”) and is a manifestation of persistent monetary inflation (ie seigniorage is a source taxation. Investment implies credit expansion, and the level of this expansion is controlled by time preference alone.
>
>> I stop here with finance speak as the purpose of this mail is not to dive into finance, but to show how loans with full reserve check could be implemented in Bitcoin.
>>
>> 1. Receiving the loan is a payment from Bob to Alice, but we need a restriction how Alice can use the funds, so Bob can get them back unconditionally at maturity, so lending is riskless to him.
>> 2. Bob wants to receive interest, since he gives up his control of the coins until maturity, he can not use them elsewhere until then. That interest could be paid in advance, this can be solved with Bitcoin as is.
>
> Interest cannot be paid in advance. This implies nothing more than a smaller amount of principle.
>
>> How do we allow Alice to use the coins, that is: split/merge and transfer them to others, but still ensure Bob can claim them back at maturity?
>>
>> We ensure that Alice can only send the coins to outputs that inherit a taproot path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity
>>
>> This requires a generalization of the Bitcoin Covenants Idea[1] such that it nicely fits with taproot as follows:
>>
>> 1. A covenant in the form of '_ covenant C’ on output means that it can be spent to an output that maches the covenant pattern with placeholder _ and the output(s) will be assigned 'covenant C'.
>> 2. A covenant that mandates an output script with alternate validation paths can also assign alternate covernants to be inherited by the output(s) depending on which path was used to spend the input eg. 'covenant or(c covenant C, d covernant D)’
>> 3. The resulting covenant of outputs should be reduced following boolean algebra, e.g. or(b,or(b,a)) to or(b, a)
>> 4. express transitivity with 'covenant transitive’ which means the output will have the same covenant as the input
>> 5. allow to omit covenant on the output with 'covenant drop'
>>
>> The covenant Bob would assign to the loan output sent to Alice is: 'covenant or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
>> - Alice can send to an output script where she is free to chose the embedded script at the placeholder _ and that output will again have the same covenant as the input.
>> - After maturity Bob can claim any coin that is transitively rooted in the loan (more on this later) and the covenant will no longer be assigned to his new output(s).
>>
>> Assuming Alice wants to send some of the borrowed coins to Charlie:
>>
>> for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the script that gives Bob control after maturity.
>>
>> Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) covenant transitive)
>> Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) covenant transitive) is a promissory note issued by Alice to Charlie, here is why:
>>
>> If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he trusts, that Alice will offer a regular payment in exchange for it before maturity, since that output is worthless to Charlie after maturity as Bob can just take it.
>>
>> It seems at the first sight that there is no value in these outputs for Charlie, since he still has to ensure Alice replaces them before maturity.
>>
>> The value of these outputs to Charlie is the proof that he has exclusive control of the coins until maturity.
>
> At a minimum, money that predictably depreciates (to zero in this case) must be discounted accordingly. How much is money worth today that is worth zero tomorrow? This can be observed with both inflation and demurrage money. This also implies that each encumbered coin is not fungible with any other of a distinct discount schedule.
>
> What is the economic consequence of lending discounted money? Lower interest rates. How much lower? The rate of depreciation. This can also be observed with inflation and demurrage, but observation isn’t required. This is a necessary outcome.
>
> So when one lends 1 demurrage coin for a term one cannot earn interest on 1 coin, one is earning interest on a fraction of a coin. That fraction creates credit expansion and reduces return in direct proportion to the risk that has been offset. In other words, the risk cost has been converted to opportunity cost. The discounted fraction earns no interest.
>
> So credit expansion and risk remain, in the same proportions as without such a system. However lack of fungibility introduces an additional overhead cost.
>
> e
>
>> Alice can not issue promissory notes in excess of own capital or capital that she was able to borrow. No coin inflation or fractional reserve here, which also reduces the credit risk Charlie takes.
>>
>> Due to the transitive covenant Charlie could pass on the coins to an other temporary owner until maturity when Bob would re-collect them unconditionally.
>>
>> Should Charlie no longer be comfortable with Alice’s promise or need final coins (cash) immediatelly, then he could turn to Dan and do a re-purchase (repo) agreement with him.
>>
>> Charlie would receive final coins from Dan in exchange for the temporarily controled coins and Charlie's promise to replace them with final coins before maturity.
>> Dan would thereby charge high interest through a discount since as he has to bear the credit risk of Charlie. This is not a riskless but a plain zero bond.
>>
>> Why would Dan want to take temporary control of the coins at all? Again, to ensure Charlie is not doing yet another repo with Frank on the same coins, the sum of Charlie's repo deals are not in excess of his claims against others.
>> This again avoids lending in excess of coin supply and reduces the credit risk Dan takes.
>>
>> Here are the sketches for the transacions for above alternate actions:
>>
>> lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)’
>>
>> the transactions offer a fee of 0.0001
>>
>> Bob gives a riskless credit to Alice:
>>
>> Input Output
>> 1 pk(Bob) 1 or(b,pk(Alice) covenant c)
>> 0.1 pk(Alice) 0.9999 pk(Bob)
>>
>> Alice could send a 0.5 promissory note to Charlie:
>>
>> Input Output
>> 1 or(pk(Alice) covenant c) 0.5 or(b,pk(Charlie) covenant c)
>> 1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
>> 0.9999 pk(Alice)
>>
>> Alice could make good of the note before maturity, pay some interest and get back temporary control of the coins with:
>> Input Output
>> 0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Alice) covenant c)
>> 0.5101 pk(Alice) 0.51 pk(Charlie)
>>
>> alternatively Charlie borrows from Dan at high interest:
>>
>> Input Output
>> 0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Dan) covenant c)
>> 0.3001 pk(Dan) 0.3 pk(Charlie)
>>
>> and Charlie re-purchases the temporary coins before maturity, making good of the repo with Dan:
>>
>> Input Output
>> 0.5 or(b,pk(Dan) covenant c) 0.5 or(b,pk(Charlie) covenant c)
>> 0.5001 pk(Charlie) 0.5 pk(Dan)
>>
>> We need to define further transaction level validations for transactions spending inputs with covenants as follows:
>>
>> 1. If there are inputs without covenant before the input with covenant than inputs without covenant must be spent exactly with outputs preceeding the outputs with covenants.
>> 2. A transaction can have inputs with different covenants, their allocation to outputs should follow input order.
>> 3. For output(s) that share input(s) with covenant, the sum of covenant outputs must exactly add up to the input(s). This allows merging and splitting them.
>>
>> Bob would re-collect his coins at maturity unconditionally. Who followed through promises or defaulted down the transitive chain is irrelevant to him.
>> Remark: we might also need a covenant attribute defining the minimum size of output, so Bob is not forced to collect dust, which would be expensive or even impossible. I am not yet happy with this solution, looking for better.
>>
>> I am very excited about the possibilities this proposal would unlock and ask you verify usefulness of this scheme and join working out the details and how covenants would be integrated with taproot.
>>
>> Tamas Blummer
>>
>> [1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Covenants. URL: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
>> _______________________________________________
>> 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 <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/b6aef1d2/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/b6aef1d2/attachment-0001.sig>;

📅 Original date posted:2019-06-28 📝 Original message:I ...

2023-06-07T20:18:54+02:00

In reply to nevent1q…5cr9
_________________________

📅 Original date posted:2019-06-28
📝 Original message:I start with a formalisation of loans as common in finance:

A zero bond is a contract between two parties Alice and Bob whereby Alice receives an amount less than P and has to pay back P at a later time point called maturity.
The difference between the amount received and P is the interest implied by the contract. E.g. receiving 1 Bitcoin (<P) and agree to pay back 1.1 (=P) in a year is the same as getting a loan with 10% p.a. interest.

The inherent risk in the contract is that Alice may not honor the agreement or be bankrupt by then.

If we could programmatically guarantee that Alice honors the contract then we would be able to create a riskless zero bond, the fundation of financial engineering.

A systemic problem with loans is that the lender might operate on fractional reserve, that is lending more than his capital.

Unchecked inflation of money supply through fractional reserve is creating a mess in the world we live in. Bitcoin could overcome this mess implementing this proposal!

I stop here with finance speak as the purpose of this mail is not to dive into finance, but to show how loans with full reserve check could be implemented in Bitcoin.

1. Receiving the loan is a payment from Bob to Alice, but we need a restriction how Alice can use the funds, so Bob can get them back unconditionally at maturity, so lending is riskless to him.
2. Bob wants to receive interest, since he gives up his control of the coins until maturity, he can not use them elsewhere until then. That interest could be paid in advance, this can be solved with Bitcoin as is.

How do we allow Alice to use the coins, that is: split/merge and transfer them to others, but still ensure Bob can claim them back at maturity?

We ensure that Alice can only send the coins to outputs that inherit a taproot path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity

This requires a generalization of the Bitcoin Covenants Idea[1] such that it nicely fits with taproot as follows:

1. A covenant in the form of '_ covenant C’ on output means that it can be spent to an output that maches the covenant pattern with placeholder _ and the output(s) will be assigned 'covenant C'.
2. A covenant that mandates an output script with alternate validation paths can also assign alternate covernants to be inherited by the output(s) depending on which path was used to spend the input eg. 'covenant or(c covenant C, d covernant D)’
3. The resulting covenant of outputs should be reduced following boolean algebra, e.g. or(b,or(b,a)) to or(b, a)
4. express transitivity with 'covenant transitive’ which means the output will have the same covenant as the input
5. allow to omit covenant on the output with 'covenant drop'

The covenant Bob would assign to the loan output sent to Alice is: 'covenant or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
- Alice can send to an output script where she is free to chose the embedded script at the placeholder _ and that output will again have the same covenant as the input.
- After maturity Bob can claim any coin that is transitively rooted in the loan (more on this later) and the covenant will no longer be assigned to his new output(s).

Assuming Alice wants to send some of the borrowed coins to Charlie:

for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the script that gives Bob control after maturity.

Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) covenant transitive)
Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) covenant transitive) is a promissory note issued by Alice to Charlie, here is why:

If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he trusts, that Alice will offer a regular payment in exchange for it before maturity, since that output is worthless to Charlie after maturity as Bob can just take it.

It seems at the first sight that there is no value in these outputs for Charlie, since he still has to ensure Alice replaces them before maturity.

The value of these outputs to Charlie is the proof that he has exclusive control of the coins until maturity.
Alice can not issue promissory notes in excess of own capital or capital that she was able to borrow. No coin inflation or fractional reserve here, which also reduces the credit risk Charlie takes.

Due to the transitive covenant Charlie could pass on the coins to an other temporary owner until maturity when Bob would re-collect them unconditionally.

Should Charlie no longer be comfortable with Alice’s promise or need final coins (cash) immediatelly, then he could turn to Dan and do a re-purchase (repo) agreement with him.

Charlie would receive final coins from Dan in exchange for the temporarily controled coins and Charlie's promise to replace them with final coins before maturity.
Dan would thereby charge high interest through a discount since as he has to bear the credit risk of Charlie. This is not a riskless but a plain zero bond.

Why would Dan want to take temporary control of the coins at all? Again, to ensure Charlie is not doing yet another repo with Frank on the same coins, the sum of Charlie's repo deals are not in excess of his claims against others.
This again avoids lending in excess of coin supply and reduces the credit risk Dan takes.

Here are the sketches for the transacions for above alternate actions:

lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)’

the transactions offer a fee of 0.0001

Bob gives a riskless credit to Alice:

Input Output
1 pk(Bob) 1 or(b,pk(Alice) covenant c)
0.1 pk(Alice) 0.9999 pk(Bob)

Alice could send a 0.5 promissory note to Charlie:

Input Output
1 or(pk(Alice) covenant c) 0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
0.9999 pk(Alice)

Alice could make good of the note before maturity, pay some interest and get back temporary control of the coins with:
Input Output
0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Alice) covenant c)
0.5101 pk(Alice) 0.51 pk(Charlie)

alternatively Charlie borrows from Dan at high interest:

Input Output
0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Dan) covenant c)
0.3001 pk(Dan) 0.3 pk(Charlie)

and Charlie re-purchases the temporary coins before maturity, making good of the repo with Dan:

Input Output
0.5 or(b,pk(Dan) covenant c) 0.5 or(b,pk(Charlie) covenant c)
0.5001 pk(Charlie) 0.5 pk(Dan)

We need to define further transaction level validations for transactions spending inputs with covenants as follows:

1. If there are inputs without covenant before the input with covenant than inputs without covenant must be spent exactly with outputs preceeding the outputs with covenants.
2. A transaction can have inputs with different covenants, their allocation to outputs should follow input order.
3. For output(s) that share input(s) with covenant, the sum of covenant outputs must exactly add up to the input(s). This allows merging and splitting them.

Bob would re-collect his coins at maturity unconditionally. Who followed through promises or defaulted down the transitive chain is irrelevant to him.
Remark: we might also need a covenant attribute defining the minimum size of output, so Bob is not forced to collect dust, which would be expensive or even impossible. I am not yet happy with this solution, looking for better.

I am very excited about the possibilities this proposal would unlock and ask you verify usefulness of this scheme and join working out the details and how covenants would be integrated with taproot.

Tamas Blummer

[1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Covenants. URL: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/25fe4569/attachment-0001.sig>;

📅 Original date posted:2019-02-06 📝 Original message:Hi ...

2023-06-07T20:16:24+02:00

In reply to nevent1q…werx
_________________________

📅 Original date posted:2019-02-06
📝 Original message:Hi Laolu,

space savings come with the rather serious current disadvantage, that a light client is not
in the position to check the filter. Also the advanced uses you mention are subject to this, for now.
Building more on a shaky fundament does not make it look better.

Now that we have seen advantages of both filters, what keeps us from offering both by Core?

Computing the addional spent-outpoint output-script filter is cheaper than the current one as
it can be done with the block as only context, it does not need UTXO nor undo blocks no journals or
whatever else. I do not see how my statement regarding this was incorrect.

There is a political issue though, why I favor better provable uncommitted filter:

I am skeptical that commitment of any filter will come into Core soon.
The reason of my skepticism is political, not technical.

A committed filter makes light clients much more reliable and attractive, for some taste too much more.

Clients that follow PoW are not significant on the current network. Core nodes enforce many more rules,
some as important as miners' reward. A committed filter would strengthen light clients
significantly, such that perhabs too many were compelled using them instead of a Core node.
Would the remaining Core nodes be sufficient to enforce checks not covered? I see how this is a dilemma.

Is this a dilemma because we think black-white? Light(er) clients might implement checks that are more
than blind PoW trust even if less than all Core checks. Has the time come to allow for this?

Tamas Blummer

> On Feb 6, 2019, at 01:17, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Hi Tamas,
>
> > The only advantage I see in the current design choice is filter size, but
> > even that is less impressive in recent history and going forward, as address
> > re-use is much less frequent nowadays than it was Bitcoin’s early days.
>
> Gains aren't only had with address re-use, it's also the case that if an
> input is spent in the same block as it was created, then only a single items
> is inserted into the filter. Filters spanning across several blocks would
> also see savings due to the usage of input scripts.
>
> Another advantage of using input scripts is that it allows rescans where all
> keys are known ahead of time to proceed in parallel, which can serve to
> greatly speed up rescans in bitcoind. Additionally, it allows light clients
> to participate in protocols like atomic swaps using the input scripts as
> triggers for state transitions. If outpoints were used, then the party that
> initiated the swap would need to send the cooperating party all possible
> txid's that may be generated due to fee bumps (RBF or sighash single
> tricks). Using the script, the light client simply waits for it to be
> revealed in a block (P2WSH) and then it can carry on the protocol.
>
> > Clear advantages of moving to spent outpoint + output script filter:
>
> > 1. Filter correctness can be proven by downloading the block in question only.
>
> Yep, as is they can verify half the filter. With auxiliary data, they can
> verify the entire thing. Once committed, they don't need to verify at all.
> We're repeating a discussion that played out 7 months ago with no new
> information or context.
>
> > 2. Calculation of the filter on server side does not need UTXO.
>
> This is incorrect. Filter calculation can use the spentness journal (or undo
> blocks) that many full node implementations utilize.
>
> > This certainly improves with a commitment, but that is not even on the
> > roadmap yet, or is it?
>
> I don't really know of any sort of roadmaps in Bitcoin development. However,
> I think there's relatively strong support to adding a commitment, once the
> current protocol gets more usage in the wild, which it already is today on
> mainnet.
>
> > Should a filter be committed that contains spent outpoints, then such
> > filter would be even more useful
>
> Indeed, this can be added as a new filter type, optionally adding created
> outpoints as you referenced in your prior email.
>
> > Since Bitcoin Core is not yet serving any filters, I do not think this
> > discussion is too late.
>
> See my reply to Matt on the current state of deployment. It's also the case
> that bitcoind isn't the only full node implementation used in the wild.
> Further changes would also serve to delay inclusion into bitcoind. The
> individuals proposing these PRs to bitcoind has participated in this
> discussion 7 months ago (along with many of the contributors to this
> project). Based in this conversation 7 months ago, it's my understanding
> that all parties are aware of the options and tradeoffs to be had.
>
> -- Laolu
>
>
> On Tue, Feb 5, 2019 at 12:10 PM Tamas Blummer <tamas.blummer at gmail.com> wrote:
> Hi Laolu,
>
> The only advantage I see in the current design choice is filter size, but even that is less
> impressive in recent history and going forward, as address re-use is much less frequent nowadays
> than it was Bitcoin’s early days.
>
> I calculated total filter sizes since block 500,000:
>
> input script + output script (current BIP): 1.09 GB
> spent outpoint + output script: 1.26 GB
>
> Both filters are equally useful for a wallet to discover relevant transactions, but the current design
> choice seriously limits, practically disables a light client, to prove that the filter is correct.
>
> Clear advantages of moving to spent outpoint + output script filter:
>
> 1. Filter correctness can be proven by downloading the block in question only.
> 2. Calculation of the filter on server side does not need UTXO.
> 3. Spent outpoints in the filter enable light clients to do further probabilistic checks and even more if committed.
>
> The current design choice offers lower security than now attainable. This certainly improves with
> a commitment, but that is not even on the roadmap yet, or is it?
>
> Should a filter be committed that contains spent outpoints, then such filter would be even more useful:
> A client could decide on availability of spent coins of a transaction without maintaining the UTXO set, by
> checking the filters if the coin was spent after its origin proven in an SPV manner, evtl. eliminating false positives
> with a block download. This would be slower than having UTXO but require only immutable store, no unwinds and
> only download of a few blocks.
>
> Since Bitcoin Core is not yet serving any filters, I do not think this discussion is too late.
>
> Tamas Blummer
>
>
> > On Feb 5, 2019, at 02:42, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> >
> > Hi Tamas,
> >
> > This is how the filter worked before the switch over to optimize for a
> > filter containing the minimal items needed for a regular wallet to function.
> > When this was proposed, I had already implemented the entire proposal from
> > wallet to full-node. At that point, we all more or less decided that the
> > space savings (along with intra-block compression) were worthwhile, we
> > weren't cutting off any anticipated application level use cases (at that
> > point we had already comprehensively integrated both filters into lnd), and
> > that once committed the security loss would disappear.
> >
> > I think it's too late into the current deployment of the BIPs to change
> > things around yet again. Instead, the BIP already has measures in place for
> > adding _new_ filter types in the future. This along with a few other filter
> > types may be worthwhile additions as new filter types.
> >
> > -- Laolu
> >
> > On Mon, Feb 4, 2019 at 12:59 PM Tamas Blummer <tamas.blummer at gmail.com> wrote:
> > I participated in that discussion in 2018, but have not had the insight gathered by now though writing both client and server implementation of BIP157/158
> >
> > Pieter Wuille considered the design choice I am now suggesting here as alternative (a) in: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html
> > In his evaluation he recognized that a filter having spent output and output scripts would allow decision on filter correctness by knowing the block only.
> > He did not evaluate the usefulness in the context of checkpoints, which I think are an important shortcut here.
> >
> > Yes, a filter that is collecting input and output scripts is shorter if script re-use is frequent, but I showed back in 2018 in the same thread that this saving is not that significant in recent history as address reuse is no longer that frequent.
> >
> > A filter on spent outpoint is just as useful for wallets as is one on spent script, since they naturally scan the blockchain forward and thereby learn about their coins by the output script before they need to check spends of those outpoints.
> >
> > It seems to me that implementing an interrogation by evtl. downloading blocks at checkpoints is much simpler than following multiple possible filter paths.
> >
> > A spent outpoint filter allows us to decide on coin availability based on immutable store, without updated and eventually rolled back UTXO store. The availability could be decided by following the filter path to current tip to genesis and
> > check is the outpoint was spent earlier. False positives can be sorted out with a block download. Murmel implements this if running in server mode, where blocks are already there.
> >
> > Therefore I ask for a BIP change based on better insight gained through implementation.
> >
> > Tamas Blummer
> >
> >> On Feb 4, 2019, at 21:18, Jim Posen <jim.posen at gmail.com> wrote:
> >>
> >> Please see the thread "BIP 158 Flexibility and Filter Size" from 2018 regarding the decision to remove outpoints from the filter [1].
> >>
> >> Thanks for bringing this up though, because more discussion is needed on the client protocol given that clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner (due to the inclusion of input scripts).
> >>
> >> I see three possibilities:
> >> 1) Introduce a new P2P message to retrieve all prev-outputs for a given block (essentially the undo data in Core), and verify the scripts against the block by executing them. While this permits some forms of input script malleability (and thus cannot discriminate between all valid and invalid filters), it restricts what an attacker can do. This was proposed by Laolu AFAIK, and I believe this is how btcd is proceeding.
> >> 2) Clients track multiple possible filter header chains and essentially consider the union of their matches. So if any filter received for a particular block header matches, the client downloads the block. The client can ban a peer if they 1) ever return a filter omitting some data that is observed in the downloaded block, 2) repeatedly serve filters that trigger false positive block downloads where such a number of false positives is statistically unlikely, or 3) repeatedly serves filters that are significantly larger than the expected size (essentially padding the actual filters with garbage to waste bandwidth). I have not done the analysis yet, but we should be able to come up with some fairly simple banning heuristics using Chernoff bounds. The main downside is that the client logic to track multiple possible filter chains and filters per block is more complex and bandwidth increases if connected to a malicious server. I first heard about this idea from David Harding.
> >> 3) Rush straight to committing the filters into the chain (via witness reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 157 P2P mode.
> >>
> >> I'm in favor of option #2 despite the downsides since it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written. (Though the recommended client protocol in the BIP needs to be updated to account for this). Another benefit of it is that it removes some synchronicity assumptions where a peer with the correct filters keeps timing out and is assumed to be dishonest, while the dishonest peer is assumed to be OK because it is responsive.
> >>
> >> If anyone has other ideas, I'd love to hear them.
> >>
> >> -jimpo
> >>
> >> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html
> >>
> >>
> >>
> >> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> TLDR: a change to BIP158 would allow decision on which filter chain is correct at lower bandwith use
> >>
> >> Assume there is a BIP157 client that learned a filter header chain earlier and is now offered an alternate reality by a newly connected BIP157 server.
> >>
> >> The client notices the alternate reality by routinely asking for filter chain checkpoints after connecting to a new BIP157 server. A divergence at a checkpoint means that the server disagrees the client's history at or before the first diverging checkpoint. The client would then request the filter headers between the last matching and first divergent checkpoint, and quickly figure which block’s filter is the first that does not match previous assumption, and request that filter from the server.
> >>
> >> The client downloads the corresponding block, checks that its header fits the PoW secured best header chain, re-calculates merkle root of its transaction list to know that it is complete and queries the filter to see if every output script of every transaction is contained in there, if not the server is lying, the case is closed, the server disconnected.
> >>
> >> Having all output scripts in the filter does not however guarantee that the filter is correct since it might omit input scripts. Inputs scripts are not part of the downloaded block, but are in some blocks before that. Checking those are out of reach for lightweight client with tools given by the current BIP.
> >>
> >> A remedy here would be an other filter chain on created and spent outpoints as is implemented currently by Murmel. The outpoint filter chain must offer a match for every spent output of the block with the divergent filter, otherwise the interrogated server is lying since a PoW secured block can not spend coins out of nowhere. Doing this check would already force the client to download the outpoint filter history up-to the point of divergence. Then the client would have to download and PoW check every block that shows a match in outpoints until it figures that one of the spent outputs has a script that was not in the server’s filter, in which case the server is lying. If everything checks out then the previous assumption on filter history was incorrect and should be replaced by the history offered by the interrogated server.
> >>
> >> As you see the interrogation works with this added filter but is highly ineffective. A really light client should not be forced to download lots of blocks just to uncover a lying filter server. This would actually be an easy DoS on light BIP157 clients.
> >>
> >> A better solution is a change to BIP158 such that the only filter contains created scripts and spent outpoints. It appears to me that this would serve well both wallets and interrogation of filter servers well:
> >>
> >> Wallets would recognize payments to their addresses by the filter as output scripts are included, spends from the wallet would be recognized as a wallet already knows outpoints of its previously received coins, so it can query the filters for them.
> >>
> >> Interrogation of a filter server also simplifies, since the filter of the block can be checked entirely against the contents of the same block. The decision on filter correctness does not require more bandwith then download of a block at the mismatching checkpoint. The client could only be forced at max. to download 1/1000 th of the blockchain in addition to the filter header history.
> >>
> >> Therefore I suggest to change BIP158 to have a base filter, defined as:
> >>
> >> A basic filter MUST contain exactly the following items for each transaction in a block:
> >> • Spent outpoints
> >> • The scriptPubKey of each output, aside from all OP_RETURN output scripts.
> >>
> >> Tamas Blummer
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

📅 Original date posted:2018-06-03 📝 Original ...

2023-06-07T20:12:43+02:00

In reply to nevent1q…u52n
_________________________

📅 Original date posted:2018-06-03
📝 Original message:Correction:
- Output script + spent script filters (Wuille’s (b)) have sizes of ca. 2% of block size.

Tamas Blummer

> On Jun 3, 2018, at 18:44, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>
> I processed bitcoin history assuming filters using with P=19 M=784931.
>
> Findings:
> - Output script + spent script filters (Wuille’s (b)) have sizes of ca. 0.2% of block size.
> - Output script + spent script filters (Wuille’s (b)) are ca. 10% smaller than output script + spent outpoint filters (Wuille's (a)). Savings here however trend lower since years.
>
> Graphs attached.
>
> Tamas Blummer
>
> <scriptfilter.png><scriptssaving.png>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/99540bb3/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/99540bb3/attachment-0001.sig>;

📅 Original date posted:2018-06-03 📝 Original ...

2023-06-07T20:12:39+02:00

In reply to nevent1q…2yxw
_________________________

📅 Original date posted:2018-06-03
📝 Original message:Lighter but SPV secure nodes (filter committed) would help the network (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW.

On longer term most users' security will be determined by either trusted hubs or POW.
I do not know which is worse, but we should at least offer the choice to the user, therefore commit filters.

Tamas Blummer

> On Jun 3, 2018, at 02:28, Gregory Maxwell <greg at xiph.org> wrote:
>
> pretty much us that all these filter things are a total waste of time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/0f5d908f/attachment.sig>;

📅 Original date posted:2018-06-03 📝 Original message:I ...

2023-06-07T20:12:39+02:00

In reply to nevent1q…qass
_________________________

📅 Original date posted:2018-06-03
📝 Original message:I processed bitcoin history assuming filters using with P=19 M=784931.

Findings:
- Output script + spent script filters (Wuille’s (b)) have sizes of ca. 0.2% of block size.
- Output script + spent script filters (Wuille’s (b)) are ca. 10% smaller than output script + spent outpoint filters (Wuille's (a)). Savings here however trend lower since years.

Graphs attached.

Tamas Blummer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scriptfilter.png
Type: image/png
Size: 55464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0002.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scriptssaving.png
Type: image/png
Size: 59097 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0003.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/02d00008/attachment-0001.sig>;

📅 Original date posted:2018-06-02 📝 Original ...

2023-06-07T20:12:38+02:00

In reply to nevent1q…vrh4
_________________________

📅 Original date posted:2018-06-02
📝 Original message:Without block commitment mobiles would have to use trusted filter provider or implement a complex data hungry algorithm and still remain as insecure as with BIP 37.

Years of experience implementing wallets with BIP 37 taught us that an outpoint + output script filter is useful. Committing such a filter to the block can not be an error.

We could roll this out on P2P prior to a soft fork adding the commitment, but I would not expect its use to pick up before that.
Therafter BIP 37 could be rightfully decommissioned, herby offering both security and privacy enhancement at modest data cost.

Tamas Blummer

> On Jun 2, 2018, at 14:41, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote:
>> Without the ability to verify filter validity, a client would have to stop
>> syncing altogether in the presence of just one malicious peer, which is
>> unacceptable.
>
> I'm confused about why this would be the case. If Alice's node
> generates filters accurately and Mallory's node generates filters
> inaccurately, and they both send their filters to Bob, won't Bob be able
> to download any blocks either filter indicates are relevant to his
> wallet?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180603/6623601b/attachment.sig>;

📅 Original date posted:2018-05-31 📝 Original message:I ...

2023-06-07T20:12:18+02:00

In reply to nevent1q…j96a
_________________________

📅 Original date posted:2018-05-31
📝 Original message:I processed the historic blockchain to create a single filter populated with spent input scripts and output scripts. The Golomb parameter was P=2^20

The resulting chart shows a volatile history of same-block address re-use with a notable drops in relative filter size during the early history and in the time window where SatoshiDICE was popular, since then trending higher.
The history of only the last half year suggests a current filter size of between 2.0% - 2.5% of block sizes.

Since most outputs are spent within a short time period, but apparently not that often in same blocks, I think it was worth considering filter series that match over a windows of 2^n blocks (n=(0…10)). Applications could then bracket the
range of interest and then narrow down requesting finer filters or blocks.

Then I created 1600 random (P2SH) scripts and totaled the false positive block download data size if observing 100, 200, 400, 800, 1600 of them.
The result suggests that even for 1600 the false positive overhead is less than 0.1% of blockchain data size.

I agree with Greg that we should optimize the parameters for a small observed set as those will be running on mobile devices.
As of Pieter’s findings the simulation parameters were optimal for ca. 1000 observed scripts which is maybe to many for a “small” application.
On the other hand we do not know the needs of future popular mobile applications.

With parameters of the simulation the current minimal data burden on a mobile wallet would be ca. 0.1 GB / Month.

Simulations with other parameters could be executed using this patch branch: https://github.com/tamasblummer/rust-bitcoin-spv/tree/blockfilterstats A run takes a few hours on a fast machine with release build and local bitcoind.
The calculation can not be reduced to the recent history as the process builds in-memory utxo from genesis.

The result of executing the binary is a CSV file containing:
blocknumber, blocksize, utxo size, filter size, false positive data size for 100, false positive data size for 100, … false positive data size for 100
e.g:
524994,1112181,57166825,21556,0,0,0,0,1112181

Tamas Blummer

> On May 29, 2018, at 06:01, Olaoluwa Osuntokun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > The additional benefit of the input script/outpoint filter is to watch for
> > unexpected spends (coins getting stolen or spent from another wallet) or
> > transactions without a unique change or output address. I think this is a
> > reasonable implementation, and it would be nice to be able to download that
> > filter without any input elements.
>
> As someone who's implemented a complete integration of the filtering
> technique into an existing wallet, and a higher application I disagree.
> There's not much gain to be had in splitting up the filters: it'll result in
> additional round trips (to fetch these distinct filter) during normal
> operation, complicate routine seed rescanning logic, and also is detrimental
> to privacy if one is fetching blocks from the same peer as they've
> downloaded the filters from.
>
> However, I'm now convinced that the savings had by including the prev output
> script (addr re-use and outputs spent in the same block as they're created)
> outweigh the additional booking keeping required in an implementation (when
> extracting the precise tx that matched) compared to using regular outpoint
> as we do currently. Combined with the recently proposed re-parametrization
> of the gcs parameters[1], the filter size should shrink by quite a bit!
>
> I'm very happy with the review the BIPs has been receiving as of late. It
> would've been nice to have this 1+ year ago when the draft was initially
> proposed, but better late that never!
>
> Based on this thread, [1], and discussions on various IRC channels, I plan
> to make the following modifications to the BIP:
>
> 1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the
> filter instance, so future filter types may use distinct parameters
> 2. use the prev output script rather than the prev input script in the
> regular filter
> 3. remove the txid from the regular filter(as with some extra book-keeping
> the output script is enough)
> 4. do away with the extended filter all together, as our original use case
> for it has been nerfed as the filter size grew too large when doing
> recursive parsing. instead we watch for the outpoint being spent and
> extract the pre-image from it if it matches now
>
> The resulting changes should slash the size of the filters, yet still ensure
> that they're useful enough for our target use case.
>
> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html
>
> -- Laolu
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filtersize.png
Type: image/png
Size: 58848 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0003.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lasthalfyear.png
Type: image/png
Size: 50431 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0004.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: falsepositive.png
Type: image/png
Size: 82663 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/34f94f8e/attachment-0005.png>;

📅 Original date posted:2018-05-28 📝 Original message:Hi ...

2023-06-07T20:12:16+02:00

In reply to nevent1q…vze4
_________________________

📅 Original date posted:2018-05-28
📝 Original message:Hi Jim,

A “basic” combined filter would mean up to 0.5 GB filter data per month (with 100% segwith use). Considering that 1 GB is the usual data quota for an entry level mobile phone contract, this could be a too high barrier for adoption.

I repeated your calculations and produced a slightly different graph that shows the fraction of cummulative filter size to cummulative blockchain size. This is less noisy but otherwise confirms your measurement.

I think that the data supports separation of filters as a combined filter does not seem to come with significant savings. (basic size ~= txid + input points + output scripts sizes)

My calculations are repeatable with:

https://github.com/tamasblummer/rust-bitcoin-spv/blob/blockfilterstats/src/bin/blockfilterstats.rs

that is using a Rust implementation of an SPV client built on top of other libraries we work on in the rust-bitcoin GitHub community (https://github.com/rust-bitcoin). Yes, this is a shameles plug for the project hoping to attract more developer.

Tamas Blummer

> On May 24, 2018, at 05:48, Jim Posen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Greg, I've attached a graph including the input scripts.
>
> In the top graph, we can see how the input script filter compares to the input outpoint filter. It is definitely smaller as a result of address reuse. The bottom graph shows the ratio over time of combining the input prev script and output script filters vs keeping them separate. In more recent blocks, it appears that there are decreasing savings.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180528/98939f0d/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filters.png
Type: image/png
Size: 69944 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180528/98939f0d/attachment-0001.png>;

📅 Original date posted:2015-08-16 📝 Original message:Being ...

2023-06-07T19:35:25+02:00

In reply to nevent1q…fs37
_________________________

📅 Original date posted:2015-08-16
📝 Original message:Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.

Tamas Blummer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/ffcc5a91/attachment.sig>;

📅 Original date posted:2015-08-22 📝 Original message:> ...

2023-06-07T17:48:47+02:00

In reply to nevent1q…985q
_________________________

📅 Original date posted:2015-08-22
📝 Original message:> On Aug 21, 2015, at 21:46, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at bitsofproof.com <mailto:tamas at bitsofproof.com>> wrote:
>> Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
>> but also open the chance of doing the work better, in the sense of software engineering.
>
> But you don't want something better, you want something functionally identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=764 <https://youtu.be/l3O4nh79CUU?t=764>;

I do want something better, but not for the focus you have.

Not because what you produce was not high quality, but because quality is achieved at a very
high cost and is hard to uphold over generations of developer. You focus on a single use case
while there are many out there for distributed ledgers.

I think in an infrastructure for enterprise applications, building consensus on the ledger is a
cornerstone there, but is only a piece of the solution. I built several commercially successful
deployments where I delegated the consensus building to a border router, a Bitcoin Core,
then interfaced that trusted peer with my implementation that accepted Core’s decisions
in an SPV manner. One might think of this setup as wasteful and unsuitable for “small devices”
therefore an example of centralization people here try to avoid.

Enterprises have sufficient resources. Solving the business problem is valuable to them even at
magnitudes higher cost than a hobbyist would bear.

For mainstream adoption you need to get enterprises on board too, and that is what I care of.
Enterprises want code that is not only high quality, but is easy to maintain with a development
team with high attrition. One has to take whatever help is offered for that, and one is modern
languages and runtimes.

Bits of Proof’s own implementation of the scripts was not practically relevant in my commercially
successful deployments, because of the use of a border router, but it helped development,
enabling easier debug and precise error feedback esp. end even after Core had a reject message.

I integrated libconsensus only for the hope that is significantly fastens application side tx verification,
which it has turned out it does not, until secp265k1 is integrated.

I would likely use an other extended libconsensus too, but do not think there was a dependency on
that for enterprise development.

It would help there more to have a slim protocol server, no wallet, no rpc, no qt but a high
performance remoting API.

> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to it.

Storage and validation is non-trivially interconnected, but I now the separation can be done,
since I did it.

Excuse me, but function pointers is a pattern I used in the 80’s. I know that they are behind
the curtain of modern abstractions with similar use, I still prefer not to see them again.

Tamas Blummer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c501d201/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c501d201/attachment-0001.sig>;

📅 Original date posted:2015-08-21 📝 Original ...

2023-06-07T17:48:46+02:00

In reply to nevent1q…zwgk
_________________________

📅 Original date posted:2015-08-21
📝 Original message:Thinking in Bitcoins only on the level of technology unnecessarily narrows your view.

OK, I hope to be pleasantly surprised.

Tamas Blummer

> On Aug 20, 2015, at 23:35, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
>
>
> On 08/20/15 21:26, Tamas Blummer wrote:
>> I know what you mean as I already have such a component with pluggable
>> block store and networking.
>
> I'm not suggesting pluggable networking, I'm suggesting (and I think
> everyone thinks the design should be) NO networking. The API is
> ValidationResult libconsensus.HeyIFoundABlock(Block) and
> ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
>
>> While you are at it you could aim for isolation of bitcoin specific
>> decisions and algos from generic block chain code.
>
> Are you suggesting to support altcoins? I dont think anyone cares about
> supporting that.
>
>> The magnitude of refactoring you would have to do to get there from
>> main.cpp and the rest of the hairball
>> is harder than a re-write from scratch,
>
> I think you'd be very pleasantly surprised. It sounds like you havent
> dug into Bitcoin Core validation code in years.
>
>> and the result will not be
>> impressive, just hopefully working.
>
> Hmm? The result would be an obviously correct consensus implementation
> that everyone could use, instead of everyone going off and writing their
> own and either being wrong, or never updating in the case of forks. Its
> a huge deal to allow people to focus on making their libraries have good
> APIs/Wallets/etc instead of focusing on making a working validation
> engine (though maybe for that the p2p layer needs to also be in a library).
>
>> I think a slim API server was a lower hanging fruit in Core’s case.
>
> We have one, it just needs a few already obvious performance improvements.
>
>> BTW, support for refactoring is an example where you see if your tool
>> set is modern.
>
> There are a number of good development tools for C++ that allow this....
>
>> Tamas Blummer
>>
>>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> I dont think a libconsensus would have any kind of networking layer, nor
>>> is C++ an antique tool set (hopefully libconsensus can avoid a boost
>>> dependency, though thats not antique either). Ideally it would have a
>>> simple API to give it blocks and a simple API for it to inform you of
>>> what the current chain is. If you really want to get fancy maybe it has
>>> pluggable block storage, too, but I dont see why you couldnt use this in
>>> ~any client?
>>>
>>> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
>>>> Every re-implementation, re-factoring even copy-paste introduces a
>>>> risk of disagreement,
>>>> but also open the chance of doing the work better, in the sense of
>>>> software engineering.
>>>>
>>>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc
>>>>> <mailto:jtimon at jtimon.cc>> wrote:
>>>>>
>>>>>
>>>>> But the goal is not reimplementing the consensus rules but rather
>>>>> extract them from Bitcoin Core so that nobody needs to re-implement
>>>>> them again.
>>>>
>>>>
>>>>
>>>> My goal is different. Compatibility with Bitcoin is important as I
>>>> also want to deal with Bitcoins,
>>>> but it is also imperative to be able to create and serve other block
>>>> chains with other rules and for those
>>>> I do not want to carry on the legacy of an antique tool set and a
>>>> spaghetti style.
>>>>
>>>> Bits of Proof uses scala (akka networking), java (api service), c++
>>>> (leveledb and now libconsensus)
>>>> and I am eager to integrate secp256k1 (c) as soon as part of
>>>> consensus. The choices were
>>>> made because each piece appears best in what they do.
>>>>
>>>> Tamas Blummer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20150821/9b8a4eb3/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/9b8a4eb3/attachment.sig>;

📅 Original date posted:2015-08-20 📝 Original message:Every ...

2023-06-07T17:48:45+02:00

In reply to nevent1q…gkem
_________________________

📅 Original date posted:2015-08-20
📝 Original message:Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
but also open the chance of doing the work better, in the sense of software engineering.

> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> But the goal is not reimplementing the consensus rules but rather
> extract them from Bitcoin Core so that nobody needs to re-implement
> them again.

My goal is different. Compatibility with Bitcoin is important as I also want to deal with Bitcoins,
but it is also imperative to be able to create and serve other block chains with other rules and for those
I do not want to carry on the legacy of an antique tool set and a spaghetti style.

Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb and now libconsensus)
and I am eager to integrate secp256k1 (c) as soon as part of consensus. The choices were
made because each piece appears best in what they do.

Tamas Blummer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/ea9ba04d/attachment.sig>;

📅 Original date posted:2015-08-20 📝 Original message:I know ...

2023-06-07T17:48:45+02:00

In reply to nevent1q…jqvm
_________________________

📅 Original date posted:2015-08-20
📝 Original message:I know what you mean as I already have such a component with pluggable block store and networking.
While you are at it you could aim for isolation of bitcoin specific decisions and algos from generic block chain code.

The magnitude of refactoring you would have to do to get there from main.cpp and the rest of the hairball
is harder than a re-write from scratch, and the result will not be impressive, just hopefully working.
I think a slim API server was a lower hanging fruit in Core’s case.

BTW, support for refactoring is an example where you see if your tool set is modern.

Tamas Blummer

> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I dont think a libconsensus would have any kind of networking layer, nor
> is C++ an antique tool set (hopefully libconsensus can avoid a boost
> dependency, though thats not antique either). Ideally it would have a
> simple API to give it blocks and a simple API for it to inform you of
> what the current chain is. If you really want to get fancy maybe it has
> pluggable block storage, too, but I dont see why you couldnt use this in
> ~any client?
>
> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
>> Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement,
>> but also open the chance of doing the work better, in the sense of software engineering.
>>
>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc> wrote:
>>>
>>>
>>> But the goal is not reimplementing the consensus rules but rather
>>> extract them from Bitcoin Core so that nobody needs to re-implement
>>> them again.
>>
>>
>>
>> My goal is different. Compatibility with Bitcoin is important as I also want to deal with Bitcoins,
>> but it is also imperative to be able to create and serve other block chains with other rules and for those
>> I do not want to carry on the legacy of an antique tool set and a spaghetti style.
>>
>> Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb and now libconsensus)
>> and I am eager to integrate secp256k1 (c) as soon as part of consensus. The choices were
>> made because each piece appears best in what they do.
>>
>> Tamas Blummer
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.sig>;

📅 Original date posted:2015-08-20 📝 Original message:Jorge, ...

2023-06-07T17:48:44+02:00

In reply to nevent1q…dvyt
_________________________

📅 Original date posted:2015-08-20
📝 Original message:Jorge,

separating script engine into libconsensus was very helpful, since wrapped the piece of consensus
that would least likely to be captured exactly with an implementation from scratch. Thank you for your
effort there. Bits of Proof now uses its own or alternatively libconsensus for full validation.

I am sceptical however that a “full” consensus lib extracted from satoshi’s code is worth trying.
Not because it was impossible, but because the result would not be higher quality, if measured on agreement
with satoshi, than other re-implementations. It would actually be lower quality because of the antique tool set.

The rules outside script engine are simpler, therefore much easier to capture exactly. They are however
scattered around in the spaghetti and are often just a single if statement, also repeated elsewhere.

You would either have to very extensively refactor the code, that unlikely goes through as a PR, or
do what me and others did. Read satoshi code and rewrite the same. You have
a slight advantage of copy-paste small fragments, but I doubt the consensus relevant advantage of that.

Tamas Blummer

> On Aug 20, 2015, at 02:53, Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> 1) Finish the libconsensus separation in an independent branch on top
> of a given version, for example 0.11.
> 2) Separate a repository from that. Alternative implementations can
> start using a full libconsensus
> 3) Rebase that branch on top of bitcoin/master and start to PR small
> groups of commits. Once the whole branch has been merged, Bitcoin Core
> can replace the consensus folder with the libconsensus subtree, so
> that Bitcoin Core itself can start using a full libconsensus.
>
> Ironically with this plan Bitcoin Core may not be the full node first
> implementation to use a full libconsensus.
> There will be some consensus fork bug risks during 3 (which at the
> current speed I estimate it could easily take 3 or 4 years) and there
> would be some redundant work (replicating every consensus change in
> both Bitcoin Core and libconsensus).
> On the bright side, we may be able to have a full libconsensus this
> year (which was my goal after we exposed VerifyScript in the first
> libconsensus).
>
> Thoughts?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/fc405c9e/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/fc405c9e/attachment-0001.sig>;

📅 Original date posted:2015-08-16 📝 Original message:Being ...

2023-06-07T17:47:13+02:00

In reply to nevent1q…vnj7
_________________________

📅 Original date posted:2015-08-16
📝 Original message:Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.

Tamas Blummer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/ffcc5a91/attachment.sig>;

📅 Original date posted:2015-08-18 📝 Original message:Thanks ...

2023-06-07T17:46:59+02:00

In reply to nevent1q…s2fl
_________________________

📅 Original date posted:2015-08-18
📝 Original message:Thanks a lot Cory for following through the test case and producing a patch.

I confirm that libconsensus is now running stable within the Bits of Proof stack,
in-line with test cases we use to verify the java implementation of the script engine,
that are BTW borrowed from Bitcoin Core.

The performance of libconsensus is surprisingly close to the java one.
Validating a 2-of-2 a multi-sig transaction runs at 1021 ops/sec with java and 1135 ops/sec
in libconsensus. This is on a 2.2GH i7 laptop (4 hyper threading cores used by 8 threads).
Another nice demonstration why one should not trade in advances
of languages for the last decades for a marginal gain of performance with C/C++,
I assume thereby that Bouncy Castle’ EC lib s not superior to OpenSSL's.

I disagree that the problem was rare in the real-world, it should affect any modern
implementation that validates transactions parallel in multiple threads.

Aborting also does not make the problem less severe in my opinion.
Therefore hope the pull will be included into Core with next release.

I can’t assign a timeline to “near future" secp256k1 integration. Can you?

Tamas Blummer

> On Aug 18, 2015, at 07:03, Cory Fields <lists at coryfields.com> wrote:
>
> Back to the list (from github) in case anyone finds this via Google.
>
> The patch that I posted here a few days ago did not fix the issue for Tamas.
>
> I spent some time tracking down this edge-case because
> libbitcoinconsensus needs to be as bullet-proof as possible. Thanks to
> Tamas for creating a bare-bones test case after some discussion.
>
> I finally managed to reproduce the issue on OSX. It's subtle and
> likely rare in the real-world, though obviously not impossible given
> the report here. For posterity, here's a rundown (braindump) of the
> issue.
>
> When calling EC_KEY_new_by_curve_name(), openssl internally checks to
> see how to setup the curve's EC_METHOD (simple, montgomery, or nist).
>
> Unfortunately, in all released OpenSSL versions (as far as I can tell
> master is the only branch that has fixed this issue), it's tested like
> so:
>
> - Try a method. If it fails, set a global error and return.
> - If the global error is set, try a different method.
>
> Prior to OpenSSL 1.0.0, these were tested in the order:
> EC_GFp_nist_method -> EC_GFp_mont_method. The secp256k1 curve fails
> the ec_GFp_nist_group_set_curve test and sets the global error. That
> error is then checked for failure, and EC_GFp_mont_method is tried
> (and succeeds).
>
> Obviously that global error usage is dangerous, especially since it
> happens for _each_ transaction verification in libbitcoinconsensus. In
> a multi-threaded environment, a crash is guaranteed within a few
> seconds.
>
> However, OpenSSL 1.0.1 reversed the order, trying EC_GFp_mont_method
> first, so that the global error doesn't end up being used:
> https://github.com/openssl/openssl/commit/17674bfdf75bffa4e225f8328b9d42cb74504005
>
> This was backported from master back to 1.0.1, but not to 1.0.0 or 0.9.8.
>
> So that change (accidentally) "solved" the problem. As you can see,
> it's still possible to hit the reversed order in the
> !defined(OPENSSL_BN_ASM_MONT) case. That's easily tested by building
> OpenSSL with the -no-asm config option. It's probably also the case
> for obscure architectures and OSs, but I haven't looked deeply into
> that. In that case, it's reasonable to assume that this crash would
> likely occur on such platforms.
>
> Also, OSX, even the latest version (10.10 as of now), still ships with
> OpenSSL 0.9.8. Which is how Tamas ran into it.
>
> Since Bitcoin Core and libbitcoinconsensus are switching away from
> OpenSSL for verification in the near future, I don't think this is
> much of an issue. Especially since the problem manifests as a
> controlled assertion failure/abort. However, I've prepared a patch for
> anyone who may run into the issue in the short-term:
> https://github.com/theuni/bitcoin/commit/adf0a691ee1c2f02e26828f976cfe5b78896b507
>
> I'll open a pull-request for Bitcoin Core to discuss whether it's
> worth merging or not.
>
> Regards,
> Cory
>
> On Fri, Aug 14, 2015 at 5:10 PM, Cory Fields <lists at coryfields.com> wrote:
>> Ugh, what an unfortunate oversight!
>>
>> The good news is that this issue should be solved in future versions
>> when we switch to the new libsecp256k1 lib for validation.
>>
>> For now, I've thrown together a quick hack to allow a user-specifiable
>> callback for libbitcoinconsensus. I think it's not worth messing with
>> the official API since it will be fixed soon, but rather hacked in as
>> a temporary work-around as needed. It _should_ be documented as an
>> issue with the current version, though.
>>
>> Please see here for a work-around to try:
>> https://github.com/theuni/bitcoin/commits/openssl-consensus-threads
>> Unfortunately it's not pretty, but it works fine here. Note that you
>> should give this some _serious_ testing before deploying in any real
>> way. It should mimic the way we do it in Core, though.
>>
>> That's on top of current master, but it should be trivial to apply to
>> release tags.
>>
>> Please let me know how it works out.
>>
>> Regards,
>> Cory
>>
>> On Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.
>>>
>>> The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:
>>>
>>> Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.
>>>
>>> arises under that stress.
>>>
>>> I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
>>> Registering those however would require access to OpenSSL functions, not exported from the lib.
>>>
>>> I’d be thankful for a pointer to a workaround.
>>>
>>> Tamas Blummer
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/43bc1a5b/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/43bc1a5b/attachment.sig>;

📅 Original date posted:2015-08-14 📝 Original message:We ...

2023-06-07T17:46:58+02:00

In reply to nevent1q…7tyu
_________________________

📅 Original date posted:2015-08-14
📝 Original message:We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.

The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:

Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.

arises under that stress.

I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
Registering those however would require access to OpenSSL functions, not exported from the lib.

I’d be thankful for a pointer to a workaround.

Tamas Blummer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/35f728b8/attachment-0001.sig>;

📅 Original date posted:2015-02-20 📝 Original message:On Feb ...

2023-06-07T17:30:43+02:00

In reply to nevent1q…dr4k
_________________________

📅 Original date posted:2015-02-20
📝 Original message:On Feb 20, 2015, at 5:18 PM, Wladimir <laanwj at gmail.com> wrote:

> On Fri, 20 Feb 2015, Adam Back wrote:
>
>> So I was wondering what about changing to committing a bloom filter of
>> the addresses in the block. Its seems surprising no one thought of it
>> that way before (as it seems obvious when you hear it) but that seems

Such a bloom filter was present in the Bits of Proof block store in its last
public version, so the idea obvious, but not new.

It did support well scanning for BIP32 addresses as the query set extends
while progressing.

Tamas Blummer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150220/b23aaa4c/attachment.sig>;

📅 Original date posted:2015-02-14 📝 Original message:Peter, ...

2023-06-07T17:30:33+02:00

In reply to nevent1q…lm85
_________________________

📅 Original date posted:2015-02-14
📝 Original message:Peter,

You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in.

On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:

> So stop wasting your time. Help get the consensus critical code out of
> Bitcoin Core and into a stand-alone libconsensus library,

We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore
it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet and RPC server.

On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Or you can be stereotypical programmers and dick around on github for
> the next ten years chasing stupid consensus bugs in code no-one uses.

The Core code base is unfriendly to feature extensions because of its criticality, legacy design and ancient technology. It is also a commodity
that the ecosystem takes for granted and free.

I honestly admire the core team that works and progresses within these limits and perception.

I am not willing to work within the core’s legacy technology limits. Does it mean I am dicking around? I think not.
It was my way to go down the rabbit hole by re-digging it and I created successful commercial products on the way.

It is entirely rational for me to focus on innovation that uses the core as a border router for this block chain.

I am rather thankful for the ideas of the side chains, that enable innovation that is no longer measured on unapologetic compatibility with a given code base, but its services to end user.

Tamas Blummer
Bits of Proof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/e52a0ac4/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/e52a0ac4/attachment.sig>;

📅 Original date posted:2015-02-12 📝 Original message:Mike, ...

2023-06-07T17:30:12+02:00

In reply to nevent1q…avpm
_________________________

📅 Original date posted:2015-02-12
📝 Original message:Mike,

You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some.

Some other’s might have seen the replaced transaction, but that only indicates for sure that the signer is fraudulent.

What should a node do that really cares of good reputation? Ignore both to be on the safe side?

Tamas Blummer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/9e44ecf1/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/9e44ecf1/attachment.sig>;

📅 Original date posted:2015-02-12 📝 Original message:On Feb ...

2023-06-07T17:30:12+02:00

In reply to nevent1q…g8fa
_________________________

📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 3:16 PM, Mike Hearn <mike at plan99.net> wrote:
> You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some.
>
> Fraudulent in what sense?

Assume a wallet that sends double spend of the coin spent for services with higher fees to some of its nodes simultaneously.
Merchants will catch and reject most of the attempts, but that will not stop the scheme in a setup where customer are anonymous and distant.

Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure.

Tamas Blummer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/08996a64/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/08996a64/attachment.sig>;

📅 Original date posted:2015-02-12 📝 Original message:On Feb ...

2023-06-07T17:30:07+02:00

In reply to nevent1q…9v3x
_________________________

📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
>
> How does my replace-by-fee patch *not* do that?

Does it broadcast a double spend only if it IS replacing an earlier? If yes, I am fine with it.

Tamas Blummer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/a0014230/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/a0014230/attachment.sig>;

📅 Original date posted:2015-02-12 📝 Original message:On Feb ...

2023-06-07T17:30:07+02:00

In reply to nevent1q…4xfr
_________________________

📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> Why don't you use getrawmempool RPC call to synchronize mempool contents?

Since RPC interface does not scale to serve a multi user service.
In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.

POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only.
These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.

On Feb 12, 2015, at 8:45 AM, Peter Todd <pete at petertodd.org> wrote:
> IOW, assume every transaction your "border router" gives you is now the
> one and only true transaction, and everything conflicting with it must
> go.

You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting
double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .

Tamas Blummer
Bits of Proof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.sig>;

📅 Original date posted:2015-02-12 📝 Original message:Peter, ...

2023-06-07T17:30:06+02:00

In reply to nevent1q…s2wl
_________________________

📅 Original date posted:2015-02-12
📝 Original message:Peter,

An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core.

To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router.

Tamas Blummer
Bits of Proof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/582e4829/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/582e4829/attachment.sig>;

📅 Original date posted:2015-01-20 📝 Original message:I am ...

2023-06-07T17:28:48+02:00

In reply to nevent1q…0rru
_________________________

📅 Original date posted:2015-01-20
📝 Original message:I am not a lawyer, just thinking loud.
I think that technology is a strong argument before court, but I suspect that it is just that, as of now.

Tamas Blummer
On Jan 20, 2015, at 6:47 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:

> On Tuesday, 20 January 2015, at 6:44 pm, Tamas Blummer wrote:
>> Knowing the private key and owning the linked coins is not necessarily the same in front of a court.
>>
>> At least in german law there is a difference between ‘Eigentum' means ownership and ‘Besitz’ means ability to deal with it.
>> Being able to deal with an asset does not make you the owner.
>
> So what we're telling the newbies in /r/bitcoin is plain wrong. Bitcoins *do* have an owner independent from the parties who have access to the private keys that control their disposition. That's pretty difficult to reconcile from a technological perspective.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150120/516a0e8b/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150120/516a0e8b/attachment.sig>;

📅 Original date posted:2014-05-03 📝 Original message:bit ...

2023-06-07T17:20:38+02:00

In reply to nevent1q…rewt
_________________________

📅 Original date posted:2014-05-03
📝 Original message:bit has a lot of meanings to geeks, so what.

bit means for average people:
- something very small, that 100 satoshi is.
- part of the name Bitcoin
- easy to get conversion 1 coin = 1 million bits = 1 Bitcoin

Regards,

Tamas Blummer
Founder, CEO
http://bitsofproof.com

On 03.05.2014, at 18:02, slush <slush at centrum.cz> wrote:

> Excellent points Christophe!
>
> Although moving to 1e-6 units is fine for me and I see advantages of doing this, I don't get that people on this mailing list are fine with calling such unit "bit". It's geeky as hell, ambiguous and confusing.
>
> slush
>
>
> On Sat, May 3, 2014 at 5:48 PM, Christophe Biocca <christophe.biocca at gmail.com> wrote:
> Context as a disambiguator works fine when the interlocutors
> understand the topics they're talking about.
> Not a day goes by without me seeing "neurotypical people" get horribly
> confused between RAM and Hard Drive sizes, because they share the same
> units (not that that can be helped, as the units are supposed to be
> the same, base 1000 vs 1024 notwithstanding).
>
> Bit (as a unit) is already really confusing for anyone who doesn't
> deal with it on a regular basis. I think people who don't see an issue
> are making an assumption based on their own lack of confusion. We
> understand computer science AND Bitcoin. Most people have zero
> understanding of either.
>
> Bitcoin already has a ton of issues with terrible names for things:
>
> - Mining (for transaction validation).
> - Addresses (which are meant to be one-time use, and don't even really
> exist at the network level).
> - Wallets (which don't hold your bitcoins, can be copied, and all
> backups can be stolen from equally).
>
> I end up having to make the distinctions obvious every time I explain
> Bitcoin to someone new to it. There's an acceptable tradeoff here,
> because there were arguably no better words to assign to these
> concepts (although I'd argue mining is a really awful metaphor, and is
> the one that prompts the most questions from people). Then add to the
> pile a bunch of third parties naming themselves after parts of the
> protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
> definitiely seen average people get confused between "the blockchain"
> and "blockchain.info" (not so much Coinbase, because that name doesn't
> come up in beginner explanations).
>
> It seems downright masochistic to add
> yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
> for no reason other than aesthetics. Are we actively trying to confuse
> people?
>
> On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine <voisine at gmail.com> wrote:
> > I have to agree with Mike. Human language is surprisingly tolerant of
> > overloading and inference from context. Neurotypical people have no
> > problem with it and perceive a software engineer's aversion to it as
> > being pedantic and strange. Note that "bits" was a term for a unit of
> > money long before the invention of digital computers.
> >
> > Aaron
> >
> > There's no trick to being a humorist when you have the whole
> > government working for you -- Will Rodgers
> >
> >
> > On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr <gojomo at gmail.com> wrote:
> >> [resend - apologies if duplicate]
> >>
> >> Microbitcoin is a good-sized unit, workable for everyday transaction
> >> values, with room-to-grow, and a nice relationship to satoshis as 'cents'.
> >>
> >> But "bits" has problems as a unit name.
> >>
> >> "Bits" will be especially problematic whenever people try to graduate
> >> from informal use to understanding the system internals - that is, when
> >> the real "bits" of key sizes, hash sizes, and storage/bandwidth needs
> >> become important. The "bit" as "binary digit" was important enough that
> >> Satoshi named the system after it; that homage gets lost if the word is
> >> muddied with a new retconned meaning that's quite different.
> >>
> >> Some examples of possible problems:
> >>
> >> * If "bit" equals "100 satoshis", then the natural-language unpacking of
> >> "bit-coin" is "100 satoshi coin", which runs against all prior usage.
> >>
> >> * If people are informed that a "256-bit private key" is what ultimately
> >> controls their balances, it could prompt confusion like, "if each key
> >> has 256-bits, will I need 40 keys to hold 10,000.00 bits?"
> >>
> >> * When people learn that there are 8 bits to a byte, they may think,
> >> "OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes".
> >>
> >> * When people naturally extend "bit" into "kilobits" to mean "1000
> >> bits", then the new coinage "kilobits" will mean the exact same amount
> >> (100,000 satoshi) as many have already been calling "millibits".
> >>
> >> I believe it'd be best to pick a new made-up single-syllable word as a
> >> synonym for "microbitcoin", and I've laid out the case for "zib" as that
> >> word at <http://zibcoin.org>;.
> >>
> >> 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ'
> >> (Z-with-stroke), that remains distinctive even if it loses its stroke or
> >> gets case-reversed. (Comparatively, all 'b'-derived symbols for
> >> data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts
> >> where subtleties of casing/stroking are lost.)
> >>
> >> (There's summary of more problems with "bit" in the zibcoin.org FAQ at:
> >> <http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins>;.)
> >>
> >> - Gordon
> >>
> >> On 5/1/14, 3:35 PM, Aaron Voisine wrote:
> >>> I'm also a big fan of standardizing on microBTC as the standard unit.
> >>> I didn't like the name "bits" at first, but the more I think about it,
> >>> the more I like it. The main thing going for it is the fact that it's
> >>> part of the name bitcoin. If Bitcoin is the protocol and network, bits
> >>> are an obvious choice for the currency unit.
> >>>
> >>> I would like to propose using Unicode character U+0180, lowercase b
> >>> with stroke, as the symbol to represent the microBTC denomination,
> >>> whether we call bits or something else:
> >>> http://www.fileformat.info/info/unicode/char/0180/index.htm
> >>>
> >>> Another candidate is Unicode character U+2422, the blank symbol, but I
> >>> prefer stroke b.
> >>> http://www.fileformat.info/info/unicode/char/2422/index.htm
> >>>
> >>> Aaron
> >>>
> >>> There's no trick to being a humorist when you have the whole
> >>> government working for you -- Will Rodgers
> >>>
> >>>> On Apr 21, 2014 5:41 AM, "Pieter Wuille" <pieter.wuille at gm...> wrote:
> >>>>
> >>>>> On Apr 21, 2014 3:37 AM, "Un Ix" <slashdevnull at ...> wrote:
> >>>>>
> >>>>> Something tells me this would be reduced to a single syllable in common
> >>>>> usage I.e. bit.
> >>>>
> >>>> What units will be called colloquially is not something developers will
> >>>> determine. It will vary, depend on language and culture, and is not
> >>>> relevant to this discussion in my opinion.
> >>>>
> >>>> It may well be that people in some geographic or language area will end up
> >>>> (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as
> >>>> "official" name in software would be very strange and potentially confusing
> >>>> in my opinion. As mentioned by others, that would seem to me like calling
> >>>> dollars "bucks" in bank software. Nobody seems to have a problem with
> >>>> having colloquial names, but "US dollar" or "euro" are far less ambiguous
> >>>> than "bit". I think we need a more distinctive name.
> >>>>
> >>>> --
> >>>> Pieter
> >>>
> >>> ------------------------------------------------------------------------------
> >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >>> unparalleled scalability from the best Selenium testing platform available.
> >>> Simple to use. Nothing to install. Get started now for free."
> >>> http://p.sf.net/sfu/SauceLabs
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >> ------------------------------------------------------------------------------
> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >> unparalleled scalability from the best Selenium testing platform available.
> >> Simple to use. Nothing to install. Get started now for free."
> >> http://p.sf.net/sfu/SauceLabs
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> > ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos. Get
> > unparalleled scalability from the best Selenium testing platform available.
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140503/b6c434e1/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140503/b6c434e1/attachment.sig>;

📅 Original date posted:2014-04-26 📝 Original message:Yes, ...

2023-06-07T17:20:07+02:00

In reply to nevent1q…w3v9
_________________________

📅 Original date posted:2014-04-26
📝 Original message:Yes, it is expensive but possible to discover any funds associated with a seed, provided there are set limits to:

1. gap of address use (e.g. 20)
2. depth of hierarchy (e.g. 6)
3. gap in use of parallel branches (e.g. 0)

I would pick the limits in brackets above.

Regards,

Tamas Blummer
http://bitsofproof.com

On 26.04.2014, at 12:48, Tier Nolan <tier.nolan at gmail.com> wrote:

> Maybe the solution is to have a defined way to import an unknown wallet?
>
> This means that the gap space and a search ordering needs to be defined.
>
> Given a blockchain and a root seed, it should be possible to find all the addresses for that root seed.
>
> The hierarchy that the wallet actually uses could be anything.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/e6b66a73/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/e6b66a73/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:The ...

2023-06-07T17:18:57+02:00

In reply to nevent1q…37sj
_________________________

📅 Original date posted:2014-04-23
📝 Original message:The problem is µBTC that bit tries to solve.

BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The mixed use of them leads to misunderstanding.
I think adoption would benefit of a single unit with easily remembered and associated name that has no smaller than 1/100 fractions called satoshis.

Regards,

Tamás Blummer
Founder, CEO

http://bitsofproof.com

On 23.04.2014, at 11:44, Danny Hamilton <danny.hamilton at gmail.com> wrote:

> It seems to me that xbit is no more distinct or intuitive than µbit. In either case it's simply an arbitrary character in front of the word "bit". Of course, for the majority of the world familiar with SI, the µ actually adds additional meaning that is lost with the x.
>
> Furthermore, given the multiple concerns voiced about the overuse of the word "bit", µBTC seems to solve the problem.
>
> Since we are talking about how it would be displayed in software, we don't need to be concerned about how people will pronounce it, or what the nickname will be. If most of the wallets start displaying amounts in µBTC quantities, it will be obvious that a µBTC is a different magnitude than a BTC. Nobody is going to look at their 100,000 µBTC balance and think they have 100,000 BTC. People will immediately make the mental adjustment to the new order of magnitude even if they don't specifically know that µ means micro, or that micro means 1e-6.
>
> Nicknames will form organically (much like buck, fin, large, k, grand, and benny for U.S. currency), I've always been partial to milly (or millie) and mike (or micky) as nicknames for mBTC and µBTC. I've personally used those when speaking with people, and they seem to catch on pretty quickly.
>
> As has already been mentioned, you're going to be hard pressed to find software that denotes U.S. balances in "bucks". There isn't any good reason to be coding a nickname like "bit", "xbit", or "mike" into wallet software.
>
> - Danny Hamilton
>
>
> On Tue, Apr 22, 2014 at 8:51 AM, Aaron Axvig <aaron at axvigs.com> wrote:
> That piece of horse equipment is called a bit in the US too. But the point
> stands: most people don't use "bit" on a daily basis other than referring to
> "a little bit of <something>."
>
> -----Original Message-----
> From: Wladimir [mailto:laanwj at gmail.com]
> Sent: Sunday, April 20, 2014 11:27 AM
> To: Chris Pacia
> Cc: Bitcoin Dev
> Subject: Re: [Bitcoin-development] "bits": Unit of account
>
> On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia <ctpacia at gmail.com> wrote:
> > The term bit is really only overloaded for those who are techy. 95% of
> > the population never uses the term bit in their daily lives and I
> > doubt most could even name one use of the term.
> > Plus bit used to be a unit of money way back when, so this is kind of
> > reclaiming it. I think it's a great fit.
>
> That's a very anglocentric way of thinking.
>
> Here in the Netherlands, a "bit" is something you put in a horses's mouth.
> It's also used as imported word (in the information sense).
> We've never used the term for money.
>
> Wladimir
>
> ----------------------------------------------------------------------------
> --
> Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the
> definitive new guide to graph databases and their applications. Written by
> three acclaimed leaders in the field, this first edition is now available.
> Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/be82e058/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.png
Type: image/png
Size: 7120 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/be82e058/attachment.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/be82e058/attachment.sig>;

📅 Original date posted:2014-04-20 📝 Original message:Here ...

2023-06-07T17:18:55+02:00

In reply to nevent1q…kmc3
_________________________

📅 Original date posted:2014-04-20
📝 Original message:Here is an earlier reference to bits:

https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html

I forgot that Alan Reiner was also supporting a unit equals to bits :

https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html

and here the earlier going back to March 2013 and a poll at that time pushing for XBT being 1 bit

https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html

Regards,

Tamas Blummer
http://bitsofproof.com

On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com> wrote:

> I told him specifically to bring it here (on a pull request for
> Bitcoin Core), as there is no point in making such convention changes
> to just one client.
>
> I wasn't aware of any discussion about the "bits" proposal here before.
>
> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> People on this list are mostly engineers who have no problem dealing with
>> magnitudes and have rather limited empathy for people who have a problem
>> with them.
>> They also tend to think, that because they invented money 2.0 they would not
>> need to care of finance's or people's current customs.
>>
>> The importance of their decisions in these questions will fade as people
>> already use wallets other than the core.
>>
>> Bring this particular discussion elsewhere, to the wallet developer.
>>
>> BTW the topic was discussed here several times, you have my support and Jeff
>> Garzik's.
>>
>> Regards,
>>
>> Tamas Blummer
>> http://bitsofproof.com
>>
>> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:
>>
>> The average person is not going to be confident that the prefix they
>> are using is the correct one,
>>
>>
>> The use of any 'prefix' is one of choice and entirely unnecessary, and there
>> are already established 'divisions' in u/mBTC for those that feel they need
>> to use such things.
>>
>> people WILL send 1000x more or less than
>> intended if we go down this road,
>>
>>
>> Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
>> dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
>> once in 20 years has anyone ever 'sent' more or less than intended - oh,
>> they've 'intended' to underpay just fine, but never *unintended*.
>>
>> I propose that users are offered a preference to denominate the
>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>> equals one million bits (bits) and one bit equals 100 satoshis.
>>
>>
>> I propose that for people unable to understand what a bitcoin is, they can
>> just use satoshi's and drop this entire proposal.
>>
>> Rob
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/33517770/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/33517770/attachment.sig>;

📅 Original date posted:2014-04-21 📝 Original message:Thomas ...

2023-06-07T17:18:54+02:00

In reply to nevent1q…pnhq
_________________________

📅 Original date posted:2014-04-21
📝 Original message:Thomas V:

Your proposal misses the points that:

- this is about a unit with 1e-6 Bitcoins or 100 satoshis.
- it is not about people who know Bitcoin and are techies, but about those who don’t and aren’t.

The reasons for such a unit are more than shifting the comma some places for convinience,
but to align Bitcoin with capabilities of existing financial software and customs of finance and average people,
and ISO standard of currency abbreviations.

bit and XBT seems to check the boxes.

I would love to have some feedback on xbit as per my previous mail.

Regards,

Tamas Blummer
http://bitsofproof.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/2b053b14/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/2b053b14/attachment.sig>;

📅 Original date posted:2014-04-20 📝 Original message:People ...

2023-06-07T17:18:53+02:00

In reply to nevent1q…7kva
_________________________

📅 Original date posted:2014-04-20
📝 Original message:People on this list are mostly engineers who have no problem dealing with magnitudes and have rather limited empathy for people who have a problem with them.
They also tend to think, that because they invented money 2.0 they would not need to care of finance’s or people’s current customs.

The importance of their decisions in these questions will fade as people already use wallets other than the core.

Bring this particular discussion elsewhere, to the wallet developer.

BTW the topic was discussed here several times, you have my support and Jeff Garzik’s.

Regards,

Tamas Blummer
http://bitsofproof.com

On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:

>> The average person is not going to be confident that the prefix they
>> are using is the correct one,
>
> The use of any 'prefix' is one of choice and entirely unnecessary, and there
> are already established 'divisions' in u/mBTC for those that feel they need
> to use such things.
>
>> people WILL send 1000x more or less than
>> intended if we go down this road,
>
> Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
> dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
> once in 20 years has anyone ever 'sent' more or less than intended - oh,
> they've 'intended' to underpay just fine, but never *unintended*.
>
>> I propose that users are offered a preference to denominate the
>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>> equals one million bits (bits) and one bit equals 100 satoshis.
>
> I propose that for people unable to understand what a bitcoin is, they can
> just use satoshi's and drop this entire proposal.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/1fb70649/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/1fb70649/attachment.sig>;

📅 Original date posted:2014-04-10 📝 Original message:I know ...

2023-06-07T17:18:24+02:00

In reply to nevent1q…0lfp
_________________________

📅 Original date posted:2014-04-10
📝 Original message:I know the idea is not new. Just bringing it up to emphasize that if we don’t use it how could we expect other networks using it.
Machine to machine micro payments could become the killer application for Bitcoin.

1) There is no catch 22 as there are plenty of ways getting bitcoin without bootstrapping a full node.

2) let markets work out and not speculate what would happen.

3) Serving archive bolcks does not have to be part of core but could be a distinct service written in a language of your choice using new protocol.

As mentioned earlier I am for a stripped down core that does nothing else than consensus and stores nothing else needed for that task and offering SPV api to the wallets.

Tamas Blummer
http://bitsofproof.com

On 10.04.2014, at 11:17, Mike Hearn <mike at plan99.net> wrote:

> I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network.
>
> It's not a new idea, obviously, but there are some practical consequences:
>
> 1) To pay a node for serving, you have to have bitcoins. To get bitcoins, you need to sync with the network via a node. Catch 22.
>
> 2) If some nodes choose to charge and others choose to not charge, a smart wallet will always use the free nodes. In the absence of any global load balancing algorithms, this would lead to the free nodes getting overloaded and collapsing whilst the for-pay nodes remain silent.
>
> 3) The only payment channel implementations today are bitcoinj's (Java) and one written by Jeff in Javascript. There are no C++ implementations. And as Matt and I can attest to, doing a real, solid, fully debugged implementation that's integrated into a real app is .... a lot of work.
>
> I still think the lowest hanging fruit is basic, boring optimisations rather than architectural rethinks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/2fb654ae/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/2fb654ae/attachment.sig>;

📅 Original date posted:2014-04-10 📝 Original message:You ...

2023-06-07T17:18:23+02:00

In reply to nevent1q…50a2
_________________________

📅 Original date posted:2014-04-10
📝 Original message:You ask why people would install this ?

I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network.
What about serving archive blocks to peers paying for it ?

Tamas Blummer
http://bitsofproof.com

On 10.04.2014, at 08:50, Wladimir <laanwj at gmail.com> wrote:
> The only drawback would be that initially, people wouldn't know why or when to install this, hence my suggestion to pack it with wallets...
>
> Wladimir
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/251ef004/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/251ef004/attachment.sig>;

📅 Original date posted:2014-04-09 📝 Original message:A ...

2023-06-07T17:18:15+02:00

In reply to nevent1q…5vh3
_________________________

📅 Original date posted:2014-04-09
📝 Original message:A border router that is not able to serve blocks is still protecting consensus rules, that SPVs do not.
If the network would only consist of SPV nodes only then e.g. a majority coalition of miner could increase their reward at will.

Archives need a different solution.

Regards,

Tamas Blummer
http://bitsofproof.com

On 09.04.2014, at 17:47, Mark Friedenbach <mark at monetize.io> wrote:

> On 04/09/2014 09:09 AM, Tamas Blummer wrote:
>> Yes, SPV is a sufficient API to a trusted node to build sophisticated
>> features not offered by the core.
>> SPV clients of the border router will build their own archive and
>> indices based on their interest of the chain therefore the
>> border router core does not need to store (and process) anything not
>> needed for consensus, its memory
>> or disk footprint would be as low as an optimal storage of UTXO.
>
> Storing zero full blocks does nothing to aid the network.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/7f11ea3a/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/7f11ea3a/attachment.sig>;

📅 Original date posted:2014-04-09 📝 Original message:Block ...

2023-06-07T17:18:15+02:00

In reply to nevent1q…mx3g
_________________________

📅 Original date posted:2014-04-09
📝 Original message:Block header has to be available in SPV and also in an UTXO only storing core node, so why not serve it if bandwith allows.

Serving any additional information like known peer adresses or known full blocks is certainly beneficial and should be offered if at hand.

Regards,

Tamas Blummer
http://bitsofproof.com

On 09.04.2014, at 19:46, Peter Todd <pete at petertodd.org> wrote:

> Signed PGP part
>
>
> On 9 April 2014 12:27:13 GMT-04:00, Tamas Blummer <tamas at bitsofproof.com> wrote:
> >A border router that is not able to serve blocks is still protecting
> >consensus rules, that SPVs do not.
> >If the network would only consist of SPV nodes only then e.g. a
> >majority coalition of miner could increase their reward at will.
> >
> >Archives need a different solution.
>
> Any collective group that has a majority of hashing power will have no major issues running enough nodes that follow their rules to make SPV insecure anyway.
>
> There's no good reason not to have SPV security nodes distribute block chain data, particularly block headers. It helps provide redundancy in the network topology and helps provide more resources for full nodes to sync up faster. For instance in a network with a large number of partial UTXO set nodes if those nodes are forwarding block data to each other they can get enough data to become fully fledged full nodes without putting all the load on the existing full nodes. This is a good thing.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/781e75c1/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/781e75c1/attachment.sig>;

📅 Original date posted:2014-04-09 📝 Original message:I am ...

2023-06-07T17:18:14+02:00

In reply to nevent1q…aga2
_________________________

📅 Original date posted:2014-04-09
📝 Original message:I am glad that SPV wallets are discussed outside the scope of mobile devices!

Yes, SPV is a sufficient API to a trusted node to build sophisticated features not offered by the core.
SPV clients of the border router will build their own archive and indices based on their interest of the chain therefore the
border router core does not need to store (and process) anything not needed for consensus, its memory
or disk footprint would be as low as an optimal storage of UTXO.

Regards,

Tamás Blummer
http://bitsofproof.com

On 09.04.2014, at 17:57, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Wed, Apr 9, 2014 at 8:42 AM, Brian Hoffman <brianchoffman at gmail.com> wrote:
>> How would this affect the user in terms of disk storage? They're going to
>> get hammered on space constraints aren't they? If it's not required how
>> likely are users to enable this?
>
> If Bitcoin core activates pruning a full node can be supported in—
> say— 4GBytes or so. (That gives enough space to store the utxo about
> 350MB now, and a couple gigs for blocks to serve out).
>
> I'd imagine getting information from SPV wallet developers how much
> disk usage agility they think is required is part of what Wladimir is
> looking for.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/44274e19/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/44274e19/attachment.sig>;

📅 Original date posted:2014-04-10 📝 Original message:Hi ...

2023-06-07T17:18:11+02:00

In reply to nevent1q…jqtk
_________________________

📅 Original date posted:2014-04-10
📝 Original message:Hi Wladimir,

If the motivation of the SPV wallet is to radically extend functionality, as in my case, then the index is specific to the added features and the subset of the blockchain that is of interest for the wallet.
As you also point out, adding huge generic purpose indices to core would rather discourage people using full nodes due to excess requirements.

I believe nothing would add more to the core’s popularity as a trusted background node to SPV than full validation at lowest possible memory, disk and CPU footprint.
Serving headers should be default but storing and serving full blocks configurable to ranges, so people can tailor to their bandwith and space available.

Tamas Blummer
Bits of Proof

On 09.04.2014, at 21:25, Wladimir <laanwj at gmail.com> wrote:
>
>
> Adding a RPC call for a "address -> utxo" query wouldn't be a big deal. It has been requested before for other purposes as well, all the better if it helps for interaction with Electrum.
>
> Spent history would be involve a much larger index, and it's not likely that will end up in bitcoin
>
> Wladimir
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/45889b81/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/45889b81/attachment.sig>;

📅 Original date posted:2014-04-09 📝 Original message:YES ...

2023-06-07T17:18:09+02:00

In reply to nevent1q…gsus
_________________________

📅 Original date posted:2014-04-09
📝 Original message:YES

Such a bitcoind is what I called border router in a previous mail.

Yes, SPV wallets are getting ahead of features, so people will use them also because on size just does not fit all, but all want to ensure being on the same trunk of the chain.
Therefore serious user of Bitcoin run a bitcoind as a border router and connect SPV wallets with higher functionality to that trusted node(s).

This is what I think the core should focus on: Being a lightweight superfast consensus building border router and nothing more. No wallet, no GUI, no RPC calls,
no Payment protocol and the rest.

Regards,

Tamas Blummer
http://bitsofproof.com

On 09.04.2014, at 17:29, Wladimir <laanwj at gmail.com> wrote:

> Hello,
>
> This is primarily aimed at developers of SPV wallets.
>
> The recently reported decrease in number of full nodes could have several reasons, one of them that less people are running Bitcoin Core for the wallet because the other wallets are getting ahead in both features and useability.
>
> It's great to see innovation in wallets, but it's worrying that the number of full nodes decreases.
>
> It may be that lots of people would support the network by running a full node, but don't want to go through the trouble of installing bitcoin core separately (and get confused because it's a wallet, too).
>
> Hence I'd like to explore the idea of adding an option to popular SPV wallets, to spin a bitcoind process in the background. This could be pretty much transparent to the user - it would sync in the background, the wallet could show statistics about the node, but is not dependent on it.
>
> In exchange the user would get increased (full node level) security, as the SPV wallet would have a local trusted node.
>
> Does this sound like a good idea?
>
> Is there any way that Bitcoin Core can help to accomedate this 'embedded' usage? Specific Interfaces, special builds - maybe add a walletless bitcoind build to gitian - bindings, dlls, etc?
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/714a611c/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/714a611c/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:The ...

2023-06-07T17:18:05+02:00

In reply to nevent1q…93j7
_________________________

📅 Original date posted:2014-04-23
📝 Original message:The most useful meta data to optimize chain scan is the key birth date, then the allowed gap size.

Tamas Blummer
http://bitsofproof.com

On 23.04.2014, at 20:39, Tier Nolan <tier.nolan at gmail.com> wrote:

> Different users could have different gap limit requirements. 20 seems very low as the default.
>
> A merchant could easily send 20 addresses in a row to customers and none of them bother to actually buy anything.
>
> Setting the gap limit to high is just a small extra cost in that case.
>
> Bip-32 serialization doesn't have a way of adding meta data though.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/88279ae3/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/88279ae3/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:18:03+02:00

In reply to nevent1q…4z9v
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 23.04.2014, at 22:02, Luke-Jr <luke at dashjr.org> wrote:

> On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
>> On 23.04.2014, at 21:55, Luke-Jr <luke at dashjr.org> wrote:
>>> Any wallet should import all the coins just fine, it just wouldn't *use*
>>> any account other than 0. Remember addresses are used to receive
>>> bitcoins; once the UTXOs are in the wallet, they are no longer
>>> associated with the address or any other details of how they were
>>> received.
>>
>> This is a bit idealistic.
>> The wallet has to know how it got the UTXO in order to be able to spend it.
>
> No it doesn't... Just the assigned scriptPubKey and secret(s) required to
> satisfy it.
>

To know the secret it needs to know which key coordinate to use that is logically the same as knowing the address it used to receive it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/5bc05ae4/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:18:02+02:00

In reply to nevent1q…h96q
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 23.04.2014, at 21:55, Luke-Jr <luke at dashjr.org> wrote:
> Any wallet should import all the coins just fine, it just wouldn't *use* any
> account other than 0. Remember addresses are used to receive bitcoins; once
> the UTXOs are in the wallet, they are no longer associated with the address or
> any other details of how they were received.

This is a bit idealistic.
The wallet has to know how it got the UTXO in order to be able to spend it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/baa76914/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:18:01+02:00

In reply to nevent1q…zj2n
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On 23.04.2014, at 22:09, Luke-Jr <luke at dashjr.org> wrote:

> On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
>> On 04/23/2014 10:01 PM, Luke-Jr wrote:
>>> Yes, it should scan all possible (under the BIP-defined structure)
>>> branches regardless of which features it supports.
>>
>> So you suggest to scan for accounts, show balances but don't allow user
>> to spend them? Does not seem right to me.
>
> Scan all branches for UTXOs, then you have the balance for the wallet. Account
> balances are metadata, so cannot be known from the seed alone. If you want to
> have a way to restore accounts, you must define some more detailed wallet file
> format (which could be built on top of this).
>
> On Wednesday, April 23, 2014 8:04:35 PM you wrote:
>> On 23.04.2014, at 22:02, Luke-Jr <luke at dashjr.org> wrote:
>>> On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
>>>> The wallet has to know how it got the UTXO in order to be able to spend
>>>> it.
>>>
>>> No it doesn't... Just the assigned scriptPubKey and secret(s) required to
>>> satisfy it.
>>
>> To know the secret it needs to know which key coordinate to use that is
>> logically the same as knowing the address it used to receive it.
>
> Sure, it *knows* what address was used to receive it. But at the point it's a
> UTXO, that address is no longer relevant.
>

In context of BIP32 one does not store secrets but re-create them on-the-fly if needed using key coordinates known to the UTXO.
Individual secrets per UTXO are about as irrelevant and accessible as addresses.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/73badbe8/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:I ...

2023-06-07T17:17:55+02:00

In reply to nevent1q…gtg6
_________________________

📅 Original date posted:2014-04-23
📝 Original message:I built such a merchant system handing out BIP32 addresses.

The gap size problem does not arise there since such a system has to have an extra database keeping track of requests, so there is no added cost of storing the key coordinates used by them. A scan is not needed the keys can be accessed at random order.

Tamas Blummer
http://bitsofproof.com

On 23.04.2014, at 21:00, Tier Nolan <tier.nolan at gmail.com> wrote:

> On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak <stick at gk2.sk> wrote:
>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>
> I meant for a merchant with a server that is handing out hundreds of addresses.
>
> The point is to have a single system that is compatible over a large number of systems.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/693f3869/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/693f3869/attachment.sig>;

📅 Original date posted:2014-04-23 📝 Original message:Pieter ...

2023-06-07T17:17:54+02:00

In reply to nevent1q…40fa
_________________________

📅 Original date posted:2014-04-23
📝 Original message:Pieter suggested in IRC couple of months ago to append key birth to key serialization in xprv…. at unixtime format.

What about picking this idea up in BIP64? It would greatly help the importing client.

Regards,

Tamas Blummer
http://bitsofproof.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/a787e044/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/a787e044/attachment.sig>;

📅 Original date posted:2014-04-08 📝 Original ...

2023-06-07T17:17:51+02:00

In reply to nevent1q…2lvk
_________________________

📅 Original date posted:2014-04-08
📝 Original message:Pieter,

your suggestion has charm since “Bitcoin seed” would even not need
a global dictionary like the interpretation of the first level, since it would be self describing.

Regards,

Tamas Blummer
http://bitsofproof.com

On 08.04.2014, at 15:53, Pieter Wuille <pieter.wuille at gmail.com> wrote:

> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
> This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
> --
> Pieter
>
>
> On Tue, Apr 8, 2014 at 3:43 PM, slush <slush at centrum.cz> wrote:
>> tl;dr;
>>
>> It is dangerous to expect that other seed than "xprv" does not contain
>> bitcoins or that "xprv" contains only bitcoins, because technically are both
>> situations possible. It is still safer to do the lookup; the magic itself is
>> ambiguous.
>>
>> Marek
>>
>> On Tue, Apr 8, 2014 at 3:40 PM, slush <slush at centrum.cz> wrote:
>>>
>>>
>>> Serialization magic of bip32 seed is in my opinion completely unnecessary.
>>> Most of software does not care about it anyway; You can use xprv/xpub pair
>>> for main net, testnet, litecoin, dogecoin, whatevercoin.
>>>
>>> Instead using the same seed (xprv) and then separate the chains *inside*
>>> the bip32 path seems more useful to me.
>>>
>>> Marek
>>
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/272c6548/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/272c6548/attachment.sig>;

📅 Original date posted:2014-04-07 📝 Original message:You ...

2023-06-07T17:17:42+02:00

In reply to nevent1q…xdzl
_________________________

📅 Original date posted:2014-04-07
📝 Original message:You have to load headers sequantially to be able to connect them and determine the longest chain.

Blocks can be loaded in random order once you have their order given by the headers.
Computing the UTXO however will force you to at least temporarily store the blocks unless you have plenty of RAM.

Regards,

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:30, Paul Lyon <pmlyon at hotmail.ca> wrote:

> I hope I'm not thread-jacking here, apologies if so, but that's the approach I've taken with the node I'm working on.
>
> Headers can be downloaded and stored in any order, it'll make sense of what the winning chain is. Blocks don't need to be downloaded in any particular order and they don't need to be saved to disk, the UTXO is fully self-contained. That way the concern of storing blocks for seeding (or not) is wholly separated from syncing the UTXO. This allows me to do the initial blockchain sync in ~6 hours when I use my SSD. I only need enough disk space to store the UTXO, and then whatever amount of block data the user would want to store for the health of the network.
>
> This project is a bitcoin learning exercise for me, so I can only hope I don't have any critical design flaws in there. :)
>
> From: tamas at bitsofproof.com
> Date: Mon, 7 Apr 2014 21:20:31 +0200
> To: gmaxwell at gmail.com
> CC: bitcoin-development at lists.sourceforge.net
> Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
>
>
> Once headers are loaded first there is no reason for sequential loading.
>
> Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous.
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 07.04.2014, at 21:03, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
>> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>>> therefore I guess it is more handy to return some bitmap of pruned/full
>>> blocks than ranges.
>>
>> A bitmap also means high overhead and— if it's used to advertise
>> non-contiguous blocks— poor locality, since blocks are fetched
>> sequentially.
>>
>
>
> ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________ Bitcoin-development mailing list Bitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/c7bb2295/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/c7bb2295/attachment.sig>;

📅 Original date posted:2014-04-07 📝 Original message:You ...

2023-06-07T17:17:41+02:00

In reply to nevent1q…339u
_________________________

📅 Original date posted:2014-04-07
📝 Original message:You have the trunk defined by the headers. Once a range from genesis to block n is fully downloaded,
you may validate upto block n. Furthermore after validation you can prune transactions spent until block n.

You would approach the highest block with validation and stop pruning say 100 blocks before it, to leave room for reorgs.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:13, Mark Friedenbach <mark at monetize.io> wrote:

>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do you find those blocks?
>
> I have a suggestion: have nodes advertise which range of full blocks
> they possess, then you can perform synchronization from the adversed ranges!
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/cc4c7838/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/cc4c7838/attachment.sig>;

📅 Original date posted:2014-04-07 📝 Original message:Once ...

2023-06-07T17:17:41+02:00

In reply to nevent1q…2mfs
_________________________

📅 Original date posted:2014-04-07
📝 Original message:Once headers are loaded first there is no reason for sequential loading.

Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:03, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> therefore I guess it is more handy to return some bitmap of pruned/full
>> blocks than ranges.
>
> A bitmap also means high overhead and— if it's used to advertise
> non-contiguous blocks— poor locality, since blocks are fetched
> sequentially.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/895983a6/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/895983a6/attachment.sig>;

📅 Original date posted:2014-04-07 📝 Original message:Maybe ...

2023-06-07T17:17:40+02:00

In reply to nevent1q…k9yk
_________________________

📅 Original date posted:2014-04-07
📝 Original message:Maybe it is not a question of the maturity of the implementation but that of the person making presumptions of it.

I consider a fully pruned blockchain being equivalent to the UTXO. Block that hold no
more unspent transaction are reduced to a header. There is however no harm if more retained.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:02, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> Once a single transaction in pruned in a block, the block is no longer
>> eligible to be served to other nodes.
>> Which transactions are pruned can be rather custom e.g. even depending on
>> the wallet(s) of the node,
>> therefore I guess it is more handy to return some bitmap of pruned/full
>> blocks than ranges.
>
> This isn't at all how pruning works in Bitcoin-QT (nor is it how I
> expect pruning to work for any mature implementation). Pruning can
> work happily on a whole block at a time basis regardless if all the
> transactions in it are spent or not.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/5d49d687/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/5d49d687/attachment.sig>;

📅 Original date posted:2014-04-07 📝 Original message:Once a ...

2023-06-07T17:17:39+02:00

In reply to nevent1q…4aav
_________________________

📅 Original date posted:2014-04-07
📝 Original message:Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes.
Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 20:49, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
>
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/e37eb022/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/e37eb022/attachment.sig>;

📅 Original date posted:2014-04-07 📝 Original ...

2023-06-07T17:17:39+02:00

In reply to nevent1q…uhj4
_________________________

📅 Original date posted:2014-04-07
📝 Original message:Headers first loading allows the node to run SPV from the very first minutes and it can converge to full node by time.
This is BTW how newest versions of BOP can work.

Pruning however disqualifies the node as a source for bootstrapping an other full node.
BTW, did we already agree on the service bits for an archive node?

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 20:23, Mike Hearn <mike at plan99.net> wrote:

> * Sent 456.5 gb data
>
> At my geographic service location (Singapore), this cost about $90 last month for bandwidth alone.
>
> One of the reasons I initiated the (now stalled) PayFile project was in anticipation of this problem:
>
> https://github.com/mikehearn/PayFile
> http://www.youtube.com/watch?v=r0BXnWlnIi4&feature=youtu.be
>
> At some point if you want to actually download and validate the full block chain from scratch, you will have to start paying for it I'm sure.
>
> In the meantime:
> Getting headers-first implemented and rolled out everywhere would reduce the amount of redundant downloading and hopefully reduce transmit traffic network-wide.
> Implementing chain pruning would allow people to control upload bandwidth consumption by reducing the amount of disk storage they allow.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/3bc77bbe/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/3bc77bbe/attachment.sig>;

📅 Original date posted:2014-04-22 📝 Original message:Yes, ...

2023-06-07T17:17:14+02:00

In reply to nevent1q…6mkr
_________________________

📅 Original date posted:2014-04-22
📝 Original message:Yes, it is current norm. I am questioning if we should hang on to it in BIPs.

I see testnet as a tool for a certain type of testing. Its existence is likely a consequence of Satoshi not writing unit tests and having automated integration tests, but creating a shadow chain to try things out, mostly manually.

I do not say testnet (as we know) would not be useful for certain tests. E.g. as we developed myTREZOR with slush it was useful to have a shared chain with worthless tokens and transactions we can both refer to. However for our automated tests chains-in-a-box are better as we can easily create and exactly re-create wierd situations on-the-fly.

While talking about BIP32 hierarchy use, several people argued to use a level of the hierarchy to identify the chain the key is used on. That level could identify testnet but as well an alt coin chain.

Above leads me thinking that testnet is far less important than to be addressed in every future BIP.

Regards,

Tamas Blummer
http://bitsofproof.com

On 22.04.2014, at 19:07, Jan Møller <jan.moller at gmail.com> wrote:

> Treating testnet differently is quite the norm, we have that in BIP 32, 38, 70, SIPA private keys (no BIP for that I guess), bitcoin addresses etc. At the same time none of them define values for alt coins as far as I recall.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/b51096da/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/b51096da/attachment.sig>;

📅 Original date posted:2014-04-22 📝 Original message:Extra ...

2023-06-07T17:17:13+02:00

In reply to nevent1q…48q0
_________________________

📅 Original date posted:2014-04-22
📝 Original message:Extra encoding for testnet is quite useless complexity in face of many alt chains.
BIPS should be chain agnostic.

Regards,

Tamas Blummer
http://bitsofproof.com

On 22.04.2014, at 10:35, Matt Whitlock <bip at mattwhitlock.name> wrote:

> On Tuesday, 22 April 2014, at 4:11 am, Matt Whitlock wrote:
>> On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote:
>>> - I think it is very useful to define different prefixes for testnet
>>> keys/seeds. As a developer I use the testnet every day, and many of our
>>> users use it for trying out new functionality. Mixing up keys meant for
>>> testnet and mainnet is bad.
>>
>> A fair point. I'll add some prefixes for testnet.
>
> Testnet encodings are added: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/00dd9e11/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/00dd9e11/attachment.sig>;

📅 Original date posted:2014-04-22 📝 Original message:I use ...

2023-06-07T17:17:13+02:00

In reply to nevent1q…29fq
_________________________

📅 Original date posted:2014-04-22
📝 Original message:I use several test chains while testing my software, the official test net, a standalone net in house and even chains only created on the fly for unit tests. I found no use of distinguishing serialization of keys while using any of them.

If you have some deep insights about why this is needed share it, as I am not goint to guess your valuable thoughts.

Regards,

Tamas Blummer
http://bitsofproof.com

On 22.04.2014, at 17:32, Mark Friedenbach <mark at monetize.io> wrote:

> Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
> Unfortunately few of the alts ever figured this out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/4f3b8727/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/4f3b8727/attachment.sig>;

📅 Original date posted:2014-04-01 📝 Original message:While ...

2023-06-07T17:16:56+02:00

In reply to nevent1q…ruk7
_________________________

📅 Original date posted:2014-04-01
📝 Original message:While at that let's allow coin bases to be merged from orphan blocks,
so miner are fairly rewarded even if unlucky.

On 01.04.2014, at 21:00, Pieter Wuille <pieter.wuille at gmail.com> wrote:

> Hi all,
>
> I understand this is a controversial proposal, but bear with me please.
>
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696
>
> Please comment!
>
> Thanks,
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140401/c1635d40/attachment.sig>;

📅 Original date posted:2014-03-29 📝 Original message:I also ...

2023-06-07T17:16:41+02:00

In reply to nevent1q…d6w2
_________________________

📅 Original date posted:2014-03-29
📝 Original message:I also think that we can add usability features if the underlying secret remains well protected.
I do not think there is any reason to assume that the knowledge of the degree of the polynomial, would aid an attacker.

Similarly a fingerprint of the secret if it is unrelated to the hash used in the polinomyal should leak no useful information,

The length of such fingerpring (say 4 bytes) and the degree (1 byte) does not seem a big overhead for me.

Remember that the biggest obstacle of Bitcoin is usability not security.

Regards,

Tamas Blummer
http://bitsofproof.com

On 29.03.2014, at 18:52, Alan Reiner <etotheipi at gmail.com> wrote:

> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
>
> I do not believe this is a good tradeoff. It's basically obfuscation of
> something that is already considered secure at the expense of
> usability. It's much more important to me that the user understands
> what is in their hands (or their family members after they get hit by a
> bus), than to obfuscate the parameters of the secret sharing to provide
> a tiny disadvantage to an adversary who gets ahold of one.
>
> The fact that it fails silently is really all downside, not a benefit.
> If I have enough fragments, I can reconstruct the seed and see that it
> produces addresses with money. If not, I know I need more fragments.
> I'm much more concerned about my family having all the info they need to
> recover the money, than an attacker knowing that he needs two more
> fragments instead of which are well-secured anyway.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/ad76bea3/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/ad76bea3/attachment.sig>;

📅 Original date posted:2014-03-29 📝 Original message:This ...

2023-06-07T17:16:37+02:00

In reply to nevent1q…al2h
_________________________

📅 Original date posted:2014-03-29
📝 Original message:This is why my motivation is rather secure backup, not multisig. Instead of storing encrypted seed in one location and the passphrase for it in an other location, one can just store two shares in two places.

> Right - the explanation in the BIP about the board of directors is IMO a little misleading. The problem is with splitting a private key is that at some point, someone has to get the full private key back and they can then just remember the private key to undo the system. CHECKMULTISIG avoids this.
>
> I can imagine that there may be occasional uses for splitting a wallet seed like this, like for higher security cold wallets, but I suspect an ongoing shared account like a corporate account is still best off using CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et al.
>
>
> On Sat, Mar 29, 2014 at 2:27 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> The comparison with multisig fails to mention that multi-signature
> transactions explicitly define security at the transaction level.
> This permits fine-grained specificity of what a key holder may
> approve.
>
> Shamir is much more coarse-grained. You reconstitute a private key,
> which may then be used to control anything that key controls. Thus,
> in addition to Shamir itself, you need policies such as "no key
> reuse."
>
> My first impression of Shamir many moons ago was "cool!" but that's
> since been tempered by thinking through the use cases. Shamir has a
> higher D.I.Y. factor, with a correspondingly larger surface of
> things-that-could-go-wrong, IMO.
>
> (None of this implies making an informational BIP lacks value; I'm all
> for an informational BIP)
>
>
>
>
> On Sat, Mar 29, 2014 at 7:54 AM, Chris Beams <chris at beams.io> wrote:
> > Enlightening; thanks, Matt. And apologies to the list for my earlier inadvertent double-post.
> >
> > On Mar 29, 2014, at 12:16 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> >
> >> On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
> >>> Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense-in-depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.
> >>
> >> I have added two new sections to address your questions.
> >>
> >> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
> >
> >
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/6c333492/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/6c333492/attachment.sig>;

📅 Original date posted:2014-03-29 📝 Original message:I had ...

2023-06-07T17:16:35+02:00

In reply to nevent1q…n0xv
_________________________

📅 Original date posted:2014-03-29
📝 Original message:I had Matt's answer already, see below, but then I recognized that the group was not cc:-d, so I repeat:

It would help on the user interface to include into individual shares:

1. Number of shares needed
2. A few bytes fingerprint of the secret so shares that likely belong together can be identified.

I wonder how others weight security vs. usability in these questions.

Regards,

Tamas Blummer
http://bitsofproof.com

On Saturday, 29 March 2014, at 6:22 pm, Tamas Blummer wrote:
> It might make sense to store the number of shares needed. I know it is not needed by math, but could help on user interface to say,
> you need x more shares..

I intentionally omitted that information because it's a security risk. If an adversary gains control of one share and can see exactly how many more shares he needs, he may be able to plan a better attack. If he is clueless about how many shares he needs, then he may not be able to execute an attack at all because he may not know whether his information about what shares exist and where is complete.

On 29.03.2014, at 17:54, Matt Whitlock <bip at mattwhitlock.name> wrote:

> On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
>> I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
>> Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.
>
> I have expanded the BIP so that it additionally applies to BIP32 master seeds of sizes 128, 256, and 512 bits.
>
> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> The most significant change versus the previous version is how the coefficients of the polynomials are constructed. Previously they were SHA-256 digests. Now they are SHA-512 digests, modulo a prime number that is selected depending on the size of the secret.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/7d985b90/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/7d985b90/attachment.sig>;

📅 Original date posted:2014-03-29 📝 Original message:Hi ...

2023-06-07T17:16:34+02:00

In reply to nevent1q…346u
_________________________

📅 Original date posted:2014-03-29
📝 Original message:Hi Matt,

I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.

Regards,

Tamas Blummer
http://bitsofproof.com

On 29.03.2014, at 09:05, Matt Whitlock <bip at mattwhitlock.name> wrote:

> Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares.
>
> Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/954dee5e/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/954dee5e/attachment.sig>;

📅 Original date posted:2014-03-29 📝 Original message:Great ...

2023-06-07T17:16:34+02:00

In reply to nevent1q…yv4s
_________________________

📅 Original date posted:2014-03-29
📝 Original message:Great stuff Matt!

I have an implementation of Shamir's Secret Sharing here: https://github.com/bitsofproof/bop-bitcoin-client-misc/blob/master/src/main/java/com/bitsofproof/supernode/misc/ShamirsSecretSharing.java

What was missing was nice serialization. Thanks a lot for defining and starting the process.

I will shortly adapt my code and check your test vectors.

Regards,

Tamas Blummer
http://bitsofproof.com

On 29.03.2014, at 09:05, Matt Whitlock <bip at mattwhitlock.name> wrote:

> Abstract: A method is described for dividing a Bitcoin private key into shares in a manner such that the key can be reconstituted from any sufficiently large subset of the shares but such that individually the shares do not reveal any information about the key. This method is commonly known as Shamir's Secret Sharing Scheme. Additionally, an encoding methodology is proposed to standardize transmission and storage of shares.
>
> Complete BIP: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> I am looking to have this BIP assigned a number and added to the bitcoin/bips repository. I invite any comments, questions, or suggestions.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/8a7b3715/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/8a7b3715/attachment.sig>;

📅 Original date posted:2014-03-27 📝 Original message:I ...

2023-06-07T17:16:18+02:00

In reply to nevent1q…3h7g
_________________________

📅 Original date posted:2014-03-27
📝 Original message:I think not all alts (will) have magic numbers, at least not those defined e.g. with colored coins on top of an other chain.

Also note that the index should have MSB cleared as it would otherwise indicate private derivation.

Regards,

Tamas Blummer
http://bitsofproof.com

On 27.03.2014, at 16:57, Allen Piscitello <allen.piscitello at gmail.com> wrote:

> Don't most of these coins have a magic number already assigned that is unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for Litecoin, etc...). This seems like a good candidate for identifying coins, and also supports Testnet cases well. Maybe there are some alts without such a magic number that might prevent that?
>
> -Allen
>
>
> On Thu, Mar 27, 2014 at 10:43 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> > A notable suggestion was to instead of building a directory of magic numbers
> > (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> > "Litecoin", "Dogecoin", so collosion is unlikely and
> > cetral directory is not needed.
>
> +1 good idea
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/1242a957/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/1242a957/attachment.sig>;

📅 Original date posted:2014-03-27 📝 Original message:We had ...

2023-06-07T17:16:16+02:00

In reply to nevent1q…sl4v
_________________________

📅 Original date posted:2014-03-27
📝 Original message:We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof)
at the Inside Bitcoin Conference in Berlin.

I remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be "standardized" for the retail customer but definitelly not for corporate use,
where hierarchy will certainly map to organisational hierarchy or cost centres.

A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and
cetral directory is not needed.

Regards,

Tamas Blummer
http://bitsofproof.com

On 26.03.2014, at 21:49, Mike Hearn <mike at plan99.net> wrote:

> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with:
>
> /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
> cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't.
>
> More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the "raw" money and it will just ignore/not see the keys used in more complex transactions.
>
> reserved is for "other stuff". I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas?
>
> account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that.
>
> change is 0 for receiving addresses, 1 for change addresses.
>
> n is the actual key index
> For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support.
>
> Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/6c47bae7/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/6c47bae7/attachment.sig>;

📅 Original date posted:2014-03-13 📝 Original message:BTW, ...

2023-06-07T17:15:38+02:00

In reply to nevent1q…8fj9
_________________________

📅 Original date posted:2014-03-13
📝 Original message:BTW, its not like this would be the first time this was raised, instead the "ship left" while ignoring arguments.

The idea of is up there for votes since March 2013 https://bitcointalk.org/index.php?topic=149150.0
and received the most votes.

I remembered this last time on this list here:

http://sourceforge.net/p/bitcoin/mailman/message/31640769/

Regards,

Tamas Blummer
Founder, CEO
Bits of Proof
http://bitsofproof.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/97375e0e/attachment.sig>;

📅 Original date posted:2014-03-13 📝 Original message:On ...

2023-06-07T17:15:35+02:00

In reply to nevent1q…sxsk
_________________________

📅 Original date posted:2014-03-13
📝 Original message:On 13.03.2014, at 17:14, Alan Reiner <etotheipi at gmail.com> wrote:

> We've been working with Marty Zigman who's creating a Bitcoin plugin for
> NetSuite accounting platform, and he was already forced to switch
> micro-BTC long ago for exactly the reasons described above. I think the
> system will track up to 3 decimal places without causing all sorts of
> heartache and automatic rounding.
>
> Of course, as Mike said, this ship may have already sailed, but if
> there's any way to revisit this, I'm there. We're just about to do
> another Armory release and could support this very easily.
>

Not suprised that people dealing with real world finance problems
and people who are not engineers come to the same conclusion.
Welcome Alan!

Why not add 'bit' as an option or even default to Armory?

Regards,

Tamas Blummer
Founder, CEO
Bits of Proof
http://bitsofproof.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/3594aaa8/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/3594aaa8/attachment.sig>;

📅 Original date posted:2013-06-20 📝 Original message:Yes it ...

2023-06-07T17:03:47+02:00

In reply to nevent1q…ayv9
_________________________

📅 Original date posted:2013-06-20
📝 Original message:Yes it is trivial. I do not think greater complexity in the system should keep us from addressing low complexity issues.
You can't blame me or others not trying to simplify scripts, if there is such a headwind simplifying a version message.
You are right there is too much fuss about this.

Tamás Blummer
Founder, CEO
http://bitsofproof.com

On 20.06.2013, at 10:31, Mike Hearn <mike at plan99.net> wrote:

> You can't eliminate the complexity (yet), otherwise you wouldn't be able to talk to old nodes. You'll have to wait until versions prior to a particular version are hard-forked off and can be safely dropped at connect time.
>
> That said the reason I'm being so grumpy about this is that compared to the complexity in the rest of the system, this is such a trivial and minor detail. It's hardly even worth thinking about. I mean, we have a scripting language full of opcodes nobody ever figured out how to use and the protocol uses a mixture of byte orders, so an optional field in the version message is really not such a big deal :)
>
>
> On Thu, Jun 20, 2013 at 10:17 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> I agree that this can be deferred until there is an actual new field without any harm. But then remember to update the BIP37 too saying that it is optional only if flag added in BIPXX is not present.
>
> Your argument is that this complexity is already there so why not preserve it. I think eliminating complexity (that has no benefit) strengthens the system.
>
> Tamás Blummer
> http://bitsofproof.com
>
> On 20.06.2013, at 09:36, Mike Hearn <mike at plan99.net> wrote:
>
>> Sure but why not do that when there's an actual new field to add? Does anyone have a proposal for a feature that needs a new version field at the moment? There's no point changing the protocol now unless there's actually a new field to add.
>>
>> Anyway I still don't see why anyone cares about this issue. The Bitcoin protocol does not and never has required that all messages have a fixed number of fields per version. Any parser written on the assumption it did was just buggy. Look at how tx messages are relayed for the most obvious example of that pattern in action - it's actually the raw byte stream that's stored and relayed to ensure that fields added in new versions aren't dropped during round-tripping. Old versions are supposed to preserve fields from the future.
>>
>>
>>
>> On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> Hi Mike,
>>
>> The issue with the current parser is that those fields are conditionally optional on that there will be no subsequent fields added.
>> If there will be further fields they will become manadory.
>>
>> Why not bump the version and parse the fields as mandatory from then on? This would be backward compatible and cleaner
>> going forward.
>>
>> Tamas Blummer
>> http://bitsofproof.com
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130620/652c48ba/attachment.html>;

📅 Original date posted:2013-06-20 📝 Original message:I ...

2023-06-07T17:03:46+02:00

In reply to nevent1q…99we
_________________________

📅 Original date posted:2013-06-20
📝 Original message:I agree that this can be deferred until there is an actual new field without any harm. But then remember to update the BIP37 too saying that it is optional only if flag added in BIPXX is not present.

Your argument is that this complexity is already there so why not preserve it. I think eliminating complexity (that has no benefit) strengthens the system.

Tamás Blummer
http://bitsofproof.com

On 20.06.2013, at 09:36, Mike Hearn <mike at plan99.net> wrote:

> Sure but why not do that when there's an actual new field to add? Does anyone have a proposal for a feature that needs a new version field at the moment? There's no point changing the protocol now unless there's actually a new field to add.
>
> Anyway I still don't see why anyone cares about this issue. The Bitcoin protocol does not and never has required that all messages have a fixed number of fields per version. Any parser written on the assumption it did was just buggy. Look at how tx messages are relayed for the most obvious example of that pattern in action - it's actually the raw byte stream that's stored and relayed to ensure that fields added in new versions aren't dropped during round-tripping. Old versions are supposed to preserve fields from the future.
>
>
>
> On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> Hi Mike,
>
> The issue with the current parser is that those fields are conditionally optional on that there will be no subsequent fields added.
> If there will be further fields they will become manadory.
>
> Why not bump the version and parse the fields as mandatory from then on? This would be backward compatible and cleaner
> going forward.
>
> Tamas Blummer
> http://bitsofproof.com
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130620/b1e7c9e1/attachment.html>;

📅 Original date posted:2013-06-20 📝 Original message:Hi ...

2023-06-07T17:03:45+02:00

In reply to nevent1q…p3vq
_________________________

📅 Original date posted:2013-06-20
📝 Original message:Hi Mike,

The issue with the current parser is that those fields are conditionally optional on that there will be no subsequent fields added.
If there will be further fields they will become manadory.

Why not bump the version and parse the fields as mandatory from then on? This would be backward compatible and cleaner
going forward.

Tamas Blummer
http://bitsofproof.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130620/3b03828f/attachment.html>;