Could you try running this command: /Applications/Electrum.app/Contents/MacOS/Electrum --verbose
Does that give you a different error? |
|
|
|
|
I see wallets, please cd in there and ls.
|
|
|
|
|
Your wallet should be in ~/.electrum/wallets (that is /Users/YOURUSERNAME/.electrum/wallets)
|
|
|
|
|
Am I to understand you are on OS X 10.9.2? When you say 'installing' what do you mean with that?
|
|
|
|
Electrum will never supported alt-coin forks. However Electrum is also open-source software which means anybody is allowed to do what they want with it (as long as they follow the license that comes with it.) As for your question it seems somebody might already have a working Electrum Litecoin fork. |
|
|
|
Hey, great work! However, the install still says 1.9.7!
r2k
I've just added the Windows and OS X binaries. They should be on the website tomorrow, as soon as Thomas is able to add it there. For users on OS X. I had trouble, again, building the OS X binaries. Please let me know if they don't work for you, and if so on which version of OS X you are running it. |
|
|
|
It won't work with the current codebase. It looks like the wallet will be saved inside the .app file. This means upgrading Electrum will actually start a fresh wallet. It will probably require some additional logic to make the wallet portable on OSX. If you think more people would want this you can fill out a feature request here. |
|
|
|
So I have some difficulty running this simply because running the Bitcoin client is not very friendly with my computer, will it ever work from a light weight wallet like Multibit?
No, Masterchest probably won't. It needs the specific API calls from bitcoind, Multibit (as far as I know doesn't supply these calls). You can however still use a web-wallet like https://masterchain.info/, this could be considered light. Zath, I'm trying to send the payment for an accepted DEx offer but I get the following error after filling in my password.  Translated: "Value can't be null", parameter name: Value Any idea what I'm doing wrong there? Is the offer perhaps already expired? |
|
|
|
Awesome; I just re-tested everything and it syncs fine now. Thanks for the quick fix  |
|
|
|
I've been trying to break stuff as well and I finally managed to! I just installed Alpha 2 and got this error when it appears the msc-chain got caught up: DEBUG: Block Analysis for: 289519
DEBUG: Block Analysis for pending transactions
BLOCKSCAN: Transaction processing starting...
ERROR: Blockchain scanning thread threw exception : The column name is not valid. [ Node name (if any) = ,Column name = ADDRESS ]
DEBUG: Thread exited with error condition.
Is the version on the mastercoinwallets site always the latest version? |
|
|
|
Hey guys, I got side-lined for two weeks because of holidays plus a nasty flu but I'm getting better so I wanted to share some things with you today. First off after a lot of internal discussion we decided to depcrecate my ruby based Mastercoin implementation. We have a lot of talent in the Mastercoin foundation but in order to consolidate our efforts we had to get rid of an implementation. I volunteered to deprecate mine for the follwing reasons. I started the ruby implementation when I read the Mastercoin whitepaper a few days into the Exodus fundraiser. I was intrigued and since there appeared to be nothing created yet I decided to build a website where you could enter your address and it would calculate the amount of Mastercoins during the fundraiser. This got a lot of attention and I kept adding more things on top based on the feedback I received. Fast forward a few weeks and I basically had the first Mastercoin implementation. The problem however was that I had never intended for this website to be a Mastercoin implementation and not everything I build was done so in an optimal fashion looking back at it. The main logic was tied up in the Web-application, logic that should belong in a core library instead. When I got the job-offer from the Mastercoin foundation it seemed like the perfect time to rewrite my implementation and do it properly this time. By that time however it was clear we needed a reference client, one that could bring us into the future sadly ruby was not the ideal tool for this purpose. It is harder to create bundled applications with ruby and speed wise it is severely lacking. I decided to spend my remaining time working on the reference client instead and use all the knowledge I gained from creating the ruby version towards this client. This means that starting today Mastercoin-ruby, Mastercoin-wallet and Mastercoin-explorer are deprecated. Luckily this won't have too large of an effect since the other developers are still working hard on their implementations, beautiful things are just around the corner. The other thing I want to announce is that me and Jeffrey are going to start winding down our development on the Master Protocol to begin working on Ethereum in the beginning of March. We consider Ethereum to be the next evolution in cryptocurrency and believe it provides substantial innovations that make it much easier to enable social contracts in a decentralized manner. Ethereum does not compete with Mastercoin; it further enables Mastercoin as a new cryptocurrency platform, thus we plan on keeping close ties with the Mastercoin Foundation during its development. I like to think my contributions kickstarted the Mastercoin Protocol project, it's up to the other developers now to take it to the next level. I'm still a big believer in (and holder of) Mastercoin, I have full faith in the current team and I can't wait to see what is going to be next for the project. Thanks |
|
|
|
|
Guys; timing sucks but Bitcoin-ruby has a problem with one of the transactions in the latest blocks and is stuck. To add to the problems the migration in the new version of Bitcoin-ruby is having problems running on my small-ish SSD because of lack of space.
I'm trying to discover what other options I have to recover the database but it looks like the downtime might last a little longer.
|
|
|
|
Developers: I've pushed the new verification API online for Mastercoin-explorer ( example). Could you guys let me know once you have also done this so I can add you to my DEx consensus checker? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tachikoma's BTC/MSC address is 1JmGrSP6m9XcbuMxBbHk1rGVbr39Er7CxA. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJS4jPDAAoJECJFMARpVQb9YAgIAIPhNFPUavfbJyCt9KQ7aneE LmhYXzDiInbSxeu6GLNp6jS20rp65tBsLMFUgG5ER2oHh/kxkNEBrSHRiWHwv1fO y45psv8RaBBcAAmNQbfd6V+L3BmKzNXuWCrWRB4HsCF5Op6Rp0iSA5Y0SrTUJErM OTuhHEOnYf/nCrHQZFxmY0Osw9XDo+R2vAsuxPOV9mYfsKCgkhEY3nYXr2skgeNn 76ZqrfasIhqX3Hn113O2+FSDLvbJWw2X9nqP79yYrFpvUS2TkHAG8Tkm8yGjbQ4F WkYakwSNwtL11jOkh1FjupqC9nGwMziwX+A/rzN25OSnZF+tzaitbKiweGNAxsc= =1tPs -----END PGP SIGNATURE----- |
|
|
|
Hey guys, First off; let me start by saying I'm a little annoyed with the fact that some people are writing down every post or comment on Github they ever did since the start of the bounty. The question was to summarise your work so it can easily be digested by the other participants. I am not going to open every link or read every comment you wrote somewhere on the forums and I highly doubt the value of these contributions. It almost seems like some of you want to inflate the amount of actual work done. I understand that me publicly saying this might decrease my own chances but I think it's only fair I speak my mind. Also please note that none of the Simple Send consensus work was part of this Bounty, if I mention it it's purely informational.I will outline everything I've done in very broad lines, there won't be any links to communication I had via pm/skype/hangouts or anything else. Mastercoin Explorer
Screenshot
| | Main features
Not related to the bounty
Testing
Mastercoin-explorer comes with a full rSpec based test suites that automatically tests various different outcomes for parsing Mastercoin transactions.
Where
|
Mastercoin Wallet
Screenshot
| | Main features
- Can now display DEx order book.
- Supports all creation and broadcasting of all DEx related messages.
Not related to the bounty
- There is an automatic installer script that can now install the client with one command on Debian/Ubuntu and Fedora/Redhat.
Where
|
Mastercoin Ruby
Mastercoin-ruby is the encode/decode lookup layer that can lookup transactions. Support for decoding/encoding of DEx messages is now supported in this library. This library also comes with accompanying rSpec suite. $ bin/mastercoin_transaction lookup 8dc0568fbc0cd75cb27c669ff3264ca0f1f13509def3b7ae2f1d175110e5b82b
D, [2014-01-22T17:59:58.146204 #5396] DEBUG -- : Transaction type: 20
D, [2014-01-22T17:59:58.146479 #5396] DEBUG -- : Selling offer found
Selling Offer from 16rAwebBXhJAM9ALf3fLFbaHKz24r2o3UN of 0.002 Test Mastercoin for 0.0002 Bitcoins. Time limit 5. BTC Fee 10000
Mastercoin protocol updatesNot related to the bounty |
|
|
|
I've added PR #39 (Graz's suggestion) and a variation PR #40.Developers please read and give your +1 or -1's. Even without these PR's there are plenty of things to deal with. I'm trying to improve the consensus tools we have available this week to add support for a service which can do consensus on the transaction level so we can more easily determine where our DEx implementations differ. In two weeks time I probably won't have to struggle to find the time to work on all this. Can't wait |
|
|
|
The guys from engine.co found a potential race condition where the user could accidentally create a new sell order when they were trying to change an old one, because the old one had already been bought. At my suggestion, Marv made this pull request to add a 2-confirmation time limit after a sale is complete before that address can initiate a new sell offer: https://github.com/mastercoin-MSC/spec/pull/38I'm posting here because not respecting the time limit will lead to consensus divergence, so I want to make sure everybody is aware of it. Thanks! Perhaps it's the lack of sleep but I don't like the fact that this has been merged already, up till now everything we did was democratic. Shouldn't we discuss such a major change in the protocol before merging it? I would appreciate it if at least some examples could be given in how this is suppose to work before and after the merge. I also think this pull request should be open for discussion like any other pull request. my opinion: I don't think this solution really solves this race condition, e.g. due to difference in fee amount and inputs complexity of the buy/sell change transactions, the sell offer change can still get merged 2 confirmations later, and then we're in the same race condition state. Alternative solution would be to keep only the option to cancel the offer (amount zero), and omit the option to change it. If one wants to make a change, he can first cancel the old offer, and then create a new one. EDIT: it would be also much easier to implement, and reduce complexity. My plus 1 for this idea. Separate messages make a lot of sense to me. |
|
|
|
|
My DEx transactions are getting stuck in a verification loop, don't mind any of my output at the moment.
|
|
|
|
I'm getting this transaction as invalid
8d47449b082ffe6f6b2adad327591778c43bf984e84062fb1cb13320b47ccbbd
TMSC
Date: 11/10/2013 9:22:18 AM
Remarks: Sender 16rAwebBXhJAM9ALf3fLFbaHKz24r2o3UN doesn't have 1.337 TMSC. Bal:1.1583 Sale:0.002 Pend:0
11/8/2013 6:44:20 AM 1NHVAzYT2jQ8roRddYXhvZtiVjuMwuWBGn .1337 6890
11/7/2013 8:15:22 AM 1NHVAzYT2jQ8roRddYXhvZtiVjuMwuWBGn .808 6866
11/2/2013 10:15:26 PM 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV .1 6727
11/2/2013 10:15:22 AM 18xEZx3po1iJWP5H2aM3Do11dCGQyaebnT .2 .003232 6736
10/28/2013 8:13:38 AM 2.4 1NHVAzYT2jQ8roRddYXhvZtiVjuMwuWBGn 6708
Yeah the problem is I have been messing with the DEx for two months now and it's really about time I do a full reimport because some of these transactions got imported with the old logic. I will make some time over the weekend to create a development database and see the consensus between the old and new. Until that time please assume you implementation is the correct one Grazcoin: Could you take a look at a1b5d7c73e9ec345075eb2357c4dbfced610bdac63808f2f0d05fa431e266795? It appears you are using the change address as recipient for this transaction. |
|
|
|
The guys from engine.co found a potential race condition where the user could accidentally create a new sell order when they were trying to change an old one, because the old one had already been bought. At my suggestion, Marv made this pull request to add a 2-confirmation time limit after a sale is complete before that address can initiate a new sell offer: https://github.com/mastercoin-MSC/spec/pull/38I'm posting here because not respecting the time limit will lead to consensus divergence, so I want to make sure everybody is aware of it. Thanks! Perhaps it's the lack of sleep but I don't like the fact that this has been merged already, up till now everything we did was democratic. Shouldn't we discuss such a major change in the protocol before merging it? I would appreciate it if at least some examples could be given in how this is suppose to work before and after the merge. |
|
|
|
|
Show Posts
