Agreed. I have faith that the markets will find an equilibrium, transaction processing has a cost which can be approximated for the network at any point in time, and a diff that sets it, diff can lower or raise to change the cost of securing the network, since it's all variable, human forces will work to strike a balance over the very long time they have to do so  I'm not sure how the difficulty figures into this. Difficulty doesn't set the tx fees, miners (at least in theory) do. It costs ~10%/yr to "keep the network secure" now. This level of security will continue to cost 10% of Bitcoin's market cap, regardless of Bitcoin price or mining difficulty. Tangent: It's hard to say the network is really secured when the majority of hashrate is controlled by a handful of people (megamines/pool operators). Difficulty determines the target hashrate to produce blocks at an average of 1 every 10 minutes. It sets the cost in hashes per second to keep the network running. If the difficulty goes up, the cost rises, if difficulty goes down, the cost lowers. No. ASIC manufacturers and electric companies set the cost of hashes per second. Not difficulty. What are you thinking? Devil is in the detail. Difficulty sets the cost (in hashes per second) to keep the network running at the optimal speed. The cost of those hashes, is a different thing. The total network cost (monetary) is average cost (money) per hash per second across all miners multiplied by the target number of hashes specified by the diff. The network cost to produce a block every ten minutes is controlled by the difficulty / target. |
|
|
|
Agreed. I have faith that the markets will find an equilibrium, transaction processing has a cost which can be approximated for the network at any point in time, and a diff that sets it, diff can lower or raise to change the cost of securing the network, since it's all variable, human forces will work to strike a balance over the very long time they have to do so I'm not sure how the difficulty figures into this. Difficulty doesn't set the tx fees, miners (at least in theory) do. It costs ~10%/yr to "keep the network secure" now. This level of security will continue to cost 10% of Bitcoin's market cap, regardless of Bitcoin price or mining difficulty. Tangent: It's hard to say the network is really secured when the majority of hashrate is controlled by a handful of people (megamines/pool operators). Difficulty determines the target hashrate to produce blocks at an average of 1 every 10 minutes. It sets the cost in hashes per second to keep the network running. If the difficulty goes up, the cost rises, if difficulty goes down, the cost lowers. For every given combination of market price tag and transaction volume, there is a corresponding desired hashrate (and therefore difficulty) which keeps the network costs at a rough equilibrium. If BTC goes up in price-tag, the hashrate and difficulty rise to find a new balance, conversely if price-tag lowers then hashrate and difficulty reduce to find a balance. The difficulty/target is perhaps the most important metric in many respects. |
|
|
|
Agreed. I have faith that the markets will find an equilibrium, transaction processing has a cost which can be approximated for the network at any point in time, and a diff that sets it, diff can lower or raise to change the cost of securing the network, since it's all variable, human forces will work to strike a balance over the very long time they have to do so |
|
|
|
Currently, Bitcoin's network security is costing over 10% of its market cap, yearly.
To maintain current level of security, 10% of Bitcoin's market cap would have to be spent yearly.*
When tx fees become miner's sole source of revenue, this will translate to tx fees being 10% of each transaction.
If we work on the 10% to secure basis: The average output volume per day is approaching 1,000,000 BTC per day, let's say 350 million per year. Fees would need to be 1.4 million BTC per year to cover the 10% of CAP. Which works out to 0.4% transaction fee by todays values. 5-10x cheaper than paypal and visa, based on transaction fees only. Obviously as usage increases (number of transactions and output volume per day) then that fee reduces accordingly. With 10x the transactions and half the average value, then we get a 5 fold increase in volume and a 5 times reduction in required fees, under 0.1%. * * This all depends on that 10% of CAP to secure number being correct. |
|
|
|
9%+25% = 34,000,000 MS, or 3.4% of total (1B) supply to get the oversight project off the ground and run it. If Bitcoin had 3.4% of total supply in the foundation, they'd have 714,000 BTC to fund projects with. Seems more than reasonable? I realise this is a radical proposal, but it's only a proposal, an alternative approach to discuss |
|
|
|
In short, every ASIC miner every created was simply to be a money printing machine...
False. Mining is the service which secures a block chain, proof of work is designed to be expensive, it's the monetary expense which keeps a chain secure. Eventually fees will cover mining costs, until then currency supply is emitted over time to subsidise mining and distribute supply broadly. ASICs are efficient transaction securing and processing machines, more efficient hardware is a good thing, the investment in mining hardware and the running costs are what keep the whole thing secure, and allow us to base an alternative monetary system on it. Without these improvements and investment, chains will be insecure, and the system would have limited usage due to being insecure. Those who treat mining as a service business and work to become more efficient are sensible, and those who secure our chains. Coins which are tailored to preclude ASICs and focus on CPU and GPU may be fun or seem to give the little guys a chance, but really what they preclude is having a secure future. Mining as a commercial service and commodity where it's possible to become more efficient over time adds longevity to a coin, and investment to an economy. Mining on a whim with repurposed hardware does not bode well in terms of longevity. If there's no real cost (investment/maintenance), and cost is that which secures a chain, we can conclude that costless chains will be insecure and have no real future. |
|
|
|
|
Only giving 0.9-0.09% of total supply to a project merging in which has potentially had years of work, vs 50%+ to stake holder of one still establishing project, doesn't feel too fair.
Suggestion 5: Give 10% of remaining MS supply to each project.
Project 1: ORA
Allocated 100,000,000 MS (apportioned 50% / 9% / 25% / remainder as described)
MS Pot: 900,000,000 MS
Project 2: ??
Allocated 90,000,000 MS
MS Pot: 810,000,000 MS
Project 3: ??
Allocated 81,000,000 MS
MS Pot: 729,000,000 MS
Rule 2: 10% as a cap, one project may be a single coin, another may be half of three communities joining, another may be four people working on an app for one dead coin. Apportioning the assigned ms should be easy as already discussed. Choosing what percentage up to 10 to apply to a project could be hard, perhaps just a social voting process?
Lot's to think about, I must bow out of the conversation for now, as much to do.
Small note, If you could issue 100m instead of 1b instead as a total supply, it may help in the long term, a single unit of currency should perceived as having value by itself, if you have 100m of them that's possible, if you have a billion you may always be stuck with it being fractions of a cent / a few satoshi. Consider the gift of 1 DOGE vs 1 NXT vs 1 LTC. Parity with other currencies is an important measure for community members, to go 1:1 with cent, nxt, 10 cents, dollar can give a substantial feeling of worth/merit.
|
|
|
|
How about other projects that maybe already have their own wallet?
How are going to ensure the burning process outside AE?
Burning outside the AE, a standard burn address, and process to monitor it / automate it, like dogecoin to dogeparty. As for projects which have their own wallet, we could say crypto coins fall in to 4 rough categories. 1) Crypto tech driven coins, things where the client features or specs drive the innovation. SuperNET already folds these in to aid their longevity. 2) Extending project driven coins, things where the client is a simple fork, and the extending projects + community drive the innovation. This would be the target for ORA the way I see it. 3) Projects which have both 1&2, these run on their own timeline and of which there are few. BTC being an example, VIA another. 4) Scams / abandoned / those which should arguably never existed. No concern. Swap 1-1
Myself and EsteNuno discussed this quickly yesterday. EsteNuno: setting the rate of exchange might be tricky Me: Agreed, my gut reaction on that is to ignore market price-tag all together. Let's say you have: 1) coin with 36 million mined at end of burn date 2) coin with 1 million fully mined PoS. Asset: 1,000,000 divisible to 8 decimal places 500k apportioned to each of the two coins each (1) is worth 500000/36000000 = 0.01388889 each (2) is worth 500000/1000000 = 0.5 Not all of the asset will be swapped, anything that isn't is just ignored. In this way both currencies have a fair portion of the asset, and are considered as having equal merit. Theoretically if say 60% of (1) and 50% of (2) is burned and swapped, then the asset should represent 55% of the x-month average cap of both currencies combined. But that figure is a price-tag, doesn't need known. The asset would be swapped for a portion of the MS currency, and it's supply would be inflated, and the market would adjust based on release of new coins, and new value brought to the overall starfish project. Since it's burned, no price-tag needs to be known. "what portion of MS currency" I guess would need to be decided ahead of time, by consensus of the starfish community EsteNuno: it's kind of like a supernet same sort of concept about joining forces but there are probably a lot of projects out there too that are never going to admit that it's not working out and see doing something like this as admitting failure(even though it's not that at all, and it's potentially much better) Me: +10 it's self cleaning in that manner, only those who really do want to join and create the services/projects and move crypto forward will join, the others won't. That's as far as I've personally taken discussions, will be watching, and of course best of luck in whatever you decide. |
|
|
|
High inflation and miners selling causes speculators to sell causes miners to sell faster and everyone else to sell more - it's a negative feedback loop that is only accelarating itself.
There is a little more to it. The difficulty of a coin to mine sets the production cost, if the hashrate falls quickly due to a price drop, either: A: the diff does not change quickly (btc/btm/ltc) and blocks are created much slower, emission of coin supply is slowed, which dampens the effect on the markets, allowing a new equilibrium to be found, or allowing demand to catch back up with supply. The less liquid the market, the more dramatic the effect, you can see a coins supply slowing to 1/50th of what it should be, which whilst a nuisance to transaction processing, is a saviour to the price-tag and value of the economy on the whole. B: the diff changes quickly (perhaps KGW/DGW is used) and blocks are created "on time", emission of coin supply remains constant whilst production cost is lowered. Surplus supply is created, and production cost just keeps lowering to match the market price, driving the price in to the ground. Transactions are processed quickly, but the economy collapses under the weight of the ever increasing supply of ever cheaper to produce coins, to literally 0. More often than not, it is this factor which accelerates the death of an alt coin's price tag. Remember that a large number of alt coins were created as money printing machines, some to benefit miners with legacy hardware which was inefficient on large cap coins against asics, so the business decision was made to keep printing "free money" at whatever price as long as there was any demand (buy orders) at all, this is where fast diff change and kgw/dgw came in, it allows production cost to fall as market price does, rather than putting miners back in the position of mining at a (perceived) loss. In short, constant downwards pressure is not due to miners or traders (unless it's a scam coin), constant downwards pressure commonly is due to production cost constantly matching market price tag on down turns, rather than supply slowing / reducing when demand slows. If you'd like to see the economics of this in action - as LTC and BTC have not shown case A as yet - then take a look at the all time chart on BTM with a moving average line over it, demand decreased and production decreased accordingly, price-tag has plateaued whilst we work to lift demand again, rather than price plummeting to zero with surplus supply. |
|
|
|
Thanks smaragda, all good suggestions there! CfB and jl777 are obviously two key guys in the NXT ecosystem with a lot of knowledge and skill, and picking their brains on ideas that might help ORA would be fantastic, but honestly, I think we need to develop some momentum on our own now. Sure, there will be communication asking for advice, and there has been already with both CfB & jl777 previously, but we need to get ourselves together and make ORA an 'attractive' proposition for guys of that calibre to get involved. I'm confident we can do that, and your suggestions are very welcome! When I communicated with jl777 previously his advice was pretty much what I relayed in this thread, and it is basically the same advice I've had from coinsolidation from Bitmark, who I've had the benefit of communicating with also - "what will people use ORA for, what does it offer that makes it useful, what is its 'killer feature' that can make it survive in a crowded market?". I think there are many possible paths to follow and explore here, and I'm smart enough to know that I'm not smart enough to think of many of the best ideas, that's why I always try and encourage people to get involved, and why when I try and think of something on my own I need to get philosophical and meditate; to squeeze every last drop of 'horse power' out of my mental engine We know ORA will be an MS currency now, and if we can assemble a list of ideas (even idea fragments), then maybe the 'killer feature' will jump out at us. Some ideas I've got include things like: - in game currency for online games - community 'token' on a community website - add 'escrow' features to ORA to allow reversible transactions (essential for online commerce IMO) In a more general sense I'm trying to follow this thought pattern: 1- think of 'activities' and 'things' that the world needs more of 2- find ones that aren't properly monetised in the current financial framework of global fiat, credit cards, paypal etc 3- think of ways/systems that ORA, running on mobile devices via our custom ORA app as an MS currency can monetise the thing in 1- above, so the world/ people produce/have more of it When I 'meditate' on ORA that's what I've been doing lately, and IMO the 'killer feature' jl777 and coinsolidation referred too *might* be discovered by anyone. The other day for example, I was imagining the 'thing' the world needed more of *could* be more people eating organic veggies grown in urban backyards that currently sit idle as an agricultural food producing resource, so I tried to imagine if ORA becoming the 'go to' crypto for monetising urban gardens and home grown veggies market was possible. It met my condition for something that the world needs more of, but isn't currently been done at the 'maximum' level or amount because fiat probably doesn't handle monetising small scale backyard veggy gardens that well. Let me stress that I DON'T think this idea is THE 'killer feature' for ORA, but the process of thinking about the task of 'killer feature' hunting is on the right track (hopefully). It doesn't hurt, and it can be fun It's basic 'community currency' stuff that old hippies like me have been thinking about for years (match unmet needs with unused resources via a 'token' or community currency), but really hasn't been possible on a large scale logistically, up until the invention of crypto currencies & blockchains. Perhaps you already have your killer feature, the combination of a starfish community, thought leading, willingness to cooperate, and willingness to use technologies which others have created. You do not have a developer, I suggest that you do not need one. There are hundreds of active projects currently competing in similar spaces. The coin associated with each is what fragments the wider communities and force projects to die, and rare developers to duplicate efforts, some need to die gracefully so projects can consolidate. I feel it is a fair analysis, to say that commonly the projects and services built on top of coins are what now separate them from the pack. Personally I can see multiple projects that would benefit massively by being merged. Again, the underlying (often neglected) crypto coins are what prohibit this. The alt coin community has a need: Allow projects to merge together, with respective currencies gracefully made legacy. The post above this is discussing this already, swapping RSU to ORA. With this in mind here is a back of the envelope proposal for your discussion: Create a new MS currency, do not distribute it. Create an Asset for each project merge. Provide a burn address for each coin in the merge. Issue the asset against coins burned to each burner. Once the burn period is over, swap the asset for a portion of the created MS currency. In this way, coins can be made legacy, and ORA can become not a currency, but an umbrella project with a starfish community, where each arm is a project which has merged in existing projects. This approach allows all those who want to move and merge to do so, whilst allowing those who don't to keep the coin they have and try to continue it without the broader community. It's opt in, optional. New projects could also be created in the same way, where an asset is created, released in the usual way to investors, and then the asset swapped for a portion of the MS currency. Existing assets which represent projects, for example omnigames, could also be swapped for a portion of the MS currency. Assets representing investment portfolio's are likely out of scope? From a financial aspect, every new project joining would inflate the supply, but bring an increase in value which should offset or exceed the inflation caused by the new portion currency issued. From an emission perspective, it's close to perfect, new currency is only issued when there is a demand for it, when new projects are added. The hard work required is doing the maths to ensure everything is fair around the new MS being issued. It is possible, and I would be happy to help if needed. Perhaps this will be contentious, but if you did this, I would propose that ORA (and indirectly RSU) become the first project, and receive the first portion of the new MS currency. Community organization, outreach, oversight, admin - all of that is a big enough project by itself to warrant being one arm, or perhaps the body, of this starfish. Finally, this is an observation framed as a proposal, I see you doing this already in some capactity, and you have effectively already proposed this to others, including myself, for other projects. Edit: the obvious part, each of the projects would utilize the MS currency within it, increasing the odds of one or more of them becoming "killer" within it's domain. Warmest Regards, Mark |
|
|
|
Maybe GMC and HYPER can cooperate in the future like meowball suggested? There are multiple projects working in cross-over spaces, it's definitely time for teams and communities to start joining forces where they can to be both more productive, and more useful to end users. The end goals are normally the same. Competition is good, collaboration is also powerful and to be promoted. Checkout Omnigames, it's in the same space and there is substantial crossover between all three projects, they could unify and knowledge+skill share with a broader community to advance all three quickly. Nice to see rational positive discussion. |
|
|
|
A little late to the project myself I see..oh well, time for new beginnings!
Welcome Ryse, if you would like an invitation to slack, where the community is most active, please pm myself or estenuno. |
|
|
|
|
A few problems with blockchain sticking when syncing, has the code been patched to handle reorgs? does it need done?
|
|
|
|
Bitmark 0.9.3 ReleasedThis version of Bitmark Core aligns with Bitcoin 0.9.3, including post release updates. It also includes Bitmark specific changes most notably the private key format has changed, a converter can be found at http://bitmark.co/brain to swap between old and new keys. Existing wallets, and backups will continue to work as expected, only exported keys / cold storage keys need to be converted before importing them to v0.9.3. Release and downloads for Windows, Linux, and Mac: https://github.com/project-bitmark/bitmark/releases/tag/v0.9.3Changes: - Private key version change to 213 to align with common third party tools.
- Seed Nodes and Checkpoints updated.
- Make -proxy set all network types, avoiding a connect leak.
- Refactor Alert to use static methods.
- Avoid a segfault on getblock if it can’t read a block from disk
- Add paranoid return value checks in base58
- Don’t poll showmyip.com, it doesn’t exist anymore
- Add a way to limit deserialized string lengths and use it
- Increase IsStandard() scriptSig length
- Avoid querying DNS seeds, if we have open connections
- Remove a useless millisleep in socket handler
- Stricter memory limits on CNode
- Better orphan transaction handling
- Add -maxorphantx= and -maxorphanblocks= options for control over the maximum orphan transactions and blocks
- Check redeemScript size does not exceed 520 byte limit
- Ignore (and warn about) too-long redeemScripts while loading wallet
- fix ‘opens in testnet mode when presented with a BIP-72 link with no fallback’
- AvailableCoins: acquire cs_main mutex
- Fix unicode character display on MacOSX
- key.cpp: fail with a friendlier message on missing ssl EC support
- Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitmark Core)
- Upgrade miniupnpc to 1.9.20140701
- Fix boost detection in build system on some platforms
Pfennig 0.9.3Pfennig has also been updated to align with both Bitcoin v0.9.3 and Bitmark v0.9.3. Source can be found at https://github.com/project-bitmark/pfennigMoreBitcore, Insight-api, and Insight have all been updated recently. A pull request with BTM support has been submitted to brainwallet.org. http://bitmark.co/brain/ has been updated to produce both v0.9.3 and previous version private keys.
|
|
|
|
Matched this donation. With the greatest respect, I don't think you need this at all. You have a fair distribution, no IPO/ICO, and have proved yourselves with work for almost a year already. Why verify what is plain to see and that which you have already earned? Keep up the good work. |
|
|
|
Noticed you've been plugging away at the project for a long time, great work and admirably consistent! I hope you do not mind, but I took the liberty of updating the checkpoints and seed nodes for you. There's a pull request ready to merge in here https://github.com/gamers-coin/gamers-coinv3/pull/1Keep up the good work, Mark |
|
|
|
How do I use the brain wallet generator ( http://bitmark.co/brain/) to make an encrypted paper wallet? Is it possible? Is there a paper wallet generator for BTM? This generator creates private/public keypairs for the Bitmark network, it does not as yet provide BIP-38 encrypted paper wallets. I'll add a task to create one to our queue, community development of such items is also welcomed. In the mean time we do have inuit which works as an encrypted cold storage solution. |
|
|
|
|
Due to unforeseen circumstances, we had to shift focus to resolve some real world issues for a members of our community over the past few days. As such delivery of the multi-user wallet api is now postponed until Friday, and the Marking layer over the weekend. The music curation service is an externally developed project and is still scheduled for the 15th December. Additionally, we hope to have UI designs from them for release early next week.
Thank you for your continued support, and special thanks to those in the community and on the ground who helped us address the situation, it's an honour to work with such exceptional people.
|
|
|
|
|
I offered to fix the OctoCoin and get it working. The offer was rejected as somebody else is already working on it, the community seems a bit divided as to what's happening.
As I understand it, lifeforcepools has taken charge of Octo on behalf of the community, and Edric is working on a fix or new version of the coin.
Good luck.
|
|
|
|
|
Show Posts
