 Show Posts
|
|
Pages: [1] 2 »
|
The API for hooking into Local Trader is public, and I'd be happy to help another wallet use it.
Do you have a link for some API docs ? |
|
|
|
Hi. Onchain.io has support for signing transactions via QR codes. You can see the code and some screenshots of the app here. https://github.com/onchain/onchain-androidIt would be good if the BIP followed the existing protocol. Let me know what you think. |
|
|
|
I'll add it to my list of test platforms with Dark Wallet.
Dark Wallet supports BitID ? Do you have a link I can look at. |
|
|
|
Not sure. It's working now, that's the main thing.  |
|
|
|
OK, thanks. Seems to be working now.   |
|
|
|
I assume the values are those used with the rails demo and that you had different uri, signature & address for your test with the python demo. That's right ?
That's correct. May you check the value of the field "message" in the json returned by the server ? It should give us a first hint about the problem.
I'll do some extra debug now. Thanks. |
|
|
|
Hi there, I've just pushed a new version (r0.0.3) of the python library on github: - Fixed a problem with urlparse in python 2.7 - Cleaned package structure - Created a setup script for clean installation (setuptools) I've also setup a demo server with 2 python demos (authentications with mainnet addresses): - BitId authentication demo : http://vps90685.ovh.net:8080/ - BitId 2FA demo : http://vps90685.ovh.net:8081/ Hi, I'm working on an android app at the moment. I can log onto erics implementation (ruby on rails app) but not yours. I think this may be a confusion over the protocol. I'm posting the following parameters. Started POST "/callback" for 192.168.178.39 at 2014-09-11 12:07:05 +0200
{"signature"=>"ICmRRZees1ERGP0zFRpjlzNA60e3b9GYAwScGbpqe7Lnek6ulUwTB3VXkWkH1ZbaPirEf60EKrWGAXE0BqMSETI=", "uri"=>"bitid://192.168.178.29:3000/callback?x=463eb9f064a4173f&u=1", "address"=>"1PmcrixixGKzSyL6NbNcSzjHGLSsgb7dfa"} |
|
|
|
|
I wouldn't keep a private key with the application.
You could certainly have an application that creates Bitcoin transactions, that another service could then sign.
|
|
|
|
vitalik buterin even had a discussion with devs on the nxt forum and came to agreement that nxt does not suffer from the flaws that other proof of stake does.. he also agreed the same thing about bitshares.. is it so hard to believe that PoS technology can evolve?  https://bitsharestalk.org/index.php?topic=6990That's not exactly what was said, or perhaps I'm mistaken. I think Vitalik mentioned that he would like to see code or a paper on the NXT solution (Economic Certainty) which is as far as I understand it a proposal at the moment. There's some very clever stuff happening with NXT but at the moment there is also an air of mystery around potential solutions to the nothing at stake problem. p.s. I hold NXT and BTC, nothing else. |
|
|
|
Answering the question directly; I don't see that it would be too difficult to optimize an algorithm specifically for x86 hardware; such that an ASIC would simply be x86 with a few instructions removed. The question is whether or not that's useful.
I think having a solution that required several proof of work algorithms, i.e. one is selected somewhat randomly based on the last block might be the way to go. A general CPU would be good for this task. |
|
|
|
Each person MUST have an android smartphone?  . Might be a problem with apple users? Also, should the escrow need to have good rep? What if the buyerdecides to not sign the ssignature? It would be up to the escrow, and happens if the escrow was a troll or an alt of the buyer??? iphone solution is in the pieline. Collaboration between an escrow agent and the buyer or seller is always a risk. So reputation is important for an escrow agent, however with using multi sig it's easier to build a reputation, because your using the right tools int he first place. |
|
|
|
Looks cool. I would be interested to be a part of your site Me too , i'd like to partecipate. Probably the best thing to do is set up some example escrows. For anyone interested PM me with 2 example email addresses you have access to, one of a buyer one of a seller. I'll create an escrow agreement. When the agreement is created in onchain it will send out the invites to the 2 addresses ( and also to to me as I'll act as an escrow agent). You can then see how the multi sig creation stuff works. I'll fund the bitcoins |
|
|
|
So in future the Bitcoin Core can compress the local blockchain and eliminate all old spent transactions.
Right?
You can eliminate spent outputs yes. It's generally called blockchain pruning and there have been several discussion on this. i.e. https://bitcointalk.org/index.php?topic=96644.0Enjoy. |
|
|
|
I would be interested at doing this with low fees, but I fear that I do not have enough trust in the community yet.
onchain.io is trustless because we are creating genuine multi sig contracts. Only if 2 participants agree can the Bitcoins be spent. As an escrow agent you would not have access to the funds so participants only need to trust that you will mediate correctly. Here's a presentation about how it all works for escrow. https://docs.google.com/presentation/d/1xh8VgjYtTZr6lZY3hJirrPiFUX9yJHx3ga3Ac-lDtO4/edit?usp=sharing |
|
|
|
|
One issue I can see unless I've misunderstood.
When the winning block on the Bitcoin network is published, what's stopping me picking that up and publishing it onto the sidechain, even if I didn't mine it.
|
|
|
|
|
