John Tromp [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-09-19 to 2023-06-03
💬 Posted a total of 12 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-22 14:20:56

- reply

📅 Original date posted:2023-08-21
🗒️ Summary of this message: Banning arbitrary data will lead to encoding data within public keys, making it indistinguishable and difficult to detect. Mimblewimble protocol already prevents spam encoding.
📝 Original message:
> 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

2023-06-07 23:22:05

- reply

📅 Original date posted:2023-06-03
🗒️ Summary of this message: White paper proposing Bitcoin PoW anchoring can be found on GitHub. Questions raised about miner behavior and consensus on protocol reset.
📝 Original message:> 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).

2023-06-07 23:18:07

- reply

📅 Original date posted:2023-01-22
🗒️ Summary of this message: Transaction rewards are currently $63, which is two orders of magnitude higher than typical fees that are usually over $0.50.
📝 Original message:> 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

2023-06-07 23:11:47

- reply

📅 Original date posted:2022-07-13
📝 Original message:> 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

2023-06-07 23:11:47

- reply

📅 Original date posted:2022-07-13
📝 Original message:> 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.

2023-06-07 23:11:32

- reply

📅 Original date posted:2022-07-10
📝 Original message:A parallel discussion is taking place at
https://bitcointalk.org/index.php?topic=5405755.0

2023-06-07 23:11:25

- reply

📅 Original date posted:2022-07-09
📝 Original message:> 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

2023-06-07 23:08:43

- reply

📅 Original date posted:2022-05-06
📝 Original message: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

2023-06-07 22:58:03

- reply

📅 Original date posted:2021-08-10
📝 Original message:> 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 `<saltpoint> <0> OP_EQUAL OP_NOT` with `<saltpoint>` 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

2023-06-07 18:27:09

- reply

📅 Original date posted:2020-09-25
📝 Original message: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

2023-06-07 18:20:42

- reply

📅 Original date posted:2019-09-20
📝 Original message:> 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

2023-06-07 18:20:39

- reply

📅 Original date posted:2019-09-19
📝 Original message:> However, I believe that Lightning and similar offchain protocols are **not possible** on MimbleWimble, at least if we want to retain its "magical shrinking blockchain" property.
MimbleWimble can easily incorporate relative lock heights, in addition
to absolute lock heights. Grin and Beam have included the latter since
launch.
Grin's proposal for relative lock heights is at [1] with discussion at [2].
Based on these, Grin also has a rough design for payment channels at [3].
Beam included relative lock heights in its recent HardFork [4] and has
a payment channel design at [5].
regards,
-John
[1] https://github.com/antiochp/grin-rfcs/blob/relative_lock_heights/text/0000-relative-kernels.md
[2] https://github.com/mimblewimble/grin-rfcs/pull/19
[3] https://gist.github.com/antiochp/e54fece52dc408d738bf434a14680988
[4] https://github.com/BeamMW/beam/releases/tag/beam-3.0.5654
[5] https://docs.beam.mw/laser_beam.pdf

2023-06-07 18:20:39

- reply

📅 Original date posted:2019-09-19
📝 Original message:dear ZmnSCPxj,
> Which I suppose is my point: you lose some of the "magic shrinking blockchain" property in implementing relative locktimes, as you now increase the data you have to store forever (i.e. the kernels).
The "magic shrinking" of MW never applied to kernels. To validate the
current UTXO set, you need to validate *all* the kernels, each of
which is a Pedersen commitment to zero together with a Schnorr
signature using said commitment as public key. Then you need to check
that the sum of UTXO commitments (outputs) minus the summed block
rewards times G (inputs) equals the sum of kernel commitments.
Basically, the same check that is applied to individual transactions.
> It seems to me that Poon-Dryja and Decker-Wattenhofer can be "directly" ported over to any MimbleWimble blockchain with relative locktimes.
> Reference [5] seems to be Poon-Dryja ported over to using relative locktimes for MimbleWimble.
Yes, Beam's design is a straightforward port of Poon-Dryja.
> Decker-Russell-Osuntokun ("eltoo") is harder due to the `SIGHASH_NOINPUT` requirement.
> I have tried to derive an equivalent to this `SIGHASH_NOINPUT` somehow by considering that the "reference to previous kernel" as being akin to the Bitcoin transaction input referring to a previous output, however it seems to be not easy to create a retargatable "reference to previous kernel" in this way.
The Grin "Elder channel" design of [3] is similar in spirit to eltoo
though, as the revocation transaction can be combined with the final
close transaction to counter any closing attempt to an obsolete state.
The design also offers some bandwidth savings compared to the
Poon-Dryja design.
> In any case, it seems to me that the loss of SCRIPT does not prevent a MimbleWimble blockchain from using an offchain updateable cryptocurrency system.
Correct; lack of scripts is not as much of a handicap for MW as it
appears. Multi-sig, atomic swaps, and payment channels are all
possible.
regards,
-John