Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Taylor Gerring
    @tgerring
    where does the geth daemon run? shared daemons can't run on iOS and it would be dangerous to expose full RPC to outside world
    imo better would be real light client that communicates with real peers over eth light-client subprotocol
    Péter Szilágyi
    @karalabe

    :nut_and_bolt: [xgo build bot] No new commits since geth 1.4.0-unstable (4dee200) - develop branch

    Disclaimer: All of these binaries have been cross-compiled from Linux. Their primary goal is to provide access to unsupported or experimental platforms. We cannot guarantee that a cross compiler will produce the same performing code as a native build will. For any issues found, please contact @karalabe.

    I'm off on vacation for a week with no Internet access. Have fun, everyone! Best wishes.
    f00bar
    @f00bar
    @tgerring the geth daemon runs on a backend server - it's how the ethereumjs-accounts + web3 hooked provider work
    so I can't see how replicating that on iOS will be considered dangerous
    Péter Szilágyi
    @karalabe
    @f00bar iOS doesn't support background services :)
    The background service way is how we do it on nadroid
    on ios, there will be a geth library you can link against :)
    f00bar
    @f00bar
    @karalabe but why would you need to support a background service ???
    I want to run geth on a backend EC2 instance as a provider
    and have my iOS clients manage they key pairs and send signed transactions to my backend server where geth is running
    Péter Szilágyi
    @karalabe
    Our aim is to allow running a node on your own phone, without any external device dependencies
    If you wish to run your own server and stream everything through it, that's a possibility, but it won't be something we officially endore, as there are security implications
    f00bar
    @f00bar
    what are those ? I was left with the impression that most bitcoin light wallets work in this way...no?
    Péter Szilágyi
    @karalabe
    Yes, but you are still running a light node on your device :)
    That's what we aim for
    A light node that connects to the network
    But which is nonetheless a fully qualified ethereum node
    vs. trusting a third party service to be truthful
    Taylor Gerring
    @tgerring
    The Bitcoin light client model is terrible because it basically changes the network back into a server/client model and you lose all the P2P benefits of such a system
    f00bar
    @f00bar
    @tgerring It's a trade off - security vs adoption
    my sense is that if there are really popular blockchain apps built in real-life their users will be using a light web client
    Taylor Gerring
    @tgerring
    yes of course, but does that mean the light client MUST connect to some known SPV server? i think not
    i think the better alternative would be to connect to a small number of peers and maintain the P2P-like network
    that's the difference in approach between Bitcoin SPV and Ethereum light-client
    Péter Szilágyi
    @karalabe
    There isn't anything stopping you from creating an RPC based app (see http://syng.io/)
    But that's already doable even now
    We're aiming to bring the full capability of an Ethereum node into a mobile app
    f00bar
    @f00bar
    I see
    f00bar
    @f00bar
    well I have a question about the new RPC
    eth_accounts, eth_sendTransaction and eth_sign will be supported for backwards compatibility but will eventually be removed in the future ?
    @karalabe how would that affect web3 light JS web clients that are using a transaction signer and backend server geth node (provider) ?
    Péter Szilágyi
    @karalabe
    the goal is to gradually transition to geth becoming only a relay into the network and not do its own key handling
    this will allow external applciation to reuse the same geth process
    I don't know though when we would drop support for keys intenally though
    that's a bit further down the line
    I'm nto really familiar with web3 tbh
    @frozeman ^ ?
    f00bar
    @f00bar
    well I thought you could reuse the same geth process by using an external transaction signer
    Péter Szilágyi
    @karalabe
    That would be the idea yes
    mist already does it like that
    Though it's not that simple, becuse we have whisper and swarm too
    Péter Szilágyi
    @karalabe
    which are a bit more tied in with accounts
    nd identities
    f00bar
    @f00bar
    basically key pairs are managed client side and you can use a backend server-side geth process right now to receive signed transactions from the client light wallet
    so in a way I think that geth can be used as 'relay' into the network even right now