Re: [Mimblewimble] Compact blocks

dear Igno, > In this discussion, I'm only interested in the size of a block when sent > across the wire during propagation. It's desirable in this context to have > small block sizes (in bytes) so that blocks can traverse the network quickly > without causing too much additional traffic. As most

[Mimblewimble] Fwd: Potentional method of hardforking MimbleWimble via freaky invalid to valid block transitions

> Ok, so I think where we're headed is: > > - We should generalize blocks to "frankenblocks" which are ranges of > consecutive blocks where cutthrough inputs and outputs are pruned > > - We should have a better name for frankenblock :) I somewhat disagree. We don't need new kinds of

Re: [Mimblewimble] A ransomware attack on MimbleWimble with Schnorr signatures

dear imblers, > Each output has a rangeproof consisting of several ring signatures > corresponding to different denominations that sum to the hidden value > (see [1] [2]). > For binary denominations, each such ring signature is of the form > (e0,s0,s1) satisfying, for some P0,P1 differing by 2^i

[Mimblewimble] A ransomware attack on MimbleWimble with Schnorr signatures

dear imblers, While discussing kernel signatures and possible optimizations with Igno, I got this idea about how to single-handedly turn ordinary outputs into 2-of-2 outputs with myself as additional recipient, effectively holding them at ransom. Note that this attack seems limited to the use of

Re: [Mimblewimble] defending against malicious transactors

> I agree with the need to enable non-repudiation in transactions. I > originally had a simpler scheme in mind (basically the sender adds a nonce > to the blinding factor, the receiver puts his blinded output, the sender > subtracts the nonce*G from total and builds the sig) but there may be >

Re: [Mimblewimble] Compact blocks

dear Igno, >> The second largest piece of data is composed of the transaction kernels >> (~100 bytes each). We can't fully avoid sending those as they're not >> "anchored" on anything, like the range proof is anchored on an output. >> However we could send a shortened version of their hash. In

Re: [Mimblewimble] Scriptless scripting and deniable swaps

A while ago I had a chat with Andrew in https://gitter.im/grin_community/Lobby where he helped explain multi signature transactions to me, and I thought it might benefit others as well to explain the atomic swap below in more detail. So the setting is that Igno holds some coins on the MW

Re: [Mimblewimble] Status and how to help

dear John, > Thanks for the update. Just curious, what's the time tradeoff for that 20x > memory? This optimization becomes difficult, especially on GPU, over Cuckoo > 30, correct? The speedup is about 4x on a cpu. But since the solver becomes more similar to an Equihash solver (both dominated

Re: [Mimblewimble] Compact blocks

dear Igno, > BIP152 introduced a good solution by introducing short transaction ids > (which we can generalize to inputs/outputs/kernels): > > https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#Short_transaction_IDs > > It does force a full re-hashing of the pool on each block but

Re: [Mimblewimble] Branding and messaging

dear imblers, I'm happy with the name "grin" for both the implementation and the coin. Naming of the smallest unit is not that important, and we could just go with nanogrin if we deviate from the 10^-8 subdivision by adopting the more metric compatible 10^-9 subdivision. Otherwise, I'm also fine

[Mimblewimble] On block rewards

dear all, In the very first message to this list, I made a proposal for a block reward schedule, involving some exponential stepping. In retrospect that seems overly complicated. The simplest possible schedule, namely a fixed constant block reward, probably works well enough. It's also what

Re: [Mimblewimble] On fees

> Transaction fees are mostly a mechanism to prevent transaction flooding. The block size limit should be the primary mechanism for that. > Space and bandwidth in a blockchain network are scarce resources and free > transactions would lead to abuse. The abuse would be due to a lack of

Re: [Mimblewimble] On block rewards

> BUT, observing implied chain intrinsic interest rate is impossible without > on-chain transfer of ownership of those zero bonds. Transfer of ownership is > however prohibited until maturity, at which point the zero bond becomes > cash. If a transfer before maturity was possible, then those new

Re: [Mimblewimble] On block rewards

On Sun, Oct 1, 2017 at 3:10 PM, Garrick Ollivander wrote: > Let's assume we want 0% dilution after grin reaches Visa like 2000 tx/s use > use with a block time of 10 seconds, That's completely unrealistic. Bandwidth wise, grin scales worse than bitcoin, with

Re: [Mimblewimble] On block rewards

dear Seamus, > The 7 years of rewards, plus the many hints at eventually switching to Proof > of Stake and reducing rewards, make Ethereum an altogether bad point of > comparison. Around 72 million coins were distributed via the crowdfunding > sale and to the foundation/developers. Then another

Re: [Mimblewimble] On block rewards

On Mon, Oct 2, 2017 at 8:53 AM, Alessandro Viganò wrote: > Right now is important to design a good monetary policy but not a perfect > one. I believe it’s impossible to foresee what is coming in years. So some > flexibility is needed, and, in any case, the ultimate

Re: [Mimblewimble] On block rewards

> I'll compare with bitcoin which I guess most > people consider the "standard" supply schedule. > > If you run the numbers, assuming you acquired bitcoin at the end of the > first year, at the end of year 10 (which is coming fast) you will be diluted > by a factor of 6.5. Now with a flat coin

Re: [Mimblewimble] Elapsed-Time-Scaled Block Size

> Wouldn't this create an incentive for a miner to include all transactions > with fees attached from the mempool and publish the block with a time stamp > enough in the future to allow that size of block? Yes, it clearly provides incentives to lie about timestamps, which I think is enough to

Re: [Mimblewimble] On block rewards

On Thu, Nov 2, 2017 at 3:39 PM, John Tromp <john.tr...@gmail.com> wrote: > The attached plot summarizes how the bitcoin emission compares to that of grin > over the first 200 years, assuming a 2% yearly loss of coins. Here's the same plot, as well as one for inflation, as a gif. May

Re: [Mimblewimble] logo design

A little close to Gold Coin's perhaps https://www.gldcoin.com/ On Thu, Nov 9, 2017 at 10:06 AM, Fola Adejumo wrote: > Hi All > > > I have some logo updates. See attached. > > Let me know your thoughts. > > > Thanks in advance, > > > > -- >

Re: [Mimblewimble] On block rewards

On Thu, Nov 2, 2017 at 3:36 PM, John Tromp <john.tr...@gmail.com> wrote: > dear grinners, > The attached plot summarizes how the bitcoin emission compares to that of grin > over the first 200 years, assuming a 2% yearly loss of coins. Oops; forgot to attach... bitcoin.grin.02.

Re: [Mimblewimble] Discreet Log Contracts

dear Ruben, > Olivia will publish "yes" or "no" under her key O and commitment R. > > This means there are two possible values for S: > > S1 = R + hash(R, "yes")*O > S2 = R + hash(R, "no")*O > > Alice and Bob create a payment channel under key A + B = C with 1 BTC each. > > They propose two

[Mimblewimble] PoW with memory requirement upgrades by soft fork

A few days ago I wondered if grin could accept not only cuckoo30 solutions, but cycles in larger graphs as well. A cuckoo31 graph for instance has twice as many nodes, and takes about twice as much effort to search. But scaling the difficulty only by half provides little incentive to work on

Re: [Mimblewimble] Fee burning and Dynamic Block Size

dear Ignotus, > I like the idea, it's simple and elegant and seems to put the right > incentives in place. > > I don't like that it relies on burn. It puts us between a rock and a hard > place as we either: > > * Materialize the burn as specific outputs and keep them forever, bloating > the

[Mimblewimble] Fwd: Fee burning and Dynamic Block Size

dear Igno, >> Should we give up on the possibility to burn coins, and give up on >> incentivizing small blocks, because of the perceived complexity of >> a subtraction? > > There's a little more complexity involved. First, you have to think about > fast-synced pruned nodes. They have to know

Re: [Mimblewimble] Fee burning and Dynamic Block Size

> Is the total miner reward calculated as: BaseReward - Burn [BaseReward * (N > / MaxN)^2] + N * TxFee ? That's a simplification of the general formulation where all transactions have the same #inputs, #outputs, #kernels, and fee. The burning can be implemented either as a reduction in reward, or

[Mimblewimble] Fee burning and Dynamic Block Size

Grin testnet1 burns half the tx fee in an attempt to incentivize against block bloat. But this attempt fails since miners can still spam a block with their own 0-fee transactions, or accept user's 0-fee transactions while demanding an out-of-band fee payment that is not subjected to fee burning.

Re: [Mimblewimble] introduction

hi Luke, > current crypto-currencies with the exception of monero are based > around the principle of hiding... so of course they are being hunted > and hounded. monero and i believe grin-coin at least provide both > privacy *and traceability*, such that an individual may *prove* to > their

Re: [Mimblewimble] "Pay-to-Address" / "Pay-to-Public-Key": Non-Interactive Transaction Solution for Mimblewimble

dear Gary, > 5. Alice calculates (q*P) and attach it to the transaction kernel as the > restriction to spend its PTXO. ONLY who owns the private key of this public > (q*P) can spend this PTXO. > To summarize the difference of the transaction kernel between ITX and PTX, > PTX has 3 additional

[Mimblewimble] Wikipedia entry

I took a first stab at creating a MimbleWimble Wikipedia entry at https://en.wikipedia.org/wiki/MimbleWimble regards, -John -- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help :

Re: [Mimblewimble] Relative Locktimes in Grin

dear mimblewimblers, I'd like to propose a potential alternative way to implement relative time locks. It possibly qualifies as a "crazy idea" as Antioch alluded to below. It can be thought of as a negative trigger. I propose to call it a "No Such Kernel Recently" or NSKR lock. Suppose we have

[Mimblewimble] Fwd: Relative Locktimes in Grin

tial negative trigger. > Each instance of the kernel would delay the next instance for at least the > specified lockheight number of blocks. > > John Tromp wasted no time in naming this "No Recent Duplicate" or NRD locks. > > An NSKR kernel explicitly references a prior

[Mimblewimble] Mimblewimble CoinSwap proposal

A possible way of obscuring the Mimblewimble transaction graph with multi-party non-interactive coinswaps is described at https://forum.grin.mw/t/mimblewimble-coinswap-proposal Feedback is more than welcome. regards, -John -- Mailing list: https://launchpad.net/~mimblewimble Post to :