Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    David Burkett
    @DavidBurkett
    I propose we hire someone to wrangle all this moon math and use it to our advantage. I'd love to hear everyone's thoughts. https://www.grin-forum.org/t/request-for-funding-jrandomcryptographer/6056
    Antioch Peverell
    @antiochp
    yeah given how fast things appear to be progressing in the research here, our best approach might just be to wait patiently for a few months and somebody will announce a drop-in replacement for bulletproofs that we can use
    David Burkett
    @DavidBurkett
    That would be great!
    Jacks
    @JakobAbf_twitter
    Can anybody tell me on which elliptic curve Grin operates? It's not secp256k1 is it?
    jaspervdm
    @jaspervdm
    it is
    Jacks
    @JakobAbf_twitter
    ohh that's great! Thanks for the reply
    Antioch Peverell
    @antiochp
    https://eprint.iacr.org/2019/1076 "Fractal: Post-Quantum and Transparent Recursive Proofs from Holography"
    Dev Random
    @devrandom
    hi. I'm trying to understand what the blocks commit to. it seems that when an output is consumed, it is removed from the index, but not from the MMR. this means that the commitment in the block is not to to the set of unspent TXOs, but to all historical TXOs spent and unspent. is that right?
    David Burkett
    @DavidBurkett
    Yes, correct. The MMR root is a commitment to the entire TXO set
    But we also commit to the MMR root of the kernel set (never pruned). So after downloading the utxo and kernel set, you can verify the utxo set is correct because you can perform the big mimblewimble sum to make sure the supply is correct
    Dev Random
    @devrandom
    I see. so the kernel MMR covers the set of spent TXOs?
    David Burkett
    @DavidBurkett
    No not quite, the kernels aren't UTXOs.
    Dev Random
    @devrandom
    thank you
    Dev Random
    @devrandom
    well, reading that (again), it seems like that only validates the sum of the UTXOs, but not the specific UTXO set. I'm probably misunderstanding something, will look at the code tomorrow
    Antioch Peverell
    @antiochp
    @devrandom your intuition here is right - each header commits to both the root of the output MMR (spent and unspent outputs) and the root of the kernel MMR. The kernels verify that the sum of unspent outputs matches the total supply. So as you say we validate the sum of the UTXO, not the specific UTXO set.
    Dev Random
    @devrandom
    isn't that an issue? i.e. if a node starts up, and the p2p neighbors lie about what UTXOs are active (while preserving the sum), they can get the node to accept a transaction that double spends an output?
    energyburn
    @energyburn
    @devrandom it would be statistically improbable for a malicious node to find a fake kernel set and "lie" about what UTXOs are active. Remember, these arent classical UTXOs, but Pederson commitments. To create a fake set of commitments, you would need to solve the discrete logarithm of ecc points (extremely difficult)
    Dev Random
    @devrandom
    OK, sounds like I need to study this more, thank you for pointing me in the right direction
    lehnberg
    @lehnberg
    David Burkett
    @DavidBurkett
    Paper looks like gibberish. It must be really fast and secure!
    Jacks
    @JakobAbf_twitter
    Hi is there some documentation around on how the range proofs in a Grin transaction file are (de)serialized, or do I need to look into the code?
    I would like to build bulletproofs which are compatible with Grin, which is why I am asking.
    David Burkett
    @DavidBurkett
    You'll probably need to look at the code (see: secp256k1-zkp). I'm not aware of any documentation around that.
    @jaspervdm Are you aware of anywhere that's documented?
    jaspervdm
    @jaspervdm
    There’s not really documentation specifically about the (de)serialization
    Jacks
    @JakobAbf_twitter
    Okay thanks for the response I will look into secp256k1-zkp to figure this out. What ranges are used in Grin for the proofs by the way. Is it always 0 and current max supply in Nanogrin?
    David Burkett
    @DavidBurkett
    0 to 2^64-1 nanogrins, I believe
    Jacks
    @JakobAbf_twitter
    thanks, would make sense
    John Tromp
    @tromp
    i once pondered making it 0-2^48-1 to discourage individuals from holding too much grin, but apparently that would give negligible savings on the bulletproofs
    David Burkett
    @DavidBurkett
    Yea, just a couple bytes I believe. I was surprised by how large of a range we supported until I realized it was only marginally larger than 2^32-1
    John Tromp
    @tromp
    2^48 nanogrin is about $281K worth of Grin
    or 3.25 days
    Zack
    @zack-bitcoin

    Hello.
    I am interested in using something like mimble wimble for a lottery application.
    I want users to be able to spend fractions of their lottery tickets without writing anything on-chain.

    Is this a reasonable application?
    When someone finally wins, how much data do they need to write on-chain to claim their winnings?
    What would that data look like?

    I wrote about it here, but the documentation is written in the context of someone learning about that blockchain. https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/sortition_chains.md
    It is probably more helpful if I explain directly here.

    Ethereum is currently using a patricia merkel tree to keep track of account balances.
    mimble wimble is an alternative protocol to keep track of account balances.
    but I want to keep almost all the mimble wimble stuff off-chain, and only publish the minimal slice of it to show who won the lottery.

    John Tromp
    @tromp
    not directly relevant to grin, but interesting nevertheless: https://www.chia.net/2019/11/27/chialisp.en.html
    Gary Yu
    @garyyu
    @GandalfThePink I read again your document “BLS signatures in Mimblewimble" here: https://github.com/mimblewimble/grin/issues/2504#issuecomment-467446197. I look into your non-interactive transaction proposal, but I don’t find the range proof part, how do you create the range proof for your non-ingteractive transaction output?
    kurt coolman
    @coolman_kurt_twitter
    I think there is no need for range proof in Gandalf's proposal as the pedersen commit in the output of the tx is described in the paper as non blinded (r = 0) and hence takes the form vL. As a consequence one could verify that 1) no money is created 2) v is positive (to verify just try all vL' possible until you find v_0 such as v_0*L is equal to the Pedersen commit and check that this v_0 is a allowed value for the tx)
    kurt coolman
    @coolman_kurt_twitter
    If you want to keep Confidential Tx you could make a system where the sender creates the outputs of the receiver of the tx, including the blinded factors and signs alone the kernel offset minus the receiver's address (Gandalf adds address for allowing his BLS MW system). He then gives (onchain) the blinded factors of Bob Outputs to Bob in some sort of shared secret so that Bob can spend his output later. But then the sender can steal Bob's output since it is him who created the output for Bob including and he knows Bob's blinded factor ? Not if we do a protocol where the receiver also has to sign his address on top of knowing his blinded factor to spend his output, making it not possible for the sender to steal coins (the sender does not know the private key to the receiver 's address)
    kurt coolman
    @coolman_kurt_twitter
    Maybe it is not very secure, because the sender could chose trivial values for the receiver's blinded factors, such as 0 or whatever and it could be a concern for privacy. idk
    kurt coolman
    @coolman_kurt_twitter
    and still in the case of CT, how to be convinced that the sender sends the correct blinded factor to the receiver without pre communication between the two...idk
    Gary Yu
    @garyyu

    @coolman_kurt_twitter

    I think there is no need for range proof in Gandalf's proposal as the pedersen commit in the output of the tx is described in the paper as non blinded (r = 0) and hence takes the form vL.

    I don’t think so, because the excess is still needed there and Bob’s public key P_b might contain some term proportional of H component.

    I wrote one page of review:
    Screen Shot 2020-01-22 at 8.59.49 AM.png
    Gary Yu
    @garyyu
    kurt coolman
    @coolman_kurt_twitter
    the commitments are all on chain ? Nodes can try to find the preimages (with respect to multiplication by L) to each commitments that belong to the outputs of the tx. If there exists commitments such as no positive preimage is found within a predefined - reasonable - range, deem tx invalid
    maybe missing stuff