Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    jaspervdm
    @jaspervdm
    wallet.seed contains a random salt used in encryption, meaning 2 different files could represent the same seed
    Matthew Rayfield
    @MatthewRayfield_twitter
    ah okay. that makes sense. so but then i wonder why my balance wasn't showing the same on both even though the recovery words were the same
    energyburn
    @energyburn
    @sheldonth I believe it had to do with iOS permissions for inbound connections, iirc
    Sheldon
    @sheldonth
    @energyburn I'm pretty sure that's not the case. If you google for "using sockets and streams apple documentation" you'll see that the complete tcp API (posix conforming) is available on iOS - although the docs clearly note the unreliability of accepting incoming connections on LTE radio. (Incoming connections don't wake the device for radio, so a sleeping phone can't accept an incoming tcp connection no matter how it's wired). As such, I think it's possible to extend IronBelly to use the http flow for constructing a slate with a peer directly.
    It's such an uncommon use case, I think it would need to be done with C/Objective-C, I'm not sure how that would fit into the current design with React-native, but it could be done.
    I think the ipv4 and ipv6 addresses that are assigned to endpoints by LTE service providers are themselves NAT'ed unfortunately.
    Although I think it's worth investigating. If you ran a simple tcp server on iOS over LTE, could you netcat to it from a desktop...
    jaspervdm
    @jaspervdm
    end-user shouldnt accept slates over http in the first place
    Sheldon
    @sheldonth
    why?
    jaspervdm
    @jaspervdm
    we shouldve removed it from grin-wallet before launch
    Sheldon
    @sheldonth
    The original bitcoin client was designed with pay-to-ip. Can you elaborate as to why you think end user's shouldn't do slates over http?
    David Burkett
    @DavidBurkett
    And that was one of Satoshi's many mistakes. It's bad for privacy, it's difficult for consumers (port forwarding), and it's subject to MITM
    Sheldon
    @sheldonth

    Bad for privacy

    IP addresses are easily unlinked from identity. Courts have ruled repeatedly that just because some communication happened over an IP address assigned a customer of an IP, it does not mean that customer did those actions or is liable for them. IPs leak location quite accurately, but identity, not so much. IPs are very anonymous still, identity-wise.

    difficult for consumers

    Agreed, I'm thinking of ways it could be made less difficult. The alternative of emailing attachments or using a relay also have considerable drawbacks.

    subject to MITM

    Technically yes, but in a practical sense, not really. Aside from disrupting my flow, what could be accomplished with a man in the middle? If an attacker (assuming a 1 party to 1 party payment) intercepted my slate, added their own signature and returned it to me, would I have any way of knowing? Would I unknowingly add the third signature to the slate and broadcast a payment to the attacker? Genuinely wondering.

    David Burkett
    @DavidBurkett
    Regardless of what courts rule, if you had Igno's IP address, you would be able to figure out who he is. Not great for a privacy coin. And a MITM could easily add their outputs instead.
    Sheldon
    @sheldonth

    if you had Igno's IP address

    how? Subpoena'ing (spelling) the ISP, going to that address, knocking on the door, and saying, are you igno? Is anyone whose ever signed into your Wifi igno? Have you ever run an open IP relay on this internet? Is anyone who has ever signed into your IP relay who is Igno?

    And a MITM could easily add their outputs instead.
    I'd be interested in a proof of concept there
    I wonder how much value a working "MITM for grin" program would provide the community, if what you say is accurate.
    David Burkett
    @DavidBurkett
    We're not just trying to provide plausible deniability. The goal is complete unlinkability.
    Sheldon
    @sheldonth
    I think pay to ip could be a crucial feature on iOS - especially when both the mobile devices are within the same subnet (like we're both on the same Wi-Fi connection) in which case NAT issues are resolved for free. Apple vends a nice implementation of zero-conf networking called MultiPeerConnectivity that could make transacting with nearby devices in grin very elegant and fast while still maintaining anonymity. You can see the person in the room of course, but all you would know is their local NAT ip, which leaks nothing.
    It would be fast, and save the email or whatever side channel is otherwise invoked.
    I agree with the goal of complete unlinkability, and delivering slate components over signal or something else achieves this - but if the tradeoff can be a much easier payment flow, shouldn't allowing users to revert to plausible deniability be enough for some use cases?
    Sheldon
    @sheldonth
    If you were giving some grin to a friend to show them how it works, it would change the flow from "install ironbelly and lets send each other some emails" to "install ironbelly and i'll just click on your device name" so long as the two devices were on the same WiFi
    jaspervdm
    @jaspervdm
    why not use bluetooth for that?
    Sheldon
    @sheldonth
    Apple's MultiPeerConnectivity does include bluetooth low energy as one possible underlying transport
    I think it would be a neat feature to prove out in IronBelly
    Inside the send menu, could be a button for "Nearby" which starts a search for peers on the LAN using Apple's zero-conf networking stack.
    It's simpler than using the posix tcp API to run accept connections directly.
    energyburn
    @energyburn
    @sheldonth re plausibility of MITM attack: An http grin MITM attack would be very simple to accomplish, especially so if the attacker is on the same network as one of the transacting parties.
    WIFI in particularl is very easy to hijack a connection
    Once you are "in the middle" all the attacker needs to do is replace the outputs in the transaction with their own, and just "play along" so that the sender signs and finalizes the TX
    Short of verifying keys (which I dont think any GRIN wallets support), this would be near impossible to detect
    MF Grin
    @MFgrinn_twitter
    I was trying to restore my Grin++ wallet (24-word seed) into Ironbelly but it was giving me an error. Is it not possible?
    David Burkett
    @DavidBurkett
    @MFgrinn_twitter See discussion about this in the Grin++ gitter channel. It's possible you got one of the 3 wrong words from the defective bip39 word list. No big deal if you did, it can be fixed.
    DM me and I'll help
    David Burkett
    @DavidBurkett
    Ftr, @MFgrinn_twitter can restore in Niffler so there might be an issue with restoring in IronBelly. Is this a known problem?
    new episode on Grin Talk today
    Photis Phudge
    @photis
    @MatthewRayfield_twitter How did you move your wallet.seed over to the application support directory on your phone? I’m using iMazing but don’t have access to the Documents folder of Ironbelly apparently. (iOS 12.4)
    Ivan Sorokin
    @i1skn
    You can not move it to the Application Support, but you can use paper keys to create another wallet.seed on the device.
    samholmes
    @samholmes
    Does IronBelly run a full node?
    On device*
    Ivan Sorokin
    @i1skn
    No, node is still required. But there are ideas on how to implement it on a device as well
    gospetig
    @gospetig_twitter
    yo devs, is there any cca time or any updates on the android wallet? progress %, what you working on? anything from this
    Ivan Sorokin
    @i1skn
    @gospetig_twitter hi! Android wallet is pretty much ready, I test now different Android versions, so no surprises there. So, 95% I would say.
    energyburn
    @energyburn
    Android wallet is pretty much readyn
    :rocket:
    Cant wait!
    gospetig
    @gospetig_twitter
    Awesome to hear, tnx for reply.