 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
HELLO WHAT IS HAPPENING WITH THIS PROJECT???
I got through two phases of the project's original plan (the MVP demo with stars and the system generator with planets), and deployed the "Macroverse Explorer" https://macroverse.io/#explore for looking at them, and an ERC721-compatible version of the virtual real estate system for staking claims on them. I announced the release on Twitter and to the project mailing list. As far as I can tell, nobody ever used it. The gas prices on Ethereum went up to the point where they priced out a lot of the gaming use cases I was designing for. I believe all the claims ever staked in the virtual real estate system were done by me personally, and that nobody else has ever written or deployed a contract referencing the Macroverse world generator contracts. Running the whole thing through a bespoke token, so you need to somehow get ahold of the token to use the system at all, has IMHO proven to be a not-particularly-successful approach. I prototyped some ways to implement terrain generation for the third planned phase of development, but I was having trouble coming up with a way to do it that would get good-looking results and be cheap enough to ever plausibly actually use in on-chain logic. The loops I needed for smooth terrain with classic iterated-displacement techniques like Perlin noise were just too expensive, and I was not having much luck getting around the looping with tile-based techniques. So, not having any evidence of users or developers working with what I'd written so far, I paused work on the project, since it didn't seem like any users would suddenly materialize if I finished and shipped that final planned phase, and I didn't want to write software for and waste chain space on something nobody wanted to use. If you actually do for some reason need or want the on-chain terrain and climate feature checkboxes for an actual on-chain project, please get in touch. But I'd advise against it; they'll always take a lot of gas, and the gas prices are still expensive enough that that won't be fun. And how or why would any user actually get the 100 MRV tokens to meet the minimum balance requirement to use the system? |
|
|
|
the idea is to be used in another games? or the macroverse will have a "base" game?
Yes, the idea is to be a shared world that can be used in other games. Especially for games that just need some outdoor terrain, it could be easier to find a place of the right shape to set your game in than to hire environment artists to design terrain and then spend the money to store it all on-chain for verifiability. Of course, I'm already thinking of cool game ideas to build on top of it, so if nobody else bites, at least I'll have something to work with. |
|
|
|
Cool concept, but without a working prototype I'm not buying any. Too much like No Man's Sky, and we know how that went  What kind of prototype are you looking for? There is this prototype deployed on the Ethereum chain right now, and it works. Here's a listing of the stars in the (0,0,0) sector, from the test suite: Stars in origin sector: 39
Star 0 at 0.1613819681097084,18.118419187521795,12.41629295113853 ly is a MainSequence TypeM of 0.13280483893322526 solar masses with planets
Star 1 at 8.352765291169817,21.521832496023308,14.70794403992386 ly is a WhiteDwarf NotApplicable of 0.7937905001253966 solar masses
Star 2 at 23.628362261683833,9.4487003893164,12.631785201278944 ly is a MainSequence TypeF of 1.2172339029093564 solar masses
Star 3 at 17.68796647581894,10.921977819566564,6.6272957395312915 ly is a MainSequence TypeM of 0.09394641004018922 solar masses with planets
Star 4 at 16.616928126040875,16.187588339312242,7.377445674637784 ly is a MainSequence TypeG of 0.9865067396913219 solar masses with planets
Star 5 at 15.74362464036767,6.600803068454297,5.968998394905611 ly is a MainSequence TypeM of 0.26636417300778703 solar masses with planets
Star 6 at 20.268543146312368,14.805240031569156,1.4016471760442073 ly is a MainSequence TypeM of 0.21663218672347284 solar masses with planets
Star 7 at 14.131425873461012,0.8248838812733084,3.87367203904887 ly is a MainSequence TypeM of 0.18189346254075645 solar masses with planets
Star 8 at 4.610691752213825,0.0428331247803726,2.050549116984257 ly is a MainSequence TypeM of 0.181107219693331 solar masses with planets
Star 9 at 21.586779849758386,11.544582400892978,6.165219546960543 ly is a MainSequence TypeM of 0.28534585097804666 solar masses with planets
Star 10 at 13.852605343299729,10.204806822025603,15.587450106386314 ly is a Giant TypeK of 48.90808705718882 solar masses
Star 11 at 13.788190521222532,11.125623866701062,13.996714425388745 ly is a MainSequence TypeM of 0.10444396197726746 solar masses
Star 12 at 21.489885124219654,24.826315800282828,20.456860429499102 ly is a MainSequence TypeM of 0.1178465775492441 solar masses with planets
Star 13 at 4.173886921512349,15.812307129067449,3.7542753055731737 ly is a MainSequence TypeK of 0.7818698770197443 solar masses with planets
Star 14 at 13.27533083747312,16.966044178025186,20.48390676800409 ly is a MainSequence TypeM of 0.2437850927153704 solar masses
Star 15 at 8.736244370561508,1.0378403535241887,9.831296771335474 ly is a MainSequence TypeG of 1.0004645705039366 solar masses with planets
Star 16 at 16.115172616264317,10.567678005190828,10.027809768303086 ly is a MainSequence TypeM of 0.18262802364279196 solar masses with planets
Star 17 at 11.294209219568074,4.3196126885050035,21.229172114317407 ly is a MainSequence TypeM of 0.40833418943748256 solar masses with planets
Star 18 at 5.21207560827861,11.492471201813714,10.38719548073459 ly is a MainSequence TypeM of 0.2684721985224314 solar masses with planets
Star 19 at 18.553889885993158,0.45091477743426367,20.74156241453693 ly is a MainSequence TypeM of 0.4140062171327372 solar masses with planets
Star 20 at 20.23379753577501,17.341250630147442,23.527256473835223 ly is a MainSequence TypeM of 0.26013500826411473 solar masses with planets
Star 21 at 12.66052347978075,8.060563405160792,9.884962858495783 ly is a MainSequence TypeM of 0.2598429443214627 solar masses with planets
Star 22 at 17.307068168952355,20.73634026628497,2.954285925170552 ly is a MainSequence TypeM of 0.27194352844162495 solar masses
Star 23 at 6.862001460854117,20.34844719587454,17.04913473281522 ly is a MainSequence TypeM of 0.33822736503407214 solar masses with planets
Star 24 at 23.699176378659104,14.75463548067637,16.861710910188776 ly is a MainSequence TypeM of 0.21391858288279764 solar masses with planets
Star 25 at 11.07977198385015,4.693625674917712,12.777176997678907 ly is a MainSequence TypeM of 0.4201501412098878 solar masses with planets
Star 26 at 7.363040540849397,10.01761340748999,23.565806943042844 ly is a MainSequence TypeM of 0.3293303501450282 solar masses with planets
Star 27 at 12.371446089809979,8.087426029533162,4.251143996225437 ly is a MainSequence TypeM of 0.11277296043499518 solar masses with planets
Star 28 at 3.1524554843599617,24.93803733898403,10.563421923507121 ly is a MainSequence TypeM of 0.09525545870928909 solar masses with planets
Star 29 at 18.922999667984186,4.089151687594494,21.297638903865845 ly is a MainSequence TypeM of 0.4318041607057239 solar masses with planets
Star 30 at 5.617614002699156,9.960647307684667,22.83705705324337 ly is a MainSequence TypeM of 0.3462359881841621 solar masses
Star 31 at 8.866873133320041,21.352436725965163,9.70895904245026 ly is a MainSequence TypeK of 0.4651559596059087 solar masses with planets
Star 32 at 17.616013039014433,22.401921771574962,24.705373676601994 ly is a MainSequence TypeM of 0.10785482486699038 solar masses with planets
Star 33 at 23.072090780783583,8.107381122158586,0.6762747884749842 ly is a MainSequence TypeM of 0.34945126173624885 solar masses with planets
Star 34 at 16.74501128911743,20.138443240966808,16.374172900964368 ly is a MainSequence TypeM of 0.25525278968689236 solar masses with planets
Star 35 at 12.373427700413231,1.8376803255023333,18.080980920171896 ly is a MainSequence TypeM of 0.44613618154562573 solar masses with planets
Star 36 at 22.86719418109442,18.51714929296122,11.419720619846885 ly is a MainSequence TypeM of 0.4148228889407619 solar masses
Star 37 at 11.30238699226993,12.042864324212132,8.762299942554819 ly is a MainSequence TypeM of 0.20170117294674128 solar masses
Star 38 at 19.951106185339995,14.261220537559893,10.751655614421907 ly is a MainSequence TypeM of 0.3570075996558444 solar masses with planets
There's a nice G-type star (number 4) that might eventually have some habitable planets, and a relatively rare giant K-type star, and a white dwarf. There's all sorts of gameplay possibilities there; even something as simple as a Noctis clone, where you fly around refueling at white dwarfs, would be pretty fun. Reading console dumps is not a particularly slick way to explore the universe, so I'm planning to develop a nice front end to let people explore the generated world in a web3-enabled browser, to hopefully be completed before the crowdsale is over. Is that the sort of prototype you're looking for? |
|
|
|
Well, I think people should know more details and prospect about your project. And are you planning to run the crowdsale without any bounty campaign?
Yeah, there are no plans for a bounty campaign, to pay people in tokens to post on social media. I know they're very popular, and presumably they're effective or people wouldn't do them, but they frankly offend my sensibilities. A bunch of people being paid to tweet about something is to me a good indication that I shouldn't spend my money on that thing. |
|
|
|
Hello, everyone, I wanted to announce here a project I have been working on, combining procedural world generation and blockchain-based smart contract technology. MacroverseMacroverse is a procedurally generated universe, available to be used by blockchain-based games. Rather than paying expensive gas costs to store environment and level data on the blockchain, or spending large amounts of developer effort on custom world generation algorithms, game developers will be able to use Macroverse as a piece of game development middleware, and to find settings for their games by exploring the single, shared Macroverse universe. The Macroverse world is generated by the Macroverse Generator (MG), a system of smart contracts. The Macroverse Star Generator, which produces a galaxy of over 200 billion stars of various classes, is deployed at address 0x56D96b6a5F33E2efE5BE66065D5b9C230B1f4e0e using this source code. Addresses with a balance of (currently) 100 MRV or more may query the generator's various constant functions and receive information about the Macroverse world. Virtual Real EstatePlayers exploring the Macroverse world will be able to discover, claim, and trade virtual real estate. If you find a particularly compelling star, planet, or geographical feature, you will be able to purchase it and make it yours. Ownership of real estate may confer beneficial effects or advantages in supported games. Virtual real estate claims are manged by the Macroverse Registry, a system of smart contracts. Currently, the only contract is the Macroverse Star Registry, at address 0x6C00556F471cbe518007D62bc4ACEd6d8e537c9D using this source code, which allows players to claim (transferable, releasable) ownership of star systems, by putting up a deposit of (currently) 1000 MRV. MRV TokenThe Macroverse token, MRV, is an ERC20-compatible token on the Ethereum blockchain. Players must hold a minimum balance in the MRV token to query the Macroverse system, and deposits denominated in MRV must be put up in order to claim virtual real estate. The MRV token will be distributed in a crowdsale beginning July 1st at approximately 10 AM PST. Token FactsName: Macroverse Token Symbol: MRV Decimals: 18 Token Contract: 0xAB6CF87a50F17d7F5E1FEaf81B6fE9FfBe8EBF84Total Supply: Up to 100,005,000 MRV Available for Sale: 100,000,000 MRV Crowdsale Price: 5,000 MRV per ETH Crowdsale Start Scheduled: 10:02 AM PST on July 1 Crowdsale Duration: 90 days Crowdsale Contract (same as token contract): 0xAB6CF87a50F17d7F5E1FEaf81B6fE9FfBe8EBF84Crowdsale/Token Contract Source: HereMore details are available here.The MRV token is intended to function like a software license, enabling people to use the Macroverse system. It is not indented to represent a stake in the Macroverse project, and is not designed to increase in value over time. In addition to trying to sell tokens, I'm posting here to gauge developer interest in building atop a platform like this, and to gather suggestions as to what features would be good to have when extending the system from just generating stars down to generating planets, terrain, weather, and other world features described in the whitepaper. Feedback is appreciated! Additional ResourcesCode on GithubOfficial Website including e-mail list signup WhitepaperTwitter: @MacroverseMRVE-mail: macroverse@protonmail.com |
|
|
|
|
I don't get how this is supposed to work.
It looks like someone with a minimum share of the hashing power can enforce a minimum fee, up to the point where the total fee paid by legitimate transactions willing to accept that minimum drops off. The miner enforcing the minimum fee can flood the network with transactions paying just below that fee, and get back a sufficient portion of their own transaction fees that the fees they pay in spam transactions mined by others are balanced by the fees they earn from legitimate transactions.
I fail to see how this results in that miner achieving a monopoly. The other miners will be enjoying the benefits of the higher minimum fee, and will collect some of the fees from spam transactions, without having to pay for any spam transactions of their own. So whatever profit the attacking miner is making, the other miners will be making more.
At best, this attack allows a sizable minority group of miners to engage in price fixing without running out of money, under the constraint that legitimate transactions are still wiling to pay enough to fill half the block.
|
|
|
|
|
So it turns out when we get to around 10k blocks, the coin system starts to slow down. I suspect it's because it has to copy the State (which includes a list of every unspent output) for every new block, and I'm going to try to change that when I get a chance. In the mean time, try not to need to download the blockchain for the toy coin.
|
|
|
|
|
Another new release!
It turns out the way I got the state of the blockchain in the past to verify fork blocks was a huge bottleneck, so I fixed it by adding some caching logic. I've also added some more queuing and deferring to prevent the client from locking up while verifying a batch of downloaded blocks.
Hence 0.4.
There's actually a reasonable 3,843-block blockchain going, on which I will pay 50 coins to anyone who posts their address and is running a client to receive them. Eventually.
|
|
|
|
|
You should mine PyBC Coin. We haven't written a GPU miner yet, so you are sure to get all the coins once you write it.
|
|
|
|
|
Hello all!
I've decided to make this the official thread. I had another thread for 0.2, but that seemed like it could get spammy pretty fast.
Anyway, I have a new version out, 0.3.1, which can actually handle the blockchain of 3,722 blocks that you guys have mined, and download it at a reasonable speed without deadlocking halfway through.
Be sure to use the script in the first post or something similar to upgrade your wallet file to the new corruption-resistant SQLite-based format.
I didn't bother with an upgrader script for stored blockchains; just re-download them from an old-version peer.
Also be aware that pybc_coinserver and pybc_cointk have two new arguments: a required argument for a persistent peer database, and an optional --host argument to enable announcement of an internet-visible host name or address to the network periodically.
Let me know if there are any issues.
|
|
|
|
|
I'm working on a coin that isn't derived from the Bitcoin code. What sort of backend software/API do you need to interface coins with your site?
|
|
|
|
I've released version 0.2 of the PyBC generic blockchain module on PyPI. This library has everything you need to write your own altcoin in Python. It comes with an example coin (1 minute block time, SHA512 hashing, 50 indivisible coins per block forever). That coin now comes with a GUI, so people can actually use it. To install PyBC for yourself: If you installed version 0.1 and want the new version 0.2: pip install --user --upgrade pybc The executables all go in ~/.local/bin. If you want the GUI, run: ~/.local/bin/pybc_cointk test.blocks test.keys --generate This will start up a node listening on port 8008, storing block data in test.blocks, and encryption keys in test.keys (think wallet.dat). It also sets it generating blocks. You can start up another node and tell it to talk to the first node: ~/.local/bin/pybc_cointk test2.blocks test2.keys --generate --peer_host localhost --peer_port 8008 --port 8009 This will start a second node with a different block store, a different set of keys, and a different listen port, and tell it to connect to the first node. They may fight over which blockchain is longer for a bit until they finally settle on one. Once you have this all running, you can use the GUIs to send coins between the two instances. There's no transaction listing yet, but you can see your balance change. Note that you won't see your balance update until the next block (and your client won't know which of its unspent outputs it has used until the next block, and will cheerily generate double-spend transactions that miners will reject). There's only UI for a single receiving address per node, and anonymizing transactions with new change addresses has not been implemented, but neither would be particularly difficult to add. The whole thing works on Windows if you install: - Python
- Visual C++ 2008 Runtime (an OpenSSL dependency)
- OpenSSL (a pyelliptic dependency)
- setuptools (a pip dependency)
- pip (to install pyelliptic, which is a pure Python module with no Windows installer)
- pyelliptic
- Twisted
All of the appropriate architecture and Python version. Thoughts and feature requests? |
|
|
|
New in 0.4: not locking up while downloading blocks, and much more efficient fork switching.
This new release is compatible with old blockchain data and peers, but not the stored wallet or blockchain files. To update to 0.4: pip install --upgrade --user pybc If you want to keep your private key(s) from 0.2 or earlier, you can (probably) use this script to import them: #!/usr/bin/env python2.7
"""
Script to import a Wallet to the 0.3+ format.
PyBC must be installed in a place where it can be imported.
The old wallet should be named keys.wallet.old.
The new wallet should be named keys.wallet.new.
"""
import shelve
from pybc.sqliteshelf import SQLiteShelf
old_wallet = shelve.open("keys.wallet.old")
new_wallet = SQLiteShelf("keys.wallet.new", table="wallet")
for key, value in old_wallet:
new_wallet[key] = value
old_wallet.close()
new_wallet.close()
I've been working on a Python module, PyBC, that implements a peer-to-peer distributed blockchain (as in Bitcoin or any altcoin) with easily definable rules for block validity. On top of this library, I have implemented a (very simple) altcoin: PyBC Coin. To my knowledge, this toy coin is the first altcoin not based on the Bitcoin source (if we don't count Ripple), and the only SHA-512-based altcoin. The library is available from a couple of places: PyPIBitBucketTo play around with PyBC Coin, assuming you have pip and .local/bin is in your PATH, run: pip install --user pybc
pybc_cointk blockchain.blocks keys.wallet seen.peers You can use the GUI to get a base64 receiving address and your current balance, and send and receive (indivisible) coins. If you want to generate blocks, use the --generate option. Specify another peer to connect to with the --peer_host and --peer_port options. The default port is 8008, and can be changed with the --port option. If you specify a host name or IP with the --host option, you will announce yourself to your peers. The toy currency is currently set to retarget every 10 blocks to a generation rate of a minute per block. The generation reward is 50 indivisible coins forever, and the transaction fee that all the miners charge by default is 1 coin. Naturally, this can all be changed around fairly easily. Hopefully this library will eventually be useful for the rapid development and prototyping of altcoins. Make your own currency, no compiling needed! It's also intended to be useful for non-currency blockchains. Does anyone have any design suggestions, or ideas on how to mitigate the fairly obvious opportunities for low-difficulty-block or transaction or peer flooding attacks that the library currently has? Would anyone be kind enough to run a publicly-accessible pybc_coinserver node for larger-scale testing? If so, please post here. The UI code needs substantial revisions, but what constitutes a valid block is unlikely to change in a backwards-incompatible way, so if you think my test currency is going to be the next Bictoin you can get a head start on mining. I'm very excited to see the first serious altcoin based on this library. Also, please send BitBucket pull requests; the whole thing is MIT licensed, and contributions are accepted under the same license.
|
|
|
|
|
I'm working on my own generic blockchain implementation, and I have a question about how Bitcoin ensures that everyone doesn't need to remember every fork that ever happened.
The longest chain always wins out, in the sense that that's the chain that the client looks at to see who has how many Bitcoins. But if I start getting blocks that fork off my current longest chain several blocks back, I need to keep those blocks around in case they end up forming a chain longer than the one I'm on. And there's no guarantee that I won't get half the blocks in this new longest chain today, and half tomorrow, so when I shut down my client, those blocks in the currently-shorter chain need to be saved to disk.
What stops those blocks from needing to be kept around indefinitely?
If the blocks do need to be kept around indefinitely in case their fork becomes the longest chain, what stops someone from solving a large number of blocks forking off some early, low-difficulty point in the chain, and taking up lots of disk space with all these forks?
|
|
|
|
|
I'm looking for a blockchain library: specify how to create transactions, how to collect transactions into blocks, and how to validate blocks, and get an instant working blockchain system to keep a distributed, proof-of-work-powered record of whatever you want. Something like BitcoinJ, but with the Bitcoin-specific parts abstracted out.
Obviously this would be really useful for making altcoins, so I figured this was the place to go hunting. Are any altcoins currently implemented on top of a generic library like this? Or are they all based on independent forks of the Satoshi client?
|
|
|
|
Holy Nmap Batman! $ nmap 63.141.253.124
Starting Nmap 6.00 ( http://nmap.org ) at 2013-04-19 17:58 PDT
Nmap scan report for 63.141.253.124
Host is up (0.11s latency).
Not shown: 973 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp filtered smtp
80/tcp open http
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
211/tcp filtered 914c-g
445/tcp filtered microsoft-ds
500/tcp filtered isakmp
513/tcp filtered login
666/tcp filtered doom
1100/tcp filtered mctp
1999/tcp filtered tcp-id-port
2000/tcp filtered cisco-sccp
2030/tcp filtered device2
3006/tcp filtered deslogind
3306/tcp open mysql
3814/tcp filtered neto-dcs
5000/tcp filtered upnp
6001/tcp filtered X11:1
7938/tcp filtered lgtomapper
8800/tcp filtered sunwebadmin
8888/tcp filtered sun-answerbook
9002/tcp filtered dynamid
9290/tcp filtered unknown
10215/tcp filtered unknown
40911/tcp filtered unknown
60020/tcp filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 18.23 seconds
|
|
|
|
|
I'm conducting market research for a Bitcoin-funded game project. If you were to buy a game, what platform would it be for?
|
|
|
|
|
Yeah, not a fan of that logo. But it's not my site.
|
|
|
|
Ripple is several things: - A distributed ledger that does not rely on proof of work. This is accomplished by having every Ripple client keep a list of ledger-signing "validators" that it trusts not to all be in on the same malicious scheme to defraud it. This lack of collusion is what the client relies on for trust instead. The wisdom of this is debatable, but the increased transaction speed isn't.
- A system for exchanging IOUs, on top of that ledger.
- A system for paying someone who does not trust your IOUs, by finding a path of people who trust each other's IOUs through which the value can flow. Hence the name "Ripple". If you don't like this, you can just pay people in IOUs from "Gateways", which are widely trusted people with automated systems allowing you to get or cash in IOUs. The biggest one is Bitstamp, which issues USD and BTC IOUs.
- A distributed currency exchange, that works by trading IOUs from different issuers or in different currencies against each other. This is so that you can pay someone with your USD even if they only want BTC.
- A virtual currency, called XRP, which is what Ripple transaction fees are denominated in. The Ripple creators originally gave themselves all the XRP, then handed out very large amounts of it (relative to the amount needed to pay for the operation of a Ripple address) to Bitcointalk users. It can be bought on Ripple's distributed exchange, but in order to do this you must already hold some XRP. As a spam protection measure, addresses that do not hold a certain "reserve" amount of XRP are unable to make transactions. The reasoning behind this is that some transactions, like deciding to trust someone's IOUs, need to have data persistently stored in the Ripple network, so maintaining this data has to be given a cost.
- The Ripple people themselves, who currently (as far as I know) are still the only ones running any Ripple validation nodes. They provide web-based wallet software at Ripple.com, which does all the cryptography client-side, but which relies on marginally-trusted full Ripple nodes to actually interact with the Ripple network. They also still have a huge amount of XRP left, which they plan to dispense over time in order to fund development.
|
|
|
|
|
