I also wondered why so many people believe that the Chinese bitcoin market formed the majority. Latest numbers I've seen was 80% or more of all btc-exchanges were in USD and Yuan was around 10% or so.  Also the exchanges operating without fees and the suspected padding with zeros of numbers do not exactly prove a majority stake.

To me it looks like the entire Yuan-market is smaller than that of mtGox after it's decline. At least that gives us some reference of the effect on the market if a large stakeholder suddenly disappears.

I'm not sure what numbers you see, but it's things like this that have led me to believe that China is the biggest player: http://coinmarketcap.com/volume.html#pts

Notice that over 98% of the total PTS traded in the past 24 hours was directly with CNY. That's a little higher than normal; I think normally it's more like 90%. But I've never seen CNY take less than 80% of the total PTS volume.

Quote from: biophil on March 26, 2014, 03:06:54 pm

Quote from: CryptoVape on March 26, 2014, 02:20:40 pm

My suggestion would be to show in the wallet, perhaps on an 'Economy' tab:

Balance: 4000 BTS
Percentage of Total: 0.1%
Dividend Yield: 5%

Dividend yield would be the percentage of coins destroyed in the last year.  A graph could also show total supply decreasing as well as yield.

What would be the purpose of displaying the 4000 number? Since the fraction of the money supply is all that matters, the absolute size of your stake in the total supply is unnecessary and misleading.

Instead, the above balance should merely read 100m% (or some other unit that describes fractional quantities), and people are happy because if they just sit on their money, every day they'll own more m% than they did the day before. Done. The only people who ever need to know about the absolute quantities are the programmers.

For transactions, it would be better to show a purchase of 4000 BTS than 0.1%, which actually changes with each transaction due to the destructing fee.

The change in purchasing power for a single transaction is very very small. I don't recall what the fees are, but even if the fee is as high as 1%, you'd have to transact the entire money supply for the purchasing power to change by 1% in a single transaction. The few people who are moving very large amounts of money around are the only ones who will ever notice.

Cool idea. Questions: How will the charities be chosen that the DAC will donate to? How would the actual act of doing something with the money be automated? One of the big costs/headaches with charity work is putting the money in the hands of people who need it, and that sounds hard to automate.

Are you familiar with Memorycoin? They have an automatic charity donation ever 2 hours, and I believe what happened is that nobody has ever effectively gotten a real charity to be voted on. So one guy has collected all the charity donations and is waiting for the coin's value to rise before he gives them to anybody. Moral of the story: don't put too much faith that voting will accomplish your goals... On the other hand, Memorycoin never really worked very well anyway, so maybe it's a bad example.

I've been casually lurking the XCP forum, and I ran across an idea that might be very powerful for BitShares-family DACs if it works.

Background for the uninitiated: Counterparty (XCP) is a crypto-2.0 that's like Mastercoin: it's a protocol built on top of bitcoin and it's intended to be a user-defined asset platform with a trustless, distributed exchange. It kinda works, but building the coin on top of bitcoin has caused some problems.

One of the big problems with XCP is that apparently the XCP protocol can't escrow BTC. So if I go onto the exchange and try to offer BTC for XCP, the counterparty protocol has no way to force me to pay the BTC that I've offered. So if my order matches with someone, I have to go in and manually make the BTC payment to my order match. It's annoying and complicated. They've tried to work around the problem with fees and some other hacks, but none of it works very well, and it all comes down to the fact that XCP can't escrow BTC.

On a slightly-different topic, one of the coolest ideas I've read on the XCP forum is what someone called "burn-to-rebirth." They were discussing moving XCP off bitcoin onto some other coin (oddly, Doge seemed to be their top choice), and someone said "why not put a version of XCP on top of every coin?" Their idea was that on the bitcoin XCP chain, you could execute what they called a "burn-to-rebirth" transaction, and this transaction would reference a Dogecoin address. This transaction would destroy the XCP on the bitcoin chain, and then the XCP protocol running on the Doge chain would see the burn-to-rebirth transaction and create an equal amount of XCP on the doge chain and credit it to the doge address specified. Here's where I read the idea: https://forums.counterparty.co/index.php/topic,195.msg1517.html#msg1517

I don't know if it's even remotely feasible - but it would be amazing if it worked, because then you'd be able to trustlessly transfer assets from one coin to another. XCP would be a bridge from blockchain to blockchain. One of the problems is the escrow issue I mentioned above - none of the blockchains are designed to allow XCP to escrow their native currencies.

Here's how this relates to Bitshares: It would be fantastic to be able to send assets back and forth from one Bitshares product to another; take my lottery winnings from Lotto and invest them in Bitshares X. Could a burn-to-rebirth type transaction be defined in Bitshares products? I realize that you'd probably need a bunch of super-nodes on the network; nodes that run all bitshares products on a single machine and run some meta-protocol that can facilitate the transfer of assets from chain to chain. It would probably be very difficult to avoid centralization here, but if the incentives are structured properly it might work fine.

It seems like you could do this without even building the meta-protocol right now; just make sure that each Bitshares product supports the things that such a meta-protocol would need. Maybe this could just be the ability for some XCP-like protocol to escrow each Bitshares chain's native currency.

Have I been clear enough that anybody understands? Does anybody think this might be workable?

Thanx for the reply,
As i understand it i have nothing but good faith, that someone will come through with the goods,
And not just take the coin and run,
I am making a donation, not buying and ipo or stake, so i don't have a leg to stand on, If they say thanx for the donation see ya later.
Is there anything to give some feeling of security at all, A transaction id , for spent coin is not exactly confidence inspiring.
It does sound great, but have been burned to many times
Regards Dan

When you donate you'll get a transaction ID just like with any other bitcoin/pts transaction, and you'll be able to plug in the address you used to donate to the balance lookup tool at http://www1.agsexplorer.com/ to see that you actually own some AGS.

But it sounds to me you may be happier simply buying PTS, because then you can sell them if you ever get cold feet and you eliminate some of the trust required for AGS.

There are a lot of great ideas here that have great merit.

I would hate to lose the subtle deeper meanings behind the choice of Don Quixote as a hero for whom honor and courage outweighed the inherent dangers of the quest.

I would never have associated honor and courage with Quixote, and I'm sure I'm not alone in this. I've always understood Don Quixote as a sad, silly man who couldn't tell what really mattered in life. Googling "quixotic" gives me this definition as result #1: "exceedingly idealistic; unrealistic and impractical." That's what you want to say about one of your most powerful products?

While I'm throwing my cents around, I'd vote against "BitKey" because people won't pronounce the "T" and it will sound like "bikky." Nothing wrong with that per se, it's just that people will be hearing a new word they don't know and it will add an un-necessary level of confusion.

Yep! m% and u% should be standard. I'm wondering whether it should be made explicit enough that people could actually trade in terms of specific-block-m%, which would let people earn their dividends "right away" instead of having to wait for the market to move to adjust

This would be ideal if it's workable. I guarantee that people are not going to understand that burning shares is equivalent to paying dividends, and the reason is that when you burn a share, everybody else's purchasing power doesn't immediately increase.

For this reason, I'm generally opposed to burning-as-dividends, but if we could make it so that at the GUI-level, transactions are denominated in terms of percentages, that would be spectacular. Basically, there'd be this underlying "supply" that would be invisible to anyone who doesn't care about it; the actual currency units that people see and use would be all defined in terms of percent of supply.

Quote from: toast on March 24, 2014, 01:40:53 pm

I'm ok with much lower bidder/dividend ratio, decreasing bid minimum (both w.r.t. % difference like you said and also absolute total (relative to total supply)).

Quote

If you think this is interesting, I'll put a little more thought into it and design a bidder-payout-function that works.

Would love it!

All right, I'll see what I can put together.

Ok, this didn't take too long. Goal, in words: assign payouts that are higher for bidders who enter large bids. In math: given a sequence of 3 bids b={b_i-1, b_i, b_i+1}, we want the payoff of bidder {i} to be u_i(b)=f(b_i-1,b_i)*(b_i+1-b_i), where f(b_i-1,b_i) represents the fraction of the next bid increment paid to bidder {i}.

One candidate: let r=b_i/b_i-1, so r=2 means that bidder {i} increased the bid two-fold. Then f(r) = 0.5*(1-e^a(1-r)) works for any a>0. If a = 0.693, then a 10% bid increase only gets 3.3% of the next bid increment; a 50% increase over the last bid earns 14.6% of the next bid increment, and a 2x increase over the last bid gets 25% of the next bid increment. The largest share any bidder can receive of the next bid increment is 50%.

The attack I mention in point 4 in my OP is still possible, but it would require an extra step. Note that f(r) is concave, so it provides a larger incentive for a few large bids than for many small ones, so it should speed auctions up.

One of the big drawbacks to the arbitrary exponential function is that it's unintuitive. We'd have to put a thing in the GUI that would let the bidder type in a bid, and then the GUI would spit out the fraction of the next bid increment that it would be worth; that way bidders could see exactly what they're getting themselves into.