|
Is it still possible to send to the address to establish a position in Nxt?
|
|
|
|
Bitshares and Mastercoin are similar but Bitshares is more decentralized and pays dividends.
What makes you say Bitshares is more decentralized? What I've seen and read, I can't find anything that would back this up. The amount of PTS that was mined in a week surprised everyone and what I've learned it was/is mostly done by big players. There was only a few days when regular folks could find blocks by themselves. I'm happy to be proven wrong, but so far I haven't seen anything that would back up the claim that PTS mining would have been better model for the little people who can't invest a lot up front versus Mastercoin's "Exodus August" model, where even small players had an equal possibility to invest. Small players can BUY PTS today just like they could buy Mastercoin. Furthermore, there are 1000's of small players who have received PTS and anyone mining within the first 48 hours generated at least one block. How many people currently own Mastercoin? From a speculator's point of view, obtain 2-3 hundred coins from both projects and wait...Sure win! 200 PTS ( < 2BTC) is fine, but 200 MSC ( > 20 BTC) seems really a lot to invest. I mined PTS and was an early adopter in MSC @0.01BTC - just for clarification. On the other hand at least one of Mastercoin, Bitshares and Next will achieve at least parity with BTC imho... Colored coins is the potential dark horse in this race...in my mind at least... |
|
|
|
I really want our own subforum here. We're way to integrated with bitcoin to have our own forum, IMHO
Yeah, +1 to that. That would be great. May be a bit tough to get, given their stance on breaking up the altcoin forums so it's not such a mess (i.e. "no"). Worth a try though.  |
|
|
|
[...]
With all due respect Bounty's work very well, but it comes as an afterthought to full time employment. Bounties foster competition and it is good for getting to see what potential candidates for a project are made of. How how about in a situation where we already know the skill and ability of said developers? Bounties in these cases become counter-intuitive because the ability of the skilled developer to produce quality work is not based on actual skill, but on actual time he can afford to give after his first priority which is the other job that puts food on the table. We seen several instances when tachikoma had to sleep and go to work.
The long term hiring works way way better for developers who we already know have the desired skill, competence and drive from a track record. It would mean that Mastercoin is priority for developers and they already love working on mastercoin why not enable them to give their all to mastercoin? We have several of these guys from the previous bounties and I think it best to do everything to "poach" them while we can. Don't forget there are competitors and this is also a race to the top of who can achieve a network effect for success. Not only do we want to achieve a network effect, but increase the switching costs by having such rich and intuitive system that makes it hard for users of mastercoin to find any other comparable platform. And what we need right now is to get the devs to focus full time on developing essential mastercoin features than to worry about two things at once. : "Concentrate all your thoughts upon the work at hand. The sun's rays do not burn until brought to a focus."
what does everybody else think?
I think thats a well made, and considered post. A fixed and agreed monthly/weekly wage for a given contracted dev, should not really be a problem for an organization serious about developing the benefits and claims, made for Mastercoin. Managing it is a challenge, granted, but a necessary step-up in operations to achieve current goals and expectations, i would have thought. Fully understand the leap of faith felt, jumping out of the ability to provide for commitments consistently, into something not so known and reliable, but thats what its going to take. Thank you Ola, this is a great post. When you get down to it, most people are risk adverse. This includes 90% of the developers I've employed over the last 8 years. That's why they get a job with me, instead of starting their own business. As others have mentioned, if you are employing developers, instead of entrepreneurs (which usually look for a different kind of payout with higher risk, but potentially higher reward), then a steady paycheck in fiat or possibly even BTC will do wonders. Bounty money is so nebulous and unreliable in comparison for someone that has kids and a mortgage, as zathras and Tachikoma have brought up earlier. It's great it got the project this far, but you guys may want to consider a slightly different approach moving forward as this thing gains steam. As far as the dev team, here's my two cents: * Start with two full time devs, then look at moving to 4 as things settle in and it makes sense (i.e. scale up once you have the basic structure and workflow in place) * One of the devs is given the team lead role * Pay devs in fiat/BTC, as 1099 contractors if possible (check the IRS checklist on this) * Utilize Scrum development practices * Sign up for sprint.ly and use that to manage your development process / product backlog...integrates directly into github, awesome interface & product (Pivotal tracker is another one -- Trello is a good tool, but not well suited for this at all...) * Ron/JR possibly share the Scrum "product owner" role, and put items on the backlog for the devs to work off of * Backlog and burndown chart are public, and the community can vote/influence the items on the backlog * Bounties, etc still exist for non-core-team devs, who can run independently with their own efforts If you do it this way, and your devs are of high enough skill, you don't need a dedicated PM role. I find that role not very useful with small, talented dev teams (your team lead will be half dev, half PM/interface anyhow). I would still *strongly* consider at least one of these devs working on the "mastercoind" concept I outlined earlier ( https://bitcointalk.org/index.php?topic=265488.msg3666117#msg3666117) for the reasons I listed earlier ( https://bitcointalk.org/index.php?topic=265488.msg3667049#msg3667049). It just makes sense and will move this project along SO much quicker, especially in regards to enabling non-core devs to build products and tools around mastercoin....I mean, just think of what bitcoin would be like without bitcoind??? And...this probably goes without saying, but don't get too glib that Mastercoin will maintain this current front-runner position. That's the classic downfall of every front-runner...complacency. A healthy dose of paranoia is always good |
|
|
|
I +1 Killerstorm's explanation. We absolutely need different Mastercoin implementations from the get-go to compare our interpretation of the spec. I already wrote an addition to the spec that should make comparing implementations very easy. For those interested you can read the initial draft of the verification API here. I (respectfully) totally disagree. Why is this necessary? Do we need 10 different bitcoind implementations to compare the interpretation of the bitcoin spec? If the Mastercoin spec is open to multiple material differences based on its "interpretation", then that tells me that it needs to be revised to remove ambiguity. Currently, it has a lot of that and I've started asking questions to help close that gap around some of these new features. I know you and many others have done a ton in this area, and I'm sure others will help out as well. However, some small level of ambiguity will still persist, so to your point, I agree that we maybe need 2 full parser/stack implementations, but not 10. It's simply not something that the average mastercoin developer should have to deal with. In the world of bitcoin, 90%+ of developers just hang off of bitcoind. That doesn't stop anyone from developing their own bitcoin parsing tools (e.g. sx, and others). It's just dumb to require everyone to develop their own block parsers just to be able to do anything with bitcoin. killerstorm may say the parsing mastercoin transactions is so simple a monkey could do it, but I don't know the first thing about parsing multi-sig transactions, for instance, and I'm sure the vast majority of devs on this board don't either (nor do they care). If I was going to add value to mastercoin, I'd rather work on the application I had in mind itself, rather than dinking around with bit fiddling to get my "interpretation" of the spec to show 907.3302929 MSC for transaction 3f04398298292fbcdd0f vs my buddy's showing a balance of 907.594029. Come on....waste of time. Having each developer basically creating their own parser off the spec when we could have one mastercoind that 90% of devs use is not optimal, in my opinion. I'd think that we want 90% of devs on this creating end-user solutions that add real value around mastercoin's awesome feature set, NOT more parser implementations that result in the confusion and issues we've been seeing lately between masterchest, mymastercoins, and master-coin explorer. Imagine that x100. I say, if you're the 10% of devs that want or need to create your own parser and spec engine, go for it. Otherwise, use mastercoind, hook into the realtime event feed, spend 10 minutes writing the code to parse apart the JSON for the events you want, and focus on your features. That is the only way Mastercoin is going to win this race. |
|
|
|
Once we have a solid mastercoin API library that can work across multiple languages (optimally do basic parsing in C, then use swig, etc to take out to Python, Perl, Ruby, etc) then the skill bar level is DRASTICALLY lowered. At that point, you can get generic webdevs and generaic devs that have a good mid-level understanding of bitcoin/mastercoin to do the work. Parsing transactions is an easy part. Maintaining the state is the hard part. You need some means of representing the state, i.e. balance, pending orders and so on for each address. Then you read a stream of messages and apply them one by one according to certain rules. E.g. for simple send you need this: 1. check if sending address balance is sufficient 2. decrease balance of sending address by X 3. increase balance of receiving address by X To implement more complex rules you need more state variables for each address. Now, the question is, are you going to implement it in C? How? Implementing only parsing in C and rules in high-level language won't have an effect you're aiming for: parsing itself is straightforward, but rules aren't. Example: An address marked as savings can only do simple transfers (transaction type=0). All other transaction types require addresses without a reversibility time window. This definitely makes sense: we do not want to define how savings feature interacts with all types of transactions But what happens if I declare an address as savings after I have submitted an offer? Does it cancel a pending order? Or is this 'mark as savings' command ignored? Different implementations might implement it in different ways, and getting it right is very, very tricky. On the other hand, deserialization is something a monkey can implement when it has the right tools Great points. I'm no bitcoin expert obviously, but I know with bitcoin there are blockchain parsers (such as https://github.com/znort987/blockparser) that can run through and compile stats on the block chain (e.g. simple aggregate metrics, a list of addresses with balances and their balances, etc). Obviously, the rules behind mastercoin are a very good deal more complex than bitcoin, but perhaps some kind of parser could be written (not necessarily in C) that could run either as a one-shot (parse through the chain and output) or resident (with streaming output). Output would be in a simplified JSON-formatted structure, that comprise "absolute actions" that have been validated through the spec-derived rule set encoded into the parser itself. e.g "address A sent address B 50 MSC". In this case, the parser has done all of the difficult parsing and validation (such as, the sending address having the balance, the transaction being a valid Class A/B/C one, whatever else)...it outputs this in JSON format, a higher level web tool can either read it from a file (streamed or as a static/batch run) or maybe attach to the process's event interface via TCP/IP and get it that way. other examples: "address C put out an offer for 50 MSC @ .50/ea. offer ID is 1234". "address D bid on offer 1234 for 20 of the 50 MSC" "address E created a smart property named 'foobar' with currency ID 4567" This way, all higher level utilities could hook into this Mastercoin daemon, which would take care of implementing the guts of the spec and take it out to a higher level streamed, JSON encoded "absolute" API, which would focus on things that have actually happened, after all of the parsing and rule validation have been taken into effect. The daemon could be available for windows, linux and mac OS X. A JSON RPC-driven query interface would also be available to allow querying of specific smart properties, transaction IDs, etc. Hell, write the thing in ruby and use Tachikoma's work as a base for it. Or make it in python (everyone loves python, and that way I'll want to hack on it! :p) ....We shall call it.... "mastercoind" (*pinkie over mouth*) Maybe I am smoking crack here and this won't gain us much. Just thought I'd put it out there to get the ball rolling for potential solutions. If doing the above makes sense, it would bring us in line with the way bitcoin does things (e.g. bitcoind hooking into exchange sites, armory client, p2pool, pushpool daemon, bitcoin-qt, etc), and speed new development efforts up 20x, as what we're doing now seems a bit similar to forcing everyone who wants to build their own computer to create the CPU from scratch, instead of just buying the parts and slapping them together. |
|
|
|
I have 2 things on my mind...and I think these points need to be address quickly to speed up development and foster outside development.
1) I think its high time that 2 developers, or at least Tachikoma is hired or contracted full time for at least a period of 2 years... this is a minimal relative cost of doing business considering the potential fast turn around of the initiative, due to having someone work on the project full time. At this point Tachikoma who blazes the trail, mostly leading developments and improvement shouldn't be scrounging around working to pay bills. His focus should be on developing and testing so we can have something dependable in no time: Success in anything depends on FOCUS, and right now our main devs have jobs on the side trying to pay bills. We should take a page from the bitcoin foundation and emulate the hiring of Gavin Adresen.
"Concentrate all your thoughts upon the work at hand. The sun's rays do not burn until brought to a focus."
2) Is there a plan to develop something higher level to interface programmatically with mastercoin? an api maybe, although I couldn't fathom how it will work to do :
simple sends
confirmations
betting etc..
I also thinking of designing mastercoin into my system but do not know where to start, especially if this will be addressed later.
If you are in favor of one or two of these points please echo this post.
Echoing! +1 This is what I raised up in my post as well. This project *absolutely* needs multiple full time developers. Mastercoin foundation needs to make that happen ASAP. At my business, I can hire 3 developers to work full time for me (as well as around 13 other assorted full time engineers) and we pull in less each year than the mastercoin foundation has sitting around. Not sure why this can't be done with Mastercoin as well. Run it like a business. Priority number 1. Once we have a solid mastercoin API library that can work across multiple languages (optimally do basic parsing in C, then use swig, etc to take out to Python, Perl, Ruby, etc) then the skill bar level is DRASTICALLY lowered. At that point, you can get generic webdevs and generaic devs that have a good mid-level understanding of bitcoin/mastercoin to do the work. The ruby, etc library is good, but we need it available for a wide variety of langs, without a bunch of implementations that all have their own ideas how the blocks should be parsed (we get the problems we are seeing today). This should be priority number 2. Pay for a *reference* C implementation and bindings to other languages can be easily made. Any new standard that comes out in the business world (e.g. audio codecs, etc), they implement a standard reference implementation, and vendors follow suit with their implementations, comparing their test vector results to that. Otherwise you have a mess. Why doesn't mastercoin follow this best practice that has worked so well for the standards industry? |
|
|
|
Just a small suggestion: the "Send transactions" section for an address currently shows the source address for each transaction. To me it would make much more sense to show the destination address instead. Annotated screenshot: https://i.imgur.com/BGq4vtL.pngYeah, I agree. And possibly show them both on that main page itself (maybe not the address page), and truncate, using tooltips on hover. ...I find myself pulling up a bunch of tabs for each transaction just to look at the destination addresses...the transaction ID (currently truncated) could be a tooltip as well. Easy with twitter bootstrap (good choice ). http://getbootstrap.com/javascript/#tooltipsI thought it had a css-only way to do this as well...but I guess that might have been taken out in v3.... |
|
|
|
There have been thoughts about setting up a dedicated forum. 1. FYI, forum.mastercoin.org redirects to this very thread right now, for convenience  2. I opened a Google Group for Mastercoin that nobody except me ever used  3. Right now the consensus is that it's best to remain on bitcointalk, because we want to position ourselves as part of Bitcoin, not an alt or competitor. We have asked theymos to open a dedicated sub-forum to Decentralized Applications (such as Mastercoin, Invictus, and more), and haven't gotten a response yet. 4. If we did open a new forum (I'm not completely against, but we need consensus for that), I would love to do it on Discourse. In this case we'll probablly ask Aric Fedida, our Head of IT, to install it (we haven't formally announced his position, but we should ... I'll do it within a few days). 5. For now - I propose you start a new thread on bitcointalk to discuss this. You can accompany that thread with a poll. 6. I really appreciate the initiative - thanks! Sure thing. I love the idea and am willing to help where I have some time I can set aside. The forums post is here: https://bitcointalk.org/index.php?topic=341882.new#newAnother thing I'd suggest is a separate thread for spec-related discussion. I've posted several questions that I have yet to get a response to. I'd be happy to do the spec editing work, but would like a bit of discussion before I do it and submit a pull request (otherwise it may be totally "out there"  ). ...the only risk here is that the spec thread (or any other MSC thread for that matter) does not get enough responses and gets buried behind all the other bitcointalk product development stuff. Also, one last thing: Do we have any devs that are on this effort full time? (It seems Tachikoma isn't, which I understand as this is quite a new effort and risky.) However, for instance I just hired another developer for my company yesterday...real decent skillset and not very expensive. As the mastercoin project gets more steam, and we now have these libraries that take care of the bitcoin-level bit tweaking, it seems to me that most MSC development largely becomes more commoditized....i.e. if not now, at some point soon, the a smart properties site for example could be made more by a general web dev that has a good midlevel level understanding of mastercoin/bitcoin, and uses the interface libraries that exist. You guys offer what amounts to a 100K bounty, plus 1000-some MSC, but did that do anything with moving anyone over full-time to work on the project? Maybe it's just a matter of time...I need to remind myself this project is only a bit over 2 1/2 months old! |
|
|
|
Hey guys, ripper234 asked me to post this topic. Wanted to get everyone's opinion on Mastercoin getting its own forums. My view is that it would be good for better coordination among the Mastercoin group, without flooding the Project Development forum (which may be the case if we undertake a community PR movement to the awesome extent that Peercoin, for example, has, where they have a separate activist section even, with plenty of traffic - http://peercointalk.org/). However, I can understand the view of some that, while that makes sense, it's a bit premature at this point. Based off of what folks think, we can make the best decision for both the Mastercoin and Bitcoin communities. Thanks! |
|
|
|
Guys, has there been any thought to setting up a dedicated forum for Mastercoins? I'd be happy to set up and host a forum site if desired, powered around SMF or any other forum software. I have about 15 years experience administering Linux systems and development and run a company that develops custom software products for large enterprises. It would run on a Linode VPS, and forum.mastercoin.org could be made to point at the host (or mastercointalk.org, but I'm not sure who owns that domain -- mastercointalk.com is available). I ask because I think it would really help the Mastercoin community evolve. For an example, Peercoin is another project that I follow. JustABitOfTime has done an amazing job so far in such a short period of time mobilizing community-driven PR. Just this past week, they have Peercoin being mentioned in CNBC, Forbes and the WSJ ( https://bitcointalk.org/index.php?topic=341509.0). If you look at the peercoin forums ( http://peercointalk.org/), they have an entire group setup for Peercoin activism, across multiple media channels. I think a configuration like this is much more accessible to the community at large than a few Mastercoin threads on bitcointalk, or a Trello PM board. Several of the folks around Mastercoin make a big point around benevolently "stealing" any features that Mastercoin competitors gain that could be useful. I think we should do the same when it comes to where ever another effort (whether it be another CC, or MSC competitor) is doing really well. And Peercoin is really kicking some ass with community organization and PR. Any feedback? |
|
|
|
"International conspiracy to knock down USD."?
yeah... funneeeh
the Fed is having no trouble doing this on their own.  |
|
|
|
Do they not believe that the next legitimate alt currency will be its successor? Seems ignorant. Thoughts?
You are assuming most people think for themselves, rather than simply follow popular opinion (which is most often set by those who have a vested interest in the status quo -- i.e. NOT bitcoin or any other decentralized cryptocurrency). |
|
|
|
A few more points: * To Ron's question, I believe smart properties and everything else are assigned an ID from a single 4 byte namespace, right? That means a bit over 4.29 billion possible for everything, or does each entity type (e.g. smart properties, buy/sell items, etc) have their own namespace (maybe I missed this in the spec)?? 32-bits sounds like a lot, but that may go quicker than you think, kind of like 640KB of RAM. * Regarding currency ID creation, if we have multiple smart properties created within the timespace of the same block, the spec needs to be clarified to deal with this, I think. As transactions within a block have no natural order, how should we deal with that? * Do Smart Properties have anything to do with this item buying/selling? If not, wouldn't it make more sense to create a Smart Property, then have the ability to sell, bid on, or buy that smart property, instead of having two separate classes of A) smart properties, and B) items that are offered for sale out of no where? That, or keep the latter, but add the ability for buy/sell to smart properties as well. In any case, it's a bit muddy in the spec. * Here's an interesting one: Looking at the spec, I'm thinking that the current way of having a 21-byte description for a smart property, or a category/item name for an item is limited to the point of not being useful. Say for example, you want to store a house deed as a smart property. How would you do that? Put the physical home address in the 21-byte field? What if the full address was > 21 bytes? What if I had a house transferred via Mastercoin, and then some disputes came up around the land rights, or land dimensions? A simple physical address won't help me (maybe I'm totally missing the point). In any case, two options here to make this more useful, for both smart properties, and buy/sell items (as they currently exist): -OPTION 1: Store a bit torrent hash code (e.g. "magnet link" - see http://news.softpedia.com/news/BitTorrent-Magnet-Links-Explained-132536.shtml) in the message. That will then allow us to essentially store and distribute the data for these secured assets via bittorrent...which takes care of P2P, data validity, etc issues, and offers some level of anonymity. A future smartproperty client could take care of initially seeding the torrent, and then taking that magnet hash code and putting it into the MSC transaction. This gets me excited just thinking about it.... so I could create a torrent for my 21-page house deed PDF, and then the bittorrent hash goes into the Mastercoin transaction. Cool!!  (We could even think of ways of compensating folks that maintain seed nodes for these transactions from MSC transaction fees, in the future.) -OPTION 2: Operate a side-chain optimized around storing these kinds of assets. This side chain would probably not generate its own useful currency. Instead, instead of the fees being destroyed, they could be used to compensate the miners of this sidechain for securing it (and storing the data in it). E.g. the miner that solves block #4930 in the side chain gets any fee rewards from MSC transactions in bitcoin block #49202929. |
|
|
|
Well, then if Mastercoin is VERY successful, we'll end up with our very own version of OneCoin ( https://bitcointalk.org/index.php?topic=200177.0). Can't wait for the Smart Properties conversation to really get off the ground, so I can follow it and contribute feedback. It looks like you guys got a very qualified individual to run with it...really excited. I can see several areas around it where the spec needs to be expanded/improved, and would be happy to be a part of that conversation. Please feel free to submit pull requests where you believe the spec can be improved - that's why it is in github Thanks! I will. I'll be travelling shortly, but should hopefully have some time this weekend. Plan is to add a section on Fees that covers such things as why collect fees, and how fees are paid (i.e. by the client recognizing it as a balance deduction of the current fee amount when it parses through that transaction, I'm thinking), and then for each feature where a fee is appropriate, add a sentence in that respective section that notes the fixed fee. I will propose fixed fees, that can change if necessary in a future version of the spec. Two other options here are: * Variable rate fees, depending on some kind of algorithm that looks back X blocks - too complicated at this point * Doing fixed fees, but implementing a "voting" style algorithm, similar to what has been done in a few altcoins (I believe FreeTrade had one), where a vote solicitation message can be sent out with a time limit, and vote messages cast from MSC-containing addresses. Just something to keep in mind. |
|
|
|
I'm confused.
What could WU do with Bitcoin that they couldn't already do with fiat?
Wouldn't they have a huge float in an account in each currency and just arbitrage between the accounts to keep them level?
Why would it be necessary to go Fiat *Location 1* > BTC *Tranferring* > Fiat *Location 2* when they can just go Fiat > Fiat
Western Union should look at bitcoin at an oppurtunity instead of a threat. Western Union + Bitcoin would be the perfect marriage. They got dealers around the world that can thandle cash and financial muscles and would become the no 1 place for people to convert between fiat and bitcoin in person. Exactly. Their dealer network means maintaining the same experience for their customers, while if they utilize BTC as an intermediate step for the transfers, they may be able to reduce the regulatory headache/overhead/cost by a good amount. |
|
|
|
There's a voting feature in the works which will use proof-of-stake. I have outlined how it might work, but I'm actually going to redesign it to be a more generic distributed bounty system (basically what the Mastercoin Foundation does, but using distributed proof-of-stake voting to disburse project funds). I have some ideas on that which I need to flesh out more. Mastercoin has a fixed supply, and I'll gladly destroy them as an anti-spam feature. You'll notice that distributed e-commerce destroys MSC to avoid gaming the feedback system. I think it makes sense to destroy MSC to avoid spam feedback, and spam property creation, and spam anything else. Deflationary = Good Investment = Bigger Mastercoin Community = Faster progress = Even better investment Well, then if Mastercoin is VERY successful, we'll end up with our very own version of OneCoin ( https://bitcointalk.org/index.php?topic=200177.0). Can't wait for the Smart Properties conversation to really get off the ground, so I can follow it and contribute feedback. It looks like you guys got a very qualified individual to run with it...really excited. I can see several areas around it where the spec needs to be expanded/improved, and would be happy to be a part of that conversation. |
|
|
|
I have a few questions related to smart properties:
From the spec, it looks like the unique factor used to differentiate one property from another is the Property Name, in which one may put up to 21 characters, correct?
Question 1: What’s to stop people from spamming new smart properties? This could be like the domain name system, without any pricing required to reserve a name. Someone could reserve a smart property like “dog”, or “House Deed”, in perpetuity. Is any MSC required to be consumed to create a property, or is it just the BTC transaction costs to send the transaction?
If we are just limited to 21 bytes for property names in this kind of wild-west scenario, without any kind of payment requirement beyond the minimal BTC fees to keep away spam, I can see all of the intelligible choices for this filling up quickly. People would then be forced to use names like “HouseDeed_348dF” or even some kind of odd hash value. This may not necessarily be a ‘bad’ thing…worse case we could see Mastercoin property names devolving to the level of implicit legibility as Bitcoin addresses (i.e. a long string of numbers and letters).
If MSC is required (or you are considering this), you could have two options here: pay to the Exodus address (further enriching that, although I don’t know how necessary that is), or destroy the funds, similar to Peercoin transactions.
If destroying the MSC, to offset the deflation this causes, a future proof-of-stake type system could be even initiated that would inflate the supply at a low level (e.g. fixed 1%, or a variable rate derived periodically based on the MSC value destroyed over the past X period of time) to offset and attempt constant, or very slowly growing supply. I think that this idea is probably heretical and overly complex, since MSCs were created as a fixed supply (sounds kind of like a central bank, coded into the software, hah!)…just thought I’d throw it out there if in the future we find ourselves needing to allow for some controlling feedback to be applied to several aspects of the system (smart properties, bidding, etc) by allowing Mastercoin to require at least a small amount of MSC for most actions, in a way that didn’t unfairly enrich one specific party, or disrupt the balance of wealth in the system. Whether it would cripple the usefulness of Mastercoin in the process is up in the air though. If the fee was low enough, it shouldn’t.
Question 2: I see where dividends can be paid against smart properties. Can Smart properties be transferred? (I do see “Listing something for Sale” and “Initiating a Purchase”, but I’m a bit confused whether these have anything to do with a smart property, as their identifier is a 11 byte category and a 16 byte subcategory. If not currently, why not? Perhaps that’s an area of the spec that needs to be added.
If these were covered somewhere else, forgive me. Thanks for any answers.
1) Adding some sort of cost to reduce spam is a great idea. Thanks for bringing that up. 2) Yes, each new property gets its own currency id, so anything you can do with a currency can be done with a property (buy, sell, transfer, bet, etc) Regarding 1), this is a tricky problem, which I have thought about some already. There are several ways to add cost. I prefer a sliding fee scale which targets creating X properties per day. If more than the target are being created, the fee goes up, otherwise the fee goes down. I think the fee should destroy MSC, not send them to the Exodus Address. I'd be interested in hearing other opinions about this. I'd be really happy to see a pull request about this once we've got some consensus. I haven't added anything like this to the spec because everything I came up with seemed a bit too complicated. For instance, the number of properties created per day might need to go up once MasterCoin is getting widespread use, and it's hard to make the right formula for adjusting that automatically. Having a fee is about much more than just reducing system abuse. If done right, it can also be about encouraging the growth of MSC, by requiring people to trade and vest into MSC before using the features of the systems. Doing this I believe will have a huge impact on enlisting long term support of Mastercoin, because it makes anyone that wants to use Mastercoin features have to be vested into the system to some extent, even if it's only a bit, in order to consume finite platform resources (e.g. smart property namespace and currency IDs in this case). It's also an area where I wonder how Mastercoin clones (such as Mastercoin2, where no Exodus-style funding and no inherent coin worth) will handle. To deter namespace spamming, requiring something beyond the minimal BTC transaction value to be spent on a valuable service with finite addressing resources makes logical and economic sense, to me at least, and keeps the system un-bloated and useful. And it is also something to consider from a systems perspective...i.e. if Tachikoma or someone needs to implement a smart properties feature to the site, parsing out and caching each smart property for quick look-up takes time and memory space. So that all being said, I agree with you on some kind of fee (which I think should be reasonable, able to adjust/change possibly, and made with the foremost intention of reducing spam while preserving usability and desirability of the feature-set). Also agree that it should not go to the Exodus address. It should be done in a way that doesn't bias one participant over another. However, the problem if we did that alone, is that Mastercoin would become a deflationary currency, possibly even more than bitcoin is (where supply slowly reduces due to constant max and people losing wallets, etc, but transaction fees do not destroy BTC). Not inherently a deal killer, but it would reduce the supply over time. Not entirely sure about what the exact consequences of this are, as the annualized deflation rate could become significant, depending on the exact fee structure and service use volume. So if MSC destruction on feature use is desired, I would put forward us considering some kind of proof-of-stake type system, similar to Peercoin's coin-age redeeming system, with a fixed inflation rate, or a variable one that takes MSCs destroyed by service use into account. With Peercoin, coin-age is consumed, so that stake awards can be rewarded in a fair and decentralized way. Given the fact that PPC network is the base network and produces POS blocks itself (instead of laying on top of a POW network like bitcoin), any MSC POS feature may end up having to be implemented totally differently. I am not technically experienced enough on the workings of PPC POS to make an intelligent comment beyond this. Another factor to consider is compatibility of future Mastercoin ports to other blockchains, such as Peercoin and Litecoin. I'd be very interested in hearing other opinions on this. It may even be a good idea to enlist Sunny King into the conversation at some point for this point of view (and if people DO want to go with this, we could even pay him to implement it for us). |
|
|
|
|
Show Posts
