Re: [bitcoin-dev] Concern about "Inscriptions"
> If we ban "arbitrary data", however you want to define it, then actors will > simply respond by encoding their data within sets of public keys. Public > key data is indistinguishable from random data, and, unless we are willing > to pad the blockchain with proof of knowledge of secret keys, there will be > no way to tell a priori whether a given public key is really a public key > or whether it is encoding an inscription or some other data. Note that in the Mimblewimble protocol, range proofs already prove knowledge of blinding factor in Pedersen commitments, and thus no additional padding is needed there to prevent the encoding of spam into cryptographic material. This makes pure MW blockchains the most inscription/spam resistant [1]. [1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
> The white paper describing the proposal can be found here: > https://github.com/LNP-BP/layer1/ Some questions about the Bitcoin PoW anchoring: What if a miner spends the current miner single-use-seal while creating a commitment, but makes the PMT only partially available, or entirely unavailable ? How do other miners reach consensus on whether a protocol reset is required? It seems impossible to agree on something like PMT availability (much like mempool contents). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Pseudocode for robust tail emission
> Right now the total reward per transaction is $63, three orders of magnitude > higher than typical fees. No need to exaggerate; this is only two orders of magnitude higher than current fees, which are typically over $0.50 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> There's only one coin whose expected (soft) emission time is larger > than bitcoin's, and it's about an order of magnitude larger, at 50 > years. Make that two coins. For DOGE it is 33 years. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> The emission curve lasts over 100 years because Bitcoin success state > requires it to be entrenched globally. It effectively doesn't. The last 100 years from 2040-2140 only emits a pittance of about 0.4 of all bitcoin. What matters for proper distribution is the shape of the emission curve. If you emit 99% in the first year and 1% in the next 100 years, your emission "lasts" over 100 years, and you achieve a super low supply inflation rate immediately after 1 year, but it's obviously a terrible form of distribution. This is easy to quantify as the expected time of emission which would be 0.99 * 0.5yr + 0.01* 51yr = 2 years. Bitcoin is not much better in that the expected time of emission of an bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. Monero appears much better since its tail emission yields an infinite expected time of emission, but if we avoid infinities by looking at just the soft total emission [1], which is all that is emitted before a 1% yearly inflation, then Monero is seen to actually be a lot worse than Bitcoin, due to emitting over 40% in its first year and halving the reward much faster. Ethereum is much worse still with its huge premine and PoS coins like Algorand are scraping the bottom with their expected emission time of 0. There's only one coin whose expected (soft) emission time is larger than bitcoin's, and it's about an order of magnitude larger, at 50 years. [1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
A parallel discussion is taking place at https://bitcointalk.org/index.php?topic=5405755.0 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
> New blog post: > https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary A Tail Emission is best described as disinflationary; the yearly supply inflation steadily decreases toward zero. > Dogecoin also has a fixed reward It started out with random rewards up to 1M doge per block, with the maximum halving every 100K blocks, until the fixed reward of 10K doge kicked in at height 600K. > If an existing coin decides to implement tail emission as a means to fund > security, choosing an appropriate emission rate is simple: decide on the > maximum amount of inflation you are willing to have in the worst case, and > set the tail emission accordingly. Any coin without a premine starts with infinite inflation. Bitcoin in its first 4 years had yearly inflation rates of inf, 100%, 50%, and 33%. So deciding on a maximum amount of inflation is deciding on a premine. While in the long term, a capped supply doesn't meaningfully differ from un uncapped supply [1], the 21M limit is central to Bitcoin's identity, and removing this limit results in something that can no longer be called Bitcoin. [1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted
On Fri, 6 May 2022 7:17PM Jorge Tim?n wrote > But let's not personally attack andreas for his opinions. > The only reason you don't like bip8 is because you're ignorant about it and > you haven't reviewed it enough. Can you see the irony in equating "clueless about BIP119" with a personal attack and then calling Jeremy ignorant about BIP8? -John ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Message-ID:
> Alternately, one possible softforkable design would be for Bitcoin to > maintain a non-CT block (the current scheme) and a separately-committed CT > block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that > includes witnesses). > When transferring funds from the legacy non-CT block, on the legacy block you > put it into a "burn" transaction that magically causes the same amount to be > created (with a trivial/publicly known salt) in the CT block. > Then to move from the CT block back to legacy non-CT you would match one of > those "burn" TXOs and spend it, with a proof that the amount you are removing > from the CT block is exactly the same value as the "burn" TXO you are now > spending. > (for additional privacy, the values of the "burn" TXOs might be made into > some fixed single allowed value, so that transfers passing through the CT > portion would have fewer identifying features) > > The "burn" TXOs would be some trivial anyone-can-spend, such as ` > <0> OP_EQUAL OP_NOT` with `` being what is used in the CT to cover > the value, and knowledge of the scalar behind this point would allow the CT > output to be spent (assuming something very much like MimbleWimble is used; > otherwise it could be the hash of some P2WSH or similar analogue on the CT > side). > > Basically, this is "CT as a 'sidechainlike' that every fullnode runs". > > In the legacy non-CT block, the total amount of funds that are in all CT > outputs is known (it would be the sum total of all the "burn" TXOs) and will > have a known upper limit, that cannot be higher than the supply limit of the > legacy non-CT block, i.e. 21 million BTC. > At the same time, *individual* CT-block TXOs cannot have their values known; > what is learnable is only how many BTC are in all CT block TXOs, which should > be sufficient privacy if there are a large enough number of users of the CT > block. > > This allows the CT block to use an unconditional privacy and computational > soundness scheme, and if somehow the computational soundness is broken then > the first one to break it would be able to steal all the CT coins, but not > *all* Bitcoin coins, as there would not be enough "burn" TXOs on the legacy > non-CT blockchain. > > This may be sufficient for practical privacy. This is pretty much the Mimble Wimble Extension Block (MWEB) design for Litecoin, as described at https://vaultoro.com/what-is-mweb-on-litecoin/ True to the Harry Potter background theme of Mimblewimble, the regular Litecoin transaction responsible for pegging into and out of the extension block is call the Hogwarts Express (hogex). If all goes well, it may activate as early as the end of this year... regards, -John ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Floating-Point Nakamoto Consensus (bitcoin ml)
Re: Floating-Point Nakamoto Consensus (bitcoin ml) > > This is a pretty big departure from cumulative POW. It's still cumulative. But instead of cumulating network difficulty, they cumulate log_2(solution difficulty). So if two solutions are found simultaneously, and one has a hash that's only half of the other, then that will have twice the solution difficulty and thus contribute 1 more the cumulate log_2(solution difficulty). > Could you explain to me what you see happening if a node with this patch > and no history starts to sync, and some random node gives it a block > with a better fitness test for say height 250,000? No other solution > will have a better fitness test at that height, so from my understanding > its going to stop syncing. How about even later - say this proposal is > activated at block 750,000. At 850,000, someone decides it'd be fun to > publish a new block 800,000 with a better fitness test. What happens the > 50,000 blocks? Nothing happens in these cases, as the new blocks are still far behind the tip in cumulative score (they just have higher score at their height). regards, -John ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 52, Issue 15
> However, my understanding is that, at least with the original > mimblewimble.txt from Jedusor, the signatures and the > Pedersen-commitment-to-0 could all be aggregated into a single signature and > Pedersen-commitment-to-0, if we were to use Schnorr-like signatures. Non-interactive aggregatability depends on the signature scheme. Schnorr doesn't support it, whereas something like BLS signatures does. The original paper excludes the use of the latter with the remark "And also imagine that we must not pairing-based cryptography or new hypotheses, just regular discrete logarithms signatures like Bitcoin." > Indeed, the original mimblewimble.txt mentions having to store every `k*G` > and every signature attesting to it, although does not mention Schnorr and > might not have considered the possibility of signature aggregation when using > Schnorr-like signatures. Schnorr signatures can only be aggregated interactively though, and is thus limited to individual transactions which are built interactively. > In addition, the mimblewimble.pdf from andytoshi includes a "Sinking > Signatures" section, which to my understanding, combines absolute-locktime > kernels with partial O(log n) aggregation of the signatures that attest it. I must admit to never having quite understood Sinking Signatures, but they were deemed to have too many drawbacks for practical use. > It seems to me that neither technique is possible with relative locktime > kernels. Kernels already sign for optional additional attributes such as fee and lock height. A relative kernel would just add a reference to another kernel as an additional attribute. Which doesn't seem to affect its aggregatability. -John ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
