Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - toast

Pages: 1 ... 8 9 10 11 12 13 14 [15] 16 17 18 19
211
DAC PLAY / BTS GameHost
« on: March 22, 2014, 07:05:32 pm »
This is just copy/pasted from my notes, so I apologize if it's hard to read. Some background reading is here: https://bitsharestalk.org/index.php?topic=2690.0


** perfect information games: the best kind

You can construct a payoff matrix in a way where players will tend agree to admit losses and when they don't the network makes a profit. Massively reduce storage costs.

** perfect information with an RNG: same thing, you need a "trusted seed" which is  just H(block||players||timestamp)

** trusted non-collusive hosts, no mucking
The host can reveal what cards other players have but cannot influence the probability of cards you get (infinite deck poker)

4) ** incentivized non-collusive hosts -> "normal" poker possible

hidden RNG state between player actions, host can share information. Might be possible to user clever zero-knowledge proofs to show a host did a fairly generated deck without revealing players' mucked cards. Or mucker could have a chance to rat the host out and players get paid out from hosts' collateral



So the idea is, BTS Lotto takes the most basic "game service" - an RNG - and builds the most basic game you can out of it. Games that we *know* are fun and profitable should follow this model. This will be a "catch-all" DAC that will provide the basic information services you need to host games. So people could figure out a chess engine using this DAC, then spawn a dedicated chess DAC which can embed crazy stuff like ELO and paid tournaments and stuff.


* Brand New Game Types*
If you think about the more general game players are playing when they are connected to a random host (do I trust this host not to cheat, or maybe this host actually deliberately made public), it spurs some thinking about what sort of games could be designed.


I'm actually excited about this because inventing new games is basically incentive structure research and could spawn new DAC ideas.

212
KeyID / Pre-allocate share as "Dev DNS"?
« on: March 22, 2014, 01:53:58 am »
Stan recommended I consider saving money for long-term development. Should there be 1% or 5% or 10% set aside in the genesis block in escrow for development? So an allocation as 'bad' as 45/45/10 AGS/PTS/devs.

Really the only downside is the potential for drama and politics. I think I said "50/50" already elsewhere in the forum. On the other hand, it could also de-politicize things if there is a second fund for development outside AGS, both dedicated to this DAC. Might make it possible to hire more devs full-time exclusively for DNS.

Another way to put it: Would you pay a premium to have this team snowball right now, over a 50/50 AGS/PTS team sometime in the future? How much?

213
KeyID / DNS-Pinky-Promise Bounties
« on: March 21, 2014, 02:56:18 am »
I've been given the go-ahead for using future shares in DNS derived from PTS that Invictus holds in the Angelshares fund at the time of the Bitshares DNS snapshot. In other words, about 10% all DNS are available as IOUs from me & Invictus. The amount I'll be spending in the short term is a rounding error with respect to total AGS DNS holdings. This is a way to reward DNS believers who trust I3 at a premium rate while not diluting current AGS funds.

I started a spreadsheet here to track the IOUs:

https://docs.google.com/spreadsheet/ccc?key=0AjWEvwFB1BZ7dHlRMFFlRHVvM21XU3pqS2NoSUFqWWc&usp=sharing

The total share amount might change, and I will adjust bounties accordingly. If you have trust issues (which are actually a little bit reasonable in the land of crypto-equity), I can't help you.

214
KeyID / Share amount
« on: March 20, 2014, 12:42:15 am »
I can't decide.
Write-ins *might* be considered

215
Why only one TLD?

There is a pretty good discussion here you might want to read first: https://bitsharestalk.org/index.php?topic=3652.0

The short answer is, if you look at what distinct TLDs actually do in real life, it's to establish different *rulesets* for how the namespace is managed. The fact that it can be used to avoid name collisions is a *secondary effect* and an artifact of how traditional DNS is structured. AAPL.com and AAPL.org aren't just avoiding a collision - AAPL.org is utilizing the fact that it won't get sued on the .org namespace, while it would on the .com namespace. Sure you can make it so that two TLDs use the same ruleset and are on the same blockchain, but then the only thing that it accomplishes is to make an aesthetic difference between typing "yoursite-org / yoursite-com" and "yoursite.org / yoursite.com". One blockchain is one namespace, no matter how you slice it or mask it.

So the idea is, future DNS derivatives who want to have different rulesets for their namespace, or who want to prove me wrong and show how people are just willing to avoid collisions (would you register "yourname.dac" if "yourname.p2p" is registered and popular? maybe) can launch a DNS derivative a la BTS X.

So .key might have a ruleset that fits the supply/demand characteristic of having a namespace for public keys better than domainshares.

.intr could be the first namespace to support a full character set.

There might be another blockchain that handles migrating .com, .org, etc onto a blockchain.


Why .p2p?

Here were the good suggestion, IMO:
* .bts
* .dac
* .blk
* .we
* .p2p
* .key
* .dom

I don't want to do .bts or .dac because I find them slightly more awkward to say than .p2p, and I have a really strong aversion to people trying to sell me stuff (I know that's not what's happening, but I can't help but think .bts -> "BTS STANDS FOR BUY BITSHARES(tm)"). Furthermore I think .p2p does a much better job of marketing the advantages of a blockchain-based TLD than the others - people will instantly recognize what's up versus just thinking it's another TLD.

.key shouldn't be wasted on anything other than a namespace designed specifically for keys.

.we is risky because all two-letter TLDs are reserved by ICANN for country codes.

.blk is ok but worse than .p2p, fewer people know what a blockchain is

.dom is ok, maybe the first derivative with different namespace rules can grab it


50,000,000 shares:
It's just aesthetics. Open to alternatives.

216
KeyID / DNS FAQ - collecting questions here
« on: March 19, 2014, 08:36:20 pm »
I started:
https://github.com/nmushegian/invictus-FAQ/blob/master/DNS.md

Interested in more questions you guys have. Obviously those questions make assumptions I haven't explained yet, I'll get to that.

Will slowly bump the bounty until I figure out what it's worth.

217
General Discussion / MOVED: History
« on: March 19, 2014, 05:14:29 pm »

218
How big of a selling point would it be to have arbitrary characters in domains? This would allow you to have domain names with chinese characters. Is this a big deal, or just a novelty? China is already used to using ASCII characters for domains, and it would add a *lot* of complexity and delay launching by quite a bit.

https://bitsharestalk.org/index.php?topic=3658.0

219
KeyID / Allowable names discussion
« on: March 18, 2014, 01:39:08 am »
This is *not* a discussion about TLDs or UX.
This is just a discussion for what are permissible strings for names in the name-record store.

First suggestion, lowercase alphanumeric.

Second suggestion, lowercase alphanumeric and periods, but only if you owned the suffix without any periods (so you can emulate subdomains). Still manageable complexity.

Also maybe lowercase alphanumeric and any symbols, with above suffix rule.


Stuff that currently appears after the TLD in your browser bar is not part of the name resolution and is independent of this system so it would remain the same.

220
KeyID / DNS Status Update
« on: March 17, 2014, 08:48:27 pm »
This week I plan to finish writing tests for all the DNS transaction logic.
All the empty functions here should be filled up: https://github.com/BitShares/bitshares_toolkit/blob/master/tests/dns_tests.cpp

Then I will bump the business logic bounty up.


Hopefully by the end of the week Dan will finish making the RPCI extensible, then I can write a json-rpc and a CLI to test it with, so you can play with a dummy (no network) version within 2 weeks. No idea what his plans are though.

221
KeyID / TLD discussion
« on: March 17, 2014, 07:06:18 pm »
What should BTS DNS's TLD be?

We probably can't use these awesome ideas:

* .bit  - gotta play nice with namecoin
* .web  - any lawyers care to weigh in? http://en.wikipedia.org/wiki/.web
* no TLD  - have to be able to distinguish between searches in the omnibar and addresses, and have to distinguish between "test.com.tld" and "test.com"
* .dns  - planned meta-TLD used by DNSchain

Collecting good suggestions here:

* .bts
* .dac
* .blk
* .we
* .p2p
* .key

222
General Discussion / Satoshi quotes to woo crypto community
« on: March 17, 2014, 05:21:25 pm »
I used these in the DNS thread on bitcointalk



Bitcoin Derivatives vs BitShares Derivatives

Bitcoins have no dividend or potential future dividend, therefore not like a stock. (They’re) more like a collectible or commodity.
-Satoshi, Aug. 27, 2010

Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone.
-Satoshi, June 21, 2010


TAPOS

It’s hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world.
-Satoshi,  July 8, 2010

When someone tries to buy all the world’s supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It’s great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell. The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979.
- Satoshi, July 9, 2010

223
KeyID / DNS thread on bitcointalk.
« on: March 17, 2014, 07:09:50 am »

224
General Discussion / Everybody chill out
« on: March 17, 2014, 06:10:09 am »
I3 *could* have released BTS X within 2 weeks or so with all features "ready". Then they would have "kept their word".

Maintaining "credibility" is possible but is a *worse option* than just pumping out 3 or 4 DACs real quick because they're at a point where it's possible now, even if it delays cash cow BTS X, especially since it makes it possible to release BTS X with much greater confidence





225
General Discussion / MOVED: BitShares Me - sub forum
« on: March 16, 2014, 03:32:55 pm »

Pages: 1 ... 8 9 10 11 12 13 14 [15] 16 17 18 19