Bitoy
|
|
November 27, 2013, 09:57:00 AM |
|
Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.
Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?
I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?
It's Bitoy. (Bitboy sounds good also Here is my 2 cents To keep it simple transactions should not be treated as payment. consider this example. 1. User A sends a sell offer 2. user B sends a purchase offer to User A 3. User B changes his mind and sends another purchase offer to User A Will transaction 3 be considered a payment for transaction 2?
|
|
|
|
Tachikoma
|
|
November 27, 2013, 09:58:00 AM |
|
I would say yes. It's basically free MSC for User B. Why not give it.
|
|
|
|
zathras
|
|
November 27, 2013, 10:07:01 AM |
|
Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.
Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?
I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?
Hehe that gave me a chuckle every time I see you post to 'BitBoy' I keep wondering if I should point that out Actually at the current time I do the same as Bitoy; Bitcoin transactions with an output to Exodus but no Mastercoin data go into an 'unknown' table which I subsequently search for payments. If it's got Mastercoin data a decodable Mastercoin transaction it's not looked at as a payment. The spec doesn't call for payments & Mastercoin transactions in the same Bitcoin transaction, but it doesn't specifically exclude it either so I guess it's another topic we should get consensus on and lock into the spec. I'm ambivalent on this really, it's not much work to adapt to allow it. Haven't had time to think about future implications though. Thanks!
|
|
|
|
zathras
|
|
November 27, 2013, 10:11:13 AM |
|
Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.
Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?
I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?
It's Bitoy. (Bitboy sounds good also Here is my 2 cents To keep it simple transactions should not be treated as payment. consider this example. 1. User A sends a sell offer 2. user B sends a purchase offer to User A 3. User B changes his mind and sends another purchase offer to User A Will transaction 3 be considered a payment for transaction 2? I would say yes. It's basically free MSC for User B. Why not give it.
Would this not result in a bunch of unintended 'micro' transactions of 0.00000### MSC?
|
|
|
|
Tachikoma
|
|
November 27, 2013, 11:51:49 AM |
|
Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.
Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?
I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?
Hehe that gave me a chuckle every time I see you post to 'BitBoy' I keep wondering if I should point that out I wish you did, now I feel like an ass :p Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.
Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?
I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?
It's Bitoy. (Bitboy sounds good also Here is my 2 cents To keep it simple transactions should not be treated as payment. consider this example. 1. User A sends a sell offer 2. user B sends a purchase offer to User A 3. User B changes his mind and sends another purchase offer to User A Will transaction 3 be considered a payment for transaction 2? I would say yes. It's basically free MSC for User B. Why not give it.
Would this not result in a bunch of unintended 'micro' transactions of 0.00000### MSC? Yes, it already did in my implementation. My implementation of sorting through the money is pretty dumb. That part of the code knows nothing about Mastercoin data or what it looks like. So I can't right now check if it's a possible Mastercoin transaction. I agree that it's probably cleaner to reject these 'micro transactions' though. Unless somebody can think of a reason to do not do it let's say we don't allow these payments. Grazcoin, if you could chime in that would be great.
|
|
|
|
Bitoy
|
|
November 27, 2013, 12:00:25 PM |
|
I would say yes. It's basically free MSC for User B. Why not give it.
It's a side effect (given that its a good one for the buyer). But As Zathras pointed out it will create unintented micro transaction bloat.
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
November 27, 2013, 07:56:46 PM |
|
Guys - this is yet another example of a spec-interpretation issue with more than one right answer. I originally did not intend MSC messages to count as BTC payments for purchases, but if that makes things simpler, then I'm ok with that. However, keep in mind also that we want to keep the user interface simple, and these mini-purchases might confuse people. As you know, we're working out the details of hiring some of you full-time. Depending on how that works out, one of you will probably be in charge of coordinating these discussions and making decisions when it's not too controversial. I'll get involved on the controversial ones
|
|
|
|
Tachikoma
|
|
November 27, 2013, 07:59:55 PM |
|
Guys - this is yet another example of a spec-interpretation issue with more than one right answer. I originally did not intend MSC messages to count as BTC payments for purchases, but if that makes things simpler, then I'm ok with that. However, keep in mind also that we want to keep the user interface simple, and these mini-purchases might confuse people. As you know, we're working out the details of hiring some of you full-time. Depending on how that works out, one of you will probably be in charge of coordinating these discussions and making decisions when it's not too controversial. I'll get involved on the controversial ones I'm guessing that's our final vote. Grazcoin I'm going to assume you have no problems with discarding these payments so we can move on!
|
|
|
|
grazcoin
|
|
November 27, 2013, 08:59:39 PM |
|
Guys - this is yet another example of a spec-interpretation issue with more than one right answer. I originally did not intend MSC messages to count as BTC payments for purchases, but if that makes things simpler, then I'm ok with that. However, keep in mind also that we want to keep the user interface simple, and these mini-purchases might confuse people. As you know, we're working out the details of hiring some of you full-time. Depending on how that works out, one of you will probably be in charge of coordinating these discussions and making decisions when it's not too controversial. I'll get involved on the controversial ones I'm guessing that's our final vote. Grazcoin I'm going to assume you have no problems with discarding these payments so we can move on! discard. move on. if a tx has some type (simple send, sell, accept), it is not a payment.
|
|
|
|
grazcoin
|
|
November 27, 2013, 09:18:47 PM |
|
Although my validation is not finalized (missing some code in dist exchange, in simple send from exodus, and on perfect sequence), I already export the mastercoin_verify https://masterchain.info/mastercoin_verify/where are the others to compare? I would like to know at least if some part is similar ;-)
|
|
|
|
djohnston
|
|
November 28, 2013, 06:15:30 AM |
|
LETS GET THESE GREAT DEVELOPERS FULL TIME ON MASTERCOIN In my opinion the best way to do this is reliably and predictably vest the Dev MSC generated each month and we would have $312,500 USD in BONUSES, to add to the already great BTC bounties we offer. If that's split between the current four Devs they would have made $78,125 USD in Dev MSC EACH MONTH the last three months = $234,375 USD and they would have quit their jobs by now. It really is that simple. Even if we have 12 full time Developers working right now they would still be making $26,041 per month each just in bonuses from Dev MSC! There would have to be 36 full time developers splitting the Bonus evenly to equal $8,680 USD per month and they would still be better off to work for the BTC and Dev MSC than take a $6,000 per month salary. I say we unleash our most powerful weapon, thus far left neutered and under used for lack of a specified "Distribution Rate" in the MSC protocol. I hope you will all vote in this poll going on right now and support the idea of actually using this Dev MSC that sitting there unused right now, for the most important purpose of all. Actually developing Mastercoin features and rewarding those who are doing just that. https://bitcointalk.org/index.php?topic=348028.0
|
“The state is that great fiction by which everyone tries to live at the expense of everyone else.” ― Frédéric Bastiat
|
|
|
zathras
|
|
November 28, 2013, 08:13:46 AM |
|
Quick (well not so quick if you read it!) X-post from rbdrbd's thread just in case any of the other devs who don't use .NET want to see how my library encodes transactions. Run the result through decoderawtransaction to see what it's doing. DEVELOPERS ONLY. THIS IS NOT READY FOR END USERS. THANKS!Hey rbdrbd, Here's the cli wrapper you asked for. Just provides a binary to expose the library functions for encoding transactions. Note there is no state or validation here, we're just creating the transaction. The result can be signed & broadcast if you're happy with the output. Please use with care, it's completely untested (there could be bad numeric conversions or other bugs for example) so only test against a wallet with fractional amounts Let me know how you get on with it under Mono. I'll take a look at putting sqlite support into the engine over the weekend, but for the next few days I really need to hunt down these bugs that are messing up my DEx states. Thanks! Built against .NET4. Pick it up from here. Note, use the -type= type switch to select between send, sell & accept. Simple send:Use the bitcoinrpc switches from the engine and -am (amount) -to (to address) -fr (from address) and -cu (currency type) switches. For example: MasterchestCLI.exe -bitcoinrpcserv=127.0.0.1 -bitcoinrpcport=8332 -bitcoinrpcuser=ooo -bitcoinrpcpass=ooo -type=send -fr=1KUu56RMsafvgwxkiGHmptrLLmBgQ16uQG -to=1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 -cu=MSC -am=1.234 Sell offer:Use the bitcoinrpc switches from the engine and -am (sale amount) -fr (from address) -cu (currency type) -of (offer amount) -tl (timelimit) -mf (minfee) switches. For example: -bitcoinrpcserv=127.0.0.1 -bitcoinrpcport=8332 -bitcoinrpcuser=ooo -bitcoinrpcpass=ooo -type=sell -fr=1KUu56RMsafvgwxkiGHmptrLLmBgQ16uQG -cu=MSC -am=1.234 -of=0.5 -tl=6 -mf=0.0001 Accept offer:Use the bitcoinrpc switches from the engine and -am (purchase amount) -fr (from address) -to (to address) -cu (currency type) switches. For example: -bitcoinrpcserv=127.0.0.1 -bitcoinrpcport=8332 -bitcoinrpcuser=ooo -bitcoinrpcpass=ooo -type=accept -fr=1KUu56RMsafvgwxkiGHmptrLLmBgQ16uQG -to=1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 -cu=MSC -am=1.234
|
|
|
|
vokain
Legendary
Offline
Activity: 1834
Merit: 1019
|
|
November 28, 2013, 08:34:26 AM |
|
As soon as my damned laptop will sync the blockchain 100% I will join in on testing!! Wish I could help more on this front in the mean time guys. Also, can our devs please check the last few posts on the main thread, around the same time as this time stamp? I'd like you to weigh in your thoughts about things very relevant to you.
|
|
|
|
Tachikoma
|
|
November 28, 2013, 09:24:09 AM |
|
Although my validation is not finalized (missing some code in dist exchange, in simple send from exodus, and on perfect sequence), I already export the mastercoin_verify https://masterchain.info/mastercoin_verify/where are the others to compare? I would like to know at least if some part is similar ;-) http://mastercoin-explorer.com/mastercoin_verify/addresses Mine is there. However at the moment my data is not working properly yet. I still need to find the time to update my distributed exchange code after yesterday's decision.
|
|
|
|
|
Tachikoma
|
|
November 28, 2013, 02:28:54 PM |
|
Grats on getting that out in the wild!
|
|
|
|
|
Bitoy
|
|
November 28, 2013, 04:53:42 PM |
|
Grats on getting that out in the wild! I was hoping to get this out next week just so that we can post tramsactions but the blockchain loading is really very slow (50 weeks to go
|
|
|
|
zathras
|
|
November 28, 2013, 06:28:20 PM |
|
Grats on getting that out in the wild! I was hoping to get this out next week just so that we can post tramsactions but the blockchain loading is really very slow (50 weeks to go Ouch. Did you not have too much luck running bitcoind over at AWS and making your RPC calls to bitcoind there for your initial testing? Please don't hesitate to let me know if you need help with this btw, anything to help with development speed
|
|
|
|
vokain
Legendary
Offline
Activity: 1834
Merit: 1019
|
|
November 28, 2013, 06:32:22 PM |
|
Is there anything I can help with in the meantime while Bitcoin-QT is syncing?
|
|
|
|
|