I also understand about the alpha stage - it's just that I guess I expected something a bit more stable at this stage of development, but it's understand that this is still a bit raw around some edges since the wallet was just released. I think proper error messages are very important for usability, too. Let's just write every one down, whenever one without nice information is found.  Edit: zathras, what is your take on the translation thing? Is it safe to start submitting translations to https://www.transifex.com/projects/p/masterchest-wallet-1/ or is not yet finalized and up to change? |
|
|
|
Can you give me an example where it doesn't work? That was on a sellaccept page, when clicking on an address link. Tested all pages a few minutes ago, the only one left is btcpayment when clicking on an address. Example: https://masterchain.info/btcpayment.html?tx=aa799134259de13c1249b2c538d32103eec9d0327f1c82195409a75c6a215180¤cy=TMSCTo 1EXoDusjGw...: https://masterchain.info/Address.html?addr=1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4PTo 1HG3s4Ext3...: https://masterchain.info/Address.html?addr=1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCjTo 1LifmeXYHe...: https://masterchain.info/Address.html?addr=1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMmThe payment was a BTC payment for TMSC. -- On a different topic: Say, I have four pubkeys, two of them are encoded Mastercoin data packages, one is the known input pubKey and one is random junk. I know which one is the input pubKey, but I don't know the order of the data packages: Encrypted 1: 02 8d7a29f02b6807292449947137181ae63fb60b3b1cd83bb19f0a44a8cb7fd1 68
Encrypted 2: 02 43a6b4397e00daafe0d7a76383e6808afa085577a3b8f1688279e6bea87260 70
Encrypted 3: 02 1cbdde253bea7b5ddee99b269ae74042ed6dd962efcb5ecb70973e14a86870 93 < input pubKey, pubKeyHash: 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj
Encrypted 4: 02 989a78ab3a2e8fbaa5f6003825eddaada19103096ffc5a6c01eff61779091e 49
SHA256 round #1 on pubKeyHash:
Hash 1: 999a79ab2e2e8fbaa7f6003825eddaada09103096ffc5a6c00eef61779091e 66
SHA256 round #2 on UpperCase(SHA256(pubKeyHash)):
Hash 2: 41a6b4387d00daafe0d7a76383e6808afa085577a3b8f1688279e6bea87260 a0
I could mix all encrypted with all hashes, but is this the only way and is it unamigious? Hash 1 ^ Encrypted 1: 14e0505b0546889383bf944912f5c0
Hash 1 ^ Encrypted 2: da3ccd92502e55154721a75ba60b5a
Hash 1 ^ Encrypted 3: -- E3 is the known pubKey
Hash 1 ^ Encrypted 4: 010001001400000002000000000000
Hash 2 ^ Encrypted 1: ccdc9dc85668dd86c49e3312b4fe9a
Hash 2 ^ Encrypted 2: 020000010300000000000000000000
Hash 2 ^ Encrypted 3: -- E3 is the known pubKey
Hash 2 ^ Encrypted 4: d93ccc93472e55154521a75ba60b5a
What is the fastest way to determine the order of the packages without mixing them all and testing, if they are valid? Is it possible to allow junk at the same time? |
|
|
|
moneypaktrader.com is trolling the DEx by placing 1k for sale at 0.002 but with a 8 btc fee.
What is the btc fee for? This will encourage people to put a price of 0.0001 but with a huge BTC fee.
DOS protection. If you use none, a villain can freeze your orders - for free. |
|
|
|
If you select before TMSC (on the left on large browsers or bottom on mobile), you will get the currency you chose.
On all other pages yes, but not on sellaccept.html. |
|
|
|
Speaking of tests. I want to make sure that everyone is aware of the Mastercoin faucet: http://mastercoin-faucet.comIn case you need more Test Mastercoins, send me a message with a note what you like to test. |
|
|
|
Somewhat related: Check out the two wallets in my signature. https://api.trustedcoin.com//#/ provides a service that locks payouts for 24 hours by using 2-out-of-3 multi signature transactions where the user holds two key - one for the online computer, the other one as secure backup/offline key and they hold one. The payout is initiated by the user and they sign and broadcast the transaction after 24 hours. The user is informed via email and sms, if a payout is initiated and has 24 hours to cancel. The service provider has never the authority to spend coins without the user's approval nor is the user dependent on the serivce provider. Within the Master protocol there are going to be "saving wallets", but that is limited to the Mastercoin ecosystem of course. Preliminary spec can be found here: https://github.com/mastercoin-MSC/spec#transactions-to-limit-funds-theft-preventionThe ideas there could be transformed into an oracle service and applied to real BTC with a similar service as mentioned above. Something like "sign only, if recipient address is X" should certainly be possible with a 2-out-of-3 signatures approach. |
|
|
|
Thanks for the response. The more I see, the more impressed I am. It's really well thought through. Being miner friendly is also a very, very good move to combat the argument that Master transactions are "abusing" the chain. where the seller attempts to yank their sell order just as someone tries to accept it, and pocket the fee. Interesting case. I assume block time is used throughout the protocol to ensure all clients are in the same state, so this would create a race condition where the seller cancels and the buyer accepts at the same time. Also, a seller could post a very attractive offer way below market with a high fee in hopes of getting a ton of fees from different people all at once. To avoid race conditions it's not possible to "accept offer and pay" in one transaction, but if it were, I'd transform the "required fee" into something like "required minimum partial payment". From a buyer's perspective running into the risk of a race condition may even be acceptable, if the risk-reward ratio is high enough, e.g. the risk of many buyers at the same time vs. a very appealing price or simply the comfort of a faster transaction (where partial payment = full payment). I guess it's all a trade off, but I agree, such things should be avoided whenever possible. I was wondering about the payment itself. Currently it's simply a transaction with the seller + exodus referenced and no message. I'm trying to figure out, if there is an edge case where I could scam a seller by buying something else and at the same time making the payment for an dex offer? At least related to dex it should be fine, as long as there is only one offer at the same time per seller allowed. |
|
|
|
Hey zathras, chart is fixed. You need to set the culture info at the beginning of the workthread_DoWork() method, too. I think that's also the only section where anything multithreaded is, right? So it should be fine then.. I'm not sure, if CurrentThread.CurrentCulture is enough or if CurrentUICulture needs also to be set. But make sure you use CultureInfo.InvariantCulture instead of creating your own with only the decimal change. Re: font size, this seems to be somewhat messy and there are some reports that users have problems with it, even when trying to change the element's size on the fly. Some said that the AutoScaleMode should set to .Dpi instead of .Font, but after testing the tables were still misplaced. Maybe you should use fixed font sizes all over the wallet and simply force a specific size, if this is possible. Less usability is still preferred over a broken interface imho. It would also be nice, if the form is not entitled with "Form1".  By the way, do you scan and refetch the block chain on the fly? Edit: The balances in the "address overview" are accurate, but the "currencies overview" displays the balances as if the decimal limiter was ignored. https://i.imgur.com/wJoZ0iy.pngThe date of a transaction created by the wallet is also affected by localization, I think: https://i.imgur.com/kUBEteZ.png + http://pastebin.com/raw.php?i=ad6HcMDR (log was super long, so I hope this is relevant part) |
|
|
|
Hmm.. did also not help. It's pretty late here already, so I guess the next round comes tomorrow. Cheers! |
|
|
|
The chart is still broken, but I assume the culture info is only set for the specific thread and not globally. I'm not aware of a workaround, but it's probably worth to look into and to combat this whenever possible. Could also lead to broken queries, if floating points are used somewhere for example. Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.InvariantCulture Has a broader effect and is not only limited to decimal marks, so something related may be preferred. The image from pplwjd: https://i.imgur.com/vwEK0WC.jpgedit: sent you some! 53e7ecbbdafb260e66531f4743dd6f5d332c2f0463148b14368be1ebfde28ff2 (0.005 MSC) cd0923045d076fc9fbdae6c6f2d601cc549667b21e2e949fcbabb64e592f8541 (0.2 TMSC) Will probably take a few minutes until it's visible on masterchest.info. |
|
|
|
http://chart.googleapis.com/chart?cht=lc&chd=t0:0,0001,0,0001,0,0001,0,0001,0,001,0,001,0,001,0,01,4,94E-06,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,20000037,0,20000037,0,20000037,0,20000037,0,0002,0,003,0,02231932,0,4954955,0,4954955,0,001,0,01|0,0,0,0,0,0,001,0,001,0,001,0,011,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,0,20000037,0,20000037,0,20000037,0,20000037,0,0002,0,0002,0,4954955,0,4954955,0,4954955,0,001|0,0,0,0,0,001,0,001,0,001,0,011,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,1E-05,0,20000037,0,20000037,0,20000037,0,20000037,0,0002,0,0002,0,4954955,0,4954955,0,4954955,0,001,0,01|0,0001,0,0001,0,0001,0,0001,0,001,0,001,0,001,0,011,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,01,0,20000037,0,20000037,0,20000037,0,20000037,0,003,0,003,0,4954955,0,4954955,0,4954955,0,001,0,01&chm=F,,0,-1,10&chs=426x205&chf=bg,s,252526&chxt=x,y&chds=0,0,54504505&chxr=1,0,0,54504505&chxs=1N*F4*,D1D1D1,11,0,lt|0,D1D1D1,11,0,lt&chxl=0:|07.01|11.01|17.01|23.01|29.01|04.02|10.02|16.02|22.02|28.02|06.03 The chart looks like this here, too, but is actually green-white, instead of green-black. |
|
|
|
* This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). Does your (and the others) implementation allow to include the payment within the accept offer transaction? |
|
|
|
Perfect, works fine now. Edit: I really like the design. You may check out the colored areas, those are the transactions from the other thread ( link). I have no clear overview right now though, due to the mix of many transactions inbetween and afterwards. Note to myself: start with a clean wallet next time.  Side note: It would be awesome, if a right click on a transaction would allow to copy the transaction id. |
|
|
|
Let's go! DEBUG: SQL INSERT INTO processedblocks VALUES (289247,1394137090)
DEBUG: Block Analysis for: 289248
DEBUG: SQL INSERT INTO processedblocks VALUES (289248,1394136834)
DEBUG: Block Analysis for: 289249
DEBUG: SQL INSERT INTO processedblocks VALUES (289249,1394137433)
DEBUG: Block Analysis for: 289250
DEBUG: SQL INSERT INTO processedblocks VALUES (289250,1394140038)
DEBUG: Block Analysis for pending transactions
BLOCKSCAN: Transaction processing starting...
DEBUG: SQL SELECT MAX(BLOCKTIME) FROM processedblocks
DEBUG: SQL SELECT MAX(BLOCKNUM) FROM processedblocks
DEBUG: SQL SELECT MAX(BLOCKNUM) FROM processedblocks
DEBUG: SQL SELECT MAX(BLOCKNUM) FROM processedblocks
DEBUG: SQL SELECT MAX(BLOCKNUM) FROM processedblocks
DEBUG: SQL SELECT MAX(BLOCKNUM) FROM processedblocks
DEBUG: SQL SELECT MAX(BLOCKNUM) FROM processedblocks
ERROR: Blockchain scanning thread threw exception : Fehler beim Analysieren der Abfrage. [ Token line number = 1,Token line offset = 220,Token in error = 33333333 ]
DEBUG: Thread exited with error condition. |
|
|
|
|
Show Posts
