Latest posts of: Bitoy

Quote from: prophetx on January 15, 2014, 08:36:27 PM

Perhaps you guys need to create a little widget that shows how many hours:minutes:seconds out of sync each engine is

Nice suggestion. A "last block time processed" in the api.

Quote from: ripper234 on January 15, 2014, 10:52:18 AM

I see a sudden drop in consensus, with a lot of conflicting addresses.
Also it doesn't seem like any one implementation is the cause for the conflict.

Copying pasting the conflicting addresses here (sorry for the format):

Hi Ron,

The mymastercoins engine is off for a few minutes. Have to update the table to add tachikoma's dex api.

Consensus is back to 99.96%

Consensus Address MyMastercoins Masterchain Mastercoin-Explorer Masterchest
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P 11355.93262989 11355.93262989 11355.93262989 11355.93262988

There is only a 0.00000001 difference in masterchest exodus address.

To test dex, lets just synchronize a few test msc addresses (maybe 4 addressess).

(We don't have to synchronize the whole test msc.)

Quote from: zathras on January 14, 2014, 10:30:37 AM

Quote from: Tachikoma on January 14, 2014, 10:24:09 AM

I would actually suggest this should be done with real MSC (just really small amounts 0.00000001 etc.) because consensus on Test coins is already bonkers because of DEx

Fair point - let's see what Bitoy says about update frequency so participants don't think they've broken consensus just due to delayed updates - IIRC he's at 30 mins currently.

I'm now updating every time there is a consensus check. (Hoping blockchain.org doesn't block my ip

Trying to update transactions for PDex checking. I'll be making some changes to the database to meet tachikoma's dex API.

Finally 100% consensus

https://masterchest.info/consensus_masterchestinfodev.aspx

Bug is fixed.

(I tried to update the api so that it checks for new transaction every time consensus queries it.)

Zathras,

Thanks for the advise regarding customerror. (I created a Generic Error page to catch bugs in the future bugs =)

Masterchain, Mastercoin-Explorer and MyMastercoins are now fully synched (MSC).

Development should move faster now since we don't have any more Class A transaction for DEx.

Quote from: Tachikoma on January 12, 2014, 12:34:35 AM

Bitoy a little summary for the work Graz, Zath and me have been doing this night/day:

We changed the date from which we started calculating the vesting development coins to the date the last block was accepted for the fundraiser. The new timestamp is: 1377993874
Our implementations should be 100% on consensus now but your engine appeared to have stopped working so we can't be 100% sure, also Zathras is still updating his blockchain with the new code.
Two new pull requests: Clarifications on the development Mastercoins and an update on the verification API to make it work for DEx consensus.

Ok will update dev coin calculations today.

I update from blockchain.org every 30 minutes. Ill try to update more often ( but I'm very conscious that blockchain might block my IP address

Quote from: Tachikoma on January 11, 2014, 07:20:44 PM

I'm on ##mastercoin and #mastercoin, if Grazcoin has a problem with it we can use cryptocat as well but it won't have logs.

Bitoy already went to bed, but he never replied to my email so I can he won't be around.

Cryptocat doesn't work in ipad.

I didn't get your email (in my gmail).

I thought we are already synced but when I checked this morning. Any changes in the formula?

1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
MM=11063.84979076
ME=11063.58647044

Yes Tachikoma, finally we are synched to the last msc.
11040.08115172

Grazcoin I think is just a block time away from synching 11039.54172323

( It's 2am here. I'm going to zzzz =)

Edit
Grazcoin the difference is only 0.000000004. Maybe you rounded to 7 digit instead of 8?
11040.7003806
11040.70038056

Quote from: grazcoin on January 11, 2014, 04:51:27 PM

https://masterchest.info/consensus.aspx shows now -129.34% (negative number)
It seems like MyMastercoins is way out of sync.

Sorry accidentally pushed the "reset database" button. It's now back

For the Exodus Coins Generated I used the following formula

   Time1 = $Time of latest block in seconds
   dBlockDateTime = DateAdd(DateInterval.Second, Time1, New DateTime(1970, 1, 1, 0, 0, 0))

'Calculate number of seconds from September 1,2013 to Latest Block Time
   SecondsFromSept12013 = DateDiff(DateInterval.Second, #9/1/2013#, dBlockDateTime)

   Dim Gencoins As Double = (1 - (0.5 ^ (SecondsFromSept12013 / 31557600))) * 56316.23576222
   Gencoins = Round(Gencoins) to the nearest 8 decimal

Edit

OK will change 31557600 to 31556926

Consensus is almost complete.

Consensus   Address     MyMastercoins   Masterchain   Mastercoin-Explorer   Masterchest
181k55nxGuqDRpJx3iU43T4wJznf7ZazFN   0.043   0.043   0.043
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL   376.1846   376.1846   376.1846   376.2706
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji   0.043   0.043   0.043
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P   11034.92330741   11035.15874017   10812.36900066   11034.92330741
1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm   60.12630845   60.12630845   60.12630845   10.00

Masterchain, mastercoin-explorer and mymastercoins are already synchronized except for the exodus address.

For the exodus address Mymastercoins recalculates based on the time of the latest block.
(Mymastercoins and masterchest has the same balance)

99.78 % consensus check.
https://masterchest.info/consensus.aspx

I'll recheck my exodus calculations.

Edit
exodus address dev msc is now recalculated based on the latest block.
only 4 valid msc send transaction as of 1/10/14

Quote from: Tachikoma on January 09, 2014, 04:59:26 PM

Bitoy (and others). The spec mentions that the amount used in a Selling Order should be reserved and thus removed from the balance. I did a consensus check between us and I think you are not doing that yet. Because of this its harder to compare numbers; could you check your output and see if you could build in reserved funds to your solution?

Hi Tachikoma,

I've deducted the selling order from the balance. Please check again.
http://mymastercoins.com/jaddress.aspx?CurrencyID=2

btw where is your test MSC json ?

Congrats Zathras!

Looks like mastercoin will be moving at a faster pace this year with the additional full timers

Quote from: superfluouso on January 09, 2014, 08:10:42 AM

Bitoy and Zathras - do you folks have wallets available for testing with Test MSC? Bitoy, I know you have a wallet but last I had heard you were sorting out the SQL issues - Was that resolved? Zathras, I really like the looks of the sneek peak - any updates on opening the wallet for testing purposes? Thanks!

Mymastercoins thin client wallet is at
http://mymastercoins.com/MyMSCWallet.aspx

I'm trying to remove reliance on bitcoind.exe. In order to do this

1. I need a way to generate bitcoin address with a private key. (Like bitaddress.org)
2. Sign transactions and send them (via blockchain.org pushtx).

Sample scripts greatly appreciated

Quote from: Tachikoma on January 06, 2014, 07:00:35 PM

Bitoy, Grazcoin, Zathras; could you all give me your URL's for the test MSC verification API?

I want to prepare for the DEx consensus

Edit: Already mailed it out as well since I want this sooner rather then later.

For Test MSC
http://mymastercoins.com/jaddress.aspx?CurrencyID=2

Quote from: Tachikoma on January 07, 2014, 03:53:04 PM

Shouldn't the recipient be 76?

You are correct 76. Therefore transaction is valid under p&d level 2. ( class a is draining my brain

Quote from: Tachikoma on January 07, 2014, 10:10:41 AM

Quote from: zathras on January 07, 2014, 09:49:09 AM

I've got to throw it out there - I think largely the unasked question - where is the value in all these rules for Class A at all if P&D could be used in any decodable scenario?

This has been going on in my mind as well; I just was afraid of putting it out there. Since we only allow Class A for Simple Sends P&D is actually a really viable way of doing things. When writing my P&D description in the post above I realised that we are doing a lot of extra things.

I think if we take P&D as standard that everything will be a lot easier to parse. I will do some thinking and see if I can formulate a way of parsing Class A so that P&D is the initial thing we try.

I think transaction ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5 would automatically be solved if we rewrite the spec to always use P&D and go from there.

I already use p&d first when processing class a transactions.
However
ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5
Will not pass p&d level 2 because the data seq is 75 and there is no seq no 74 as recipient address.

Zathras,

Please check
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc

It is valid under peek and decode level 1.

This should fix address
1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7
15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby

Hi Zathras

In your site
1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm Has a balance of 60.12630845 MSC
https://masterchest.info/lookupadd.aspx?address=1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm

In the consensus masterchest balance is 10