These are chat archives for grin_community/dev

8th
Aug 2018
Simon B.
@sesam
Aug 08 2018 04:46 UTC
:+1:
Casey Rodarmor
@casey
Aug 08 2018 05:27 UTC
Comment from the peanut gallery after reading the dev meeting notes: Shouldn't Grin IMprovement Proposals be known as GIMPs? 😅
Simon B.
@sesam
Aug 08 2018 05:39 UTC
or GRIMPS :)
Ivan Sorokin
@i1skn
Aug 08 2018 08:30 UTC
I like GRIMPS, sounds like some sweets from Harry Potter universe :)
Merlin's Beard
@beardofmerlin
Aug 08 2018 11:08 UTC

@ignopeverell

I agree it would be the ideal scenario, but that's not reality

Why is it unrealistic?

Antioch Peverell
@antiochp
Aug 08 2018 12:33 UTC
I feel like payment "receipts" or "proof-of-payment" has been discussed here before but I can't find it anywhere.
Say you are running a store that accepts Grin as payment - you have two customers who both owe you 5 Grin. But you only receive a single payment. How would you know which customer actually made the payment? What happens when both customers say they have paid you?
Is there a way to do this based on the data on chain (I think not)?
So if this has to be off-chain somehow - how would this look?
hashmap
@hashmap
Aug 08 2018 12:39 UTC
@antiochp it should be part of tx building protocol. In the simplest form of online http process reference id (unique, generated by a store) may be sent as part of http request and response (as a header for example)
In case of more async (DHT-based or 3rd party service like grinbox) it would be a unique address of “postbox”, again generated by a store more or less like in bitcoin. Does it make sense?
Gary Yu
@garyyu
Aug 08 2018 12:42 UTC
I had same question as @antiochp , currently no way to identify which from who, based on chain data.
can identify only with UUID of wallet
hashmap
@hashmap
Aug 08 2018 12:44 UTC
I don’t think it should be on chain, but handled by GrinPay software which a store would use
@garyyu btw do you have compilation erros with my chunk of code? I built it and all tests pass, haven’t tested it on testnet though
Gary Yu
@garyyu
Aug 08 2018 12:46 UTC
Really? that’s impossible in my view:) Let me test again for u
hashmap
@hashmap
Aug 08 2018 12:46 UTC
Nice work btw, I surprised you said you are new to Rust
Gary Yu
@garyyu
Aug 08 2018 12:49 UTC
indeed new, it’s my 1st real project with Rust, hope to catch up soon:)
lehnberg
@lehnberg
Aug 08 2018 12:49 UTC
+1 for this not being handled on the grin protocol level. Protocol should be as minimal as is possible whilst allowing for core functionality. In my most humble opinion.
hashmap
@hashmap
Aug 08 2018 12:49 UTC
I’m on 1.27.0
Gary Yu
@garyyu
Aug 08 2018 12:50 UTC
I’m 1.28, but should not rust version’s difference, wait a few minutes
hashmap
@hashmap
Aug 08 2018 12:50 UTC
I mean it would be nice to be able to add some metadata but it comes with a price and anyway impossible in MW
Gary Yu
@garyyu
Aug 08 2018 12:53 UTC
@hashmap I tried, and error paste into pr
Antioch Peverell
@antiochp
Aug 08 2018 12:58 UTC
@hashmap what you are saying makes sense but is this provable in some way? In the case of Bitcoin I'd provide the customer with a unique address to pay to. I can then point to that address and show it is empty (to effectively "prove" the payment was not received) alternatively the customer can point to this non-empty address to "prove" it received a payment.
I understand I'm (mis)using "provable" is a very loose sense here.
Antioch Peverell
@antiochp
Aug 08 2018 13:04 UTC
@lehnberg - totally agree, my question was more about can this be done given the existing protocol (i.e. can we do something with the tx input/output commitments)
hashmap
@hashmap
Aug 08 2018 13:09 UTC
It’s traceable, but anyway in the best case it proves that an attempt of a payment was made, a tx still may be rejected, so what I described works in a case of happy path and non-malicious actors
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 13:17 UTC
Is there any use for the txid ?
lehnberg
@lehnberg
Aug 08 2018 13:17 UTC

but is this provable in some way?

I think it works something like this: I’m a buyer, interacting with a vendor to buy a book. We complete a transaction, and I post it on the blockchain. Now let’s say vendor comes back and says “I never received the money, you never sent me any grins.” Because the protocol is interactive, and I as a buyer would have needed vendor to sign with their private key as part of step 2 before passing the slate back to me to finalize in step 3 before broadcasting, the vendor cannot deny that they did not sign it. If I can prove there is a transaction on the blockchain that corresponds to the vendor’s step 2 slate, only the person in control of the step 2 private key could have control of those funds now.

hashmap
@hashmap
Aug 08 2018 13:49 UTC
@garyyu it seems Travis has a bad day, looks like your pr build failed on setup. I don’t see how I can restart the build, perhaps you should close and reopen pr which will trigger the build
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 13:56 UTC
@hashmap I can restart the build
I think you should be able to
Are you logged in Travis @hashmap ?
hashmap
@hashmap
Aug 08 2018 13:59 UTC
@quentinlesceller thanks, forgot this part
Gary Yu
@garyyu
Aug 08 2018 13:59 UTC
no need to restart, I see it’s going well, only last one still going
jaspervdm
@jaspervdm
Aug 08 2018 15:01 UTC
@quentinlesceller i saw your comment on mimblewimble/grin#1325, thanks for looking into it. You concluded that propagation seems to be working, but in that case, how can we explain my logs? When I submit a normal tx, I receive the same tx from other nodes quickly after. For the big tx I never receive it from other nodes (there are no "Received tx b10f5544..." entries in the log)
lehnberg
@lehnberg
Aug 08 2018 15:02 UTC

Following up on yesterday’s discussion on disaster scenarios please review this:
https://github.com/mimblewimble/docs/wiki/Regarding-Risk-Management

Not sure these are the right risk scenarios, I just tried to put down as many I could think of. I think there may be room to reduce/simplify. Feel free to jump in! It’s a wiki after all.

Quentin Le Sceller
@quentinlesceller
Aug 08 2018 15:02 UTC
I have no idea, from the look of it it seems like some nodes are not actually propagating the transaction but I cannot reproduce locally though.
I'm trying a 4 nodes network with a miner now
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 15:11 UTC
Okay it looks like the transaction get corrupted somehow

@jaspervdm this is what happens everytime my remote node receive the transaction

Aug 08 15:10:06.019 INFO Client X.X.X.X:23414 corrupted, ban (CorruptedData).

jaspervdm
@jaspervdm
Aug 08 2018 15:16 UTC
hmm
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 15:28 UTC
more investigation coming soon :tm:
jaspervdm
@jaspervdm
Aug 08 2018 15:32 UTC
nice :smile:
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 17:40 UTC
@jaspervdm Before going even deeper did you sort the outputs of the transaction ?
jaspervdm
@jaspervdm
Aug 08 2018 17:41 UTC
yes
it spreads fine if i have only 2 outputs
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 17:41 UTC
ok
I'm getting closer
jaspervdm
@jaspervdm
Aug 08 2018 17:41 UTC
if they werent sorted properly the smaller tx would have failed to spread 50% of the time
havent seen that
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 17:42 UTC
Yeah the weird part is that the first node accept the transaction but the second refused it because this verification fails https://github.com/mimblewimble/grin/blob/328d832bd6e3ac33cf4c160c4d78085dafb20adf/core/src/core/transaction.rs#L310
jaspervdm
@jaspervdm
Aug 08 2018 17:52 UTC
this check is also done on the first node right
so maybe reading and then writing the tx somehow changes the order
oh but wait you said it does work on local nodes
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 17:56 UTC
Going deeper it 's a deserialization error
not an order error
Ignotus Peverell
@ignopeverell
Aug 08 2018 19:01 UTC
@beardofmerlin following all the projects requiring funding on a regular basis enough to know which one deserves it is too much to ask for most companies or operations, they just won't bother. Note that if some are willing to put the effort, they can still do so, we should just not take that as a base assumption.
@antiochp @hashmap @lehnberg the proof or payment is the pubkey information you got from the payer mixed with your own, you can provide both to prove payment
that's part of the @tromp payment protocol, not in MW
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 19:42 UTC
@jaspervdm I've updated the issue but I found you found possibly quite a big issue here.
I now have an headache after looking at all those hex dump ^^
jaspervdm
@jaspervdm
Aug 08 2018 19:44 UTC
@quentinlesceller hm, at what point did you save the corrupted.txt? on the receiving node side or on the sender side?
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 19:44 UTC
On the receiving node
I'm going to investigate wether the problem is with the sender or receiver
jaspervdm
@jaspervdm
Aug 08 2018 19:45 UTC
so either the sending node serialized it wrong or something got messed up during the transport i guess?
ok cool
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 19:45 UTC
I think it's during transport since on my local network it was working well...
jaspervdm
@jaspervdm
Aug 08 2018 19:45 UTC
and yea i feel sorry for you, seems quite an annoying thing to figure out haha
yeah
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 19:47 UTC
Ahah thanks for finding this though !
Ignotus Peverell
@ignopeverell
Aug 08 2018 19:48 UTC
@quentinlesceller thanks for debugging (and sorry for the headache), must be a bug in serialization or transmission then
large blocks seem fine so more likely to be transmission, have you tried a diff to see if bytes were missing/added or completely messed up?
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 19:56 UTC
@ignopeverell some bytes were definitely added.
I’ll post an example soon after my break
Ignotus Peverell
@ignopeverell
Aug 08 2018 20:06 UTC
that would likely be a buffer not properly truncated then
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 20:31 UTC

@ignopeverell
Original first 32 bytes:

78c537c95f587dbfea7f0300addc9b8e

Sent first 32 bytes:

78c537c95f587dbfea7f30addc9b8ebd

Received first 32 bytes:

78c537c95f587dbfea7f30addc9b8ebd

jaspervdm
@jaspervdm
Aug 08 2018 20:32 UTC
hm a 00 byte is missing
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 20:32 UTC
00 at pos 23 24 gets truncated
Antioch Peverell
@antiochp
Aug 08 2018 20:34 UTC
interesting - thanks for digging down into this at this level...
Ignotus Peverell
@ignopeverell
Aug 08 2018 20:35 UTC
ah truncation, mmh lack of padding?
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 20:35 UTC
looks like
during Transaction serialization ?
Antioch Peverell
@antiochp
Aug 08 2018 20:38 UTC
is this an OS thing where some nodes are truncating and others are not?
Ignotus Peverell
@ignopeverell
Aug 08 2018 20:52 UTC
@quentinlesceller I'm confused, transaction serialization starts with vec sizes, there should be a bunch of zeroes?
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 20:52 UTC
Mmm
Here it's only the message body
Before in the message there is that [1e, c5, f, 0, 0, 0, 0, 0, 3, a2, a8]
jaspervdm
@jaspervdm
Aug 08 2018 20:55 UTC
the first 32 bytes is the kernel offset iirc
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 20:56 UTC
Yes self.offset.write(writer)?;
jaspervdm
@jaspervdm
Aug 08 2018 20:57 UTC
but like igno is saying, there should be more 00's further down. the sizes of the inputs, outputs and kernels are written as an u8
are those in there or did they disappear too?
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:03 UTC
@quentinlesceller at which level did you write these bytes?
Here for the when we send the transaction
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 21:20 UTC
Yes @ignopeverell there is still inputs, outputs and kernels length: [78, c5, 37, c9, 5f, 58, 7d, bf, ea, 7f, 3, 0, ad, dc, 9b, 8e, bd, df, d9, 97, ca, 52, 89, ba, 77, 11, 58, f8, 2e, 71, 16, 32, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 4c, 0, 0, 0, 0, 0, 0, 0, 1]
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:21 UTC
oh ok, and how do you print?
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 21:21 UTC
{:x?}
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:21 UTC
the whole buffer at once?
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 21:21 UTC
yes
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:22 UTC
mmmmh
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 21:28 UTC
So it's something with the kernel offset
This is the kernel offset of this transaction [78, c5, 37, c9, 5f, 58, 7d, bf, ea, 7f, 3, 0, ad, dc, 9b, 8e, bd, df, d9, 97, ca, 52, 89, ba, 77, 11, 58, f8, 2e, 71, 16, 32] when sent.
Antioch Peverell
@antiochp
Aug 08 2018 21:30 UTC
:expressionless:
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:30 UTC
I think it might be the printing that removes those zeroes
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 21:31 UTC
ohh
This message was deleted
Actually the printing is by byte
Antioch Peverell
@antiochp
Aug 08 2018 21:32 UTC
03 -> 3 and 00 -> 0
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:32 UTC
right, not saying there's no difference, just that it may not be those zeroes
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 21:33 UTC
Hum
okay going to debug this further tonight...
Antioch Peverell
@antiochp
Aug 08 2018 21:48 UTC
@ignopeverell I remember something about the "tromp payment protocol" now - but I can't find it documented anywhere... any ideas where to look for this? Is it in the mailing list somewhere?
Ignotus Peverell
@ignopeverell
Aug 08 2018 21:58 UTC
@antiochp it's what we've adopted for transaction building now, as opposed to the simple MW way of doing it
so that's documented by yeastplume's diagram, the code and https://github.com/mimblewimble/grin/blob/master/doc/contracts.md#trustless-transactions
John Tromp
@tromp
Aug 08 2018 22:00 UTC
@antiochp my fully general mailing list description is at https://lists.launchpad.net/mimblewimble/msg00091.html
which is a follow up to this discussion on the simpler sender-receiver case https://lists.launchpad.net/mimblewimble/msg00087.html
Quentin Le Sceller
@quentinlesceller
Aug 08 2018 22:20 UTC
I've updated mimblewimble/grin#1325 there is still definitely a difference between what is sent and what is received so it's look like it's during transport or deserialization