Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 37. (Read 129207 times)

Excellent.  Getaddresses is what i'm looking for (i'm now integrating it with my wallet, hope to be ready for testing next week =).     

Happy to help

According to the documentation listreceivedbyaddress{0,true} will provide a list of all the addresses in the wallet.  In testing I discovered this wasn't accurate however as change addresses were not included even if they held a balance.  So I do that first, and then run a second pass with listunspent to grab any missing addresses.

FYI if the user has to have bitcoind installed that's all that's required to use my library if you wanted to go that route.  The library already has a mlib.getaddresses function to enumerate all addresses in the connected wallet with the above method (just returns a string array of addresses).  I'm not sure if that's in the old version but I'll be pushing my new v2 library up to git this weekend anyway

Thank you Zathras,
I'm able to run bitcoind.exe on the amazon aws.   

Is there a method in bitcoind.exe to list all address in a wallet?  I'm think of getting all the bitcoin address of a wallet then getting the MSC transactions from mymastercoins.com.   This will make it a "semi-thin" client  (because the user still has to have bitcoind installed).   

     

As David said, please go comment on that thread. Also, I'll post this here for convenience:


I need an email address from zathras and grazcoin still, per my PMs to the devs. We want to be able to reach you guys by email and copy you on other emails that may interest you. Also, we want to figure out what it would take to get some of you to quit your day jobs.

For all GITHUB Repo owners:

Please make sure that you have "mastercoin" somewhere in the "description" field.  We need this so that when someone does a search for mastercoin that your repo will come up. 

Some of the repo's do not have that right now and therefore might not be getting exposed to potential developers or users.

Particularily if your repo is called masterchest or masterchain, it might not be hitting this search:

https://github.com/search?q=mastercoin

thanks!!

I've just posted a separate thread detailing my proposal to "Standardize the Distribution Rate of Dev MSC via the MSC Protocol"

I hope anyone that wants to discuss this topic will come over to this thread and offer me their feedback.

https://bitcointalksearch.org/topic/proposal-for-standardizing-the-distribution-rate-of-dev-msc-via-the-msc-protocol-342431

Partial Sneak Peak of my post:

I propose we formalize the distribution of "Dev MSC", to mirror the amount of Dev MSC generated each month. Further more that these Dev MSC be distributed in proportion to the amount of BTC won by participants in Mastercoin bounties that month. With the intension being, that this distribution process will be fully controlled by the Mastercoin community via the existing Bounty system and up coming Proof of Stake voting.

Lets talk some simple math here.

Simple Dev MSC Distribution Equation:  A / B = C * D = E
(A) Amount of awards an individual earns in BTC during a 30 day period, divided by,
(B) the total amount of BTC awarded during that 30 day period, equals
(C) his or her individual award percentage, times
(D) the total Dev MSC generated during that 30 day period, equals
(E) the amount of Dev MSC awarded to the individual in addition to his BTC awards during the 30 day period.

Example #1 (using round numbers):
A (100 BTC) / B (1,000 BTC) = C (10%) * D (1,000 MSC) = E (100 MSC)

There are 56,316 Dev MSC that will ever be generated.
28,158 Dev MSC will be generated this year or 2,346 MSC each month.
So if a developer won 10% of the bounties this month he or she would earn 234.6 Dev MSC (worth 35.19 BTC / $24,633 USD at current MSC / BTC / USD prices).

If you're sitting on a slow connection you could spin up a free instance over on AWS (Amazon), run bitcoind there and make your RPC calls to it through an SSH tunnel.  That way you don't need to download anything over your own connection.  Just remember to only keep a small amount of test funds there

Thanks Zathras.  I did that a while ago and it worked.   But now blockchain doesn't support "signrawtransaction".  So i'm stuck again.


I'll try to download the entire bitcoin blockchain (with  my slow internet speed it will take days) then test rpc calls on it.

 

Updated MyMastercoins.com 

Added explanation why a transaction is invalid
http://mymastercoins.com/Transactions.aspx

Allow partial payment of Purchase Offer.

Generate MSC Dev coins for the Exodus Address.
7,966.90477835 Generated Coins MSC Dev Funds as of 11/20/2013 9:00:07 AM

Hi,

I made those tx as a test, because I was looking into ways to reduce transportation cost for the faucet, but switched over to regular multisig tx, because they were marked as invalid on mastercoin-explorer, if I recall correctly.

But I noticed that all outgoing transactions of 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd are rendered as invalid on mastercoin-explorer.com since some hours:

http://mastercoin-explorer.com/addresses/14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd

mastercoin.info and masterchest.info still declare them as valid.

Is this in anyway connected? The above quoted tx are derived from this address.

If you're using blockchain.info have a look at http://blockchain.info/unspent?active=$address - I could (fairly) easily give you a new function in the library that only returns the transaction hex for the vouts (ie the juicy multisig bits - which can be done offline, no need for bitcoind/qt).

You could construct the first part of the transaction hex (vins) using the info from blockchain.info's unspent API and then put the two together prior to signing.

Without looking at what you're trying to do further I don't know if this will help, but just a thought

Yes, crazy bitcoin price the last few days.  Now coding contest is around 150k. That is still a lot of money

Thank you for the heads up. My only problem now is how to send a multisig (rpc).   

Agreed, once we have compatible api we can easily check double check transactions. 

For a brief moment yesterday - the bounty on this coding contest exceeded $270,000 in value.  That is far more than JR originally anticipated (around Aug 10) would be spend on the entire project - start-to-finish.  Glad you guys are working hard on this.  You sure are going to earn one hell of a lot of money.  

I agree we should invalidate for now.  I'll add some code to invalidate these.


My view sits with Grazcoin and Tachikoma, we're complex enough already.  Future revisions can add features to the base implementation, but we need to walk before we run.


You are of course welcome to use any of my code (though I'll need to push up the latest version of the library, it's out of date on git).  With that said though, I don't think it's going to help you in this case.  My library depends on a bitcoind/qt instance to loop through the unspent outputs for a given address and select inputs to use as vins for the send transaction.  It's not really suited to a thin client.

I had intended to modify my wallet to support thin client functionality way, way down the track - it's not high on my priority list though (since Tachikoma has taken point on thin client to date) - my primary focus is on a local implementation with no centralized source of truth for now.  Once we all have compatible APIs (and thus multiple sources of truth) thin client functionality will likely get pushed up my priority list more.

Thanks!

Hi Zathras,

Can you post again how to send a multisig using your library (You posted this before but I can't find it =).

Thanks.


(I'm trying to build a thin client windows wallet rpc blockchain.info but blockchain.info doesn't support "listunspent".  )   

I agree with you on simplifying the system.  Allowing only one purchase offer for an address per currency.

I completely agree with Grazcoin on this one. There is enough difficult logic already involved even without making things harder to parse. We should keep it as simple as possible and add more interesting options when we mature enough.


I agree with you on this mainly because I don't want to spend anytime going back to the beginning to support this one edge-case. We can add support for those addresses in later.

-1
This is not according to the contract that the seller offered.
If the buyer already sees that he might be late - he better not send the tx (and lose only the fee).
No need to complicate further the already complicated distributed exchange rules.


Since we allow only one sell offer for an address, we could consider only one purchase offer for an address to simplify the protocol.
I don't see a real reason to complicate the logic here too much, so if we do keep multiple purchase offer option, let it follow the basic rules, ignoring the fact that these are purchase orders from the same address.

while updating my parsing for less standard tx, I see BIP11->BIP11 tx like:
https://blockchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
We never really said anything about more complicated addresses holding MSC (e.g. BIP11 or BIP16).
Until we say otherwise, I suggest that invalidate these tx:
http://masterchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf.json

That's how you parse it:
https://masterchest.info/lookuptx.aspx?txid=6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
http://mastercoin-explorer.com/transactions/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf

Respecting these addresses is not too difficult, so it is mainly a decision issue.