Don't twist everyone's arms and force them to upgrade at launch. Offer a transition period and let those who are happily using the existing platform continue to do so for at least a month or two. Those who prefer the new version and want to start a new asset or migrate their old asset can do so. Any bugs and usability issues can be found and fixed. When it's stable you can more actively encourage people to migrate or at least try it out; only after some time you should forcefully upgrade.
This isn't possible, the two systems cannot interact and cannot run side by side. They don't use the same dbms, the database structure is different, different application framework, even different methods of authentication. 2.0 has a normal web interface, 1.0 uses a client written in Javascript that uses public key cryptography (which most uses didn't understand, I spent so much time recovering lost accounts) to authenticate. Trying to maintain the two systems would be a complete nightmare. Give me a little more time to work out the niggles. Sounds like it isn't impossible, just requires spending more time than you have available. This is completely understandable, and I of course respect and appreciate your efforts, but that's not going to change how I feel about the upgrade. It was a complete shock. Yes, I could have tried to prepare better but my time is limited too. PS What happens to asset holders who have not yet migrated to 2.0 when I pay dividends? |
|
|
|
The way the reward is calculated on slush pool make it hopping proof.
No, it doesn't. It is well known that slush's method is hoppable. Please read Analysis of Bitcoin Pooled Mining Reward Systems and/or search for the numerous discussions of this in this forum. It is an automated process. Informations about the round should not be shown or should be displayed with a delay like deepbit.
Why do you want the pool to be less transparent? A pool that uses a hopping-proof method can safely display all of its statistics. |
|
|
|
Dividends bug has been fixed, you can now make dividend payments
I tried it again and it still doesn't work. Meni, every effort has been made to make GLBSE2.0 bug free, it's been developed in the open with a public beta, plenty of bugs as a result were found and fixed.
One of the problems though in moving from a testing environment to a production one, is that it's not possible to predict every possibility. Things that did work during testing, for various reasons broke on moving to production. Many of them were caught and fixed before launch, some were not.
I understand that, bugs will be bugs, they are not what I'm upset about (but see more below). The public beta was also there so users could become familiar with the new interface, not just test for bugs, it was also used to get feedback from the community on what you want from your exchange.
Only after the major bugs are fixed it's reasonable to try out the interface and provide feedback. Unless you spell out specifically whats wrong and what you need I won't be able to build it into the system. Give me something to go on so that I can build the functionality into it.
I'll contact you about specifics. GLBSE1.0 and 2.0 are two completely separate, different systems, they cannot operate or interact with each other.
For this exact reason the upgrade should have been handled differently. (I'm assuming GLBSE 1.0 was disabled because it did not work; please tell me if this is wrong and it was just a DB lock). Don't twist everyone's arms and force them to upgrade at launch. Offer a transition period and let those who are happily using the existing platform continue to do so for at least a month or two. Those who prefer the new version and want to start a new asset or migrate their old asset can do so. Any bugs and usability issues can be found and fixed. When it's stable you can more actively encourage people to migrate or at least try it out; only after some time you should forcefully upgrade. |
|
|
|
|
If you mine in a hoppable pool, you get less, hoppers get more, that's all there is to it. Friends don't let friends mine in hoppable pools.
slush's pool is not as hoppable as proportional, but is still hoppable. Please mine in a hopping-proof pool instead. (I have the greatest respect for slush, but his hesitance to adopt a modern reward method has gone too far.)
Don't confuse this with variance which isn't going to matter long term. slush's method also happens to be high-variance.
|
|
|
|
You had the opportunity to test the beta before it went live and help him fix any issues. Last I saw, only mila was actively poking the beta and finding bugs.
I don't have any spare time to dedicate to beta-testing this software and I did not at any point volunteer to do so. GLBSE is a service provided by nefario and I have already paid 20 BTC in fees for this service. It is not reasonable to expect that I should donate my time as well. What is reasonable to expect is that the problems would be fixed before forcing everyone to switch to the new version. But that's all missing the point. The bugs are not what I'm disappointed about. Everything about GLBSE 2.0 is more rigid, less intuitive, less usable, and less compatible with a bond model than 1.0. |
|
|
|
hashing algorithms are designed to be "trap door" functions. That is they are designed to work only one way.
A Trapdoor function is not the same as a One-way function. The difference is that with a trapdoor function, there is some secret which, if known, allows you to compute any inverse you want of the function. If SHA-256 was a trapdoor function, it would mean that someone who knows its secret would be able to find blocks effortlessly. |
|
|
|
|
GLBSE 2.0 is out and it's absolutely awful.
What's worse, it seems GLBSE 1.0 can no longer be used. (Either that or the database locked up again.) So I imported my accounts, and after much searching managed to locate the feature to pay dividends. But trying to use it leads to an "internal server error". Because of this, coupons for block #172703 from last night are still pending.
I've contacted nefario about this and I hope it will be resolved soon.
To whomever it may concern, the fact that using GLBSE 2.0 is intolerable is also delaying my plans to issue new bonds.
|
|
|
|
Some of us have heard about OKPAY, a payment processor which seems friendly towards Bitcoin. It seems they're now taking it a bit further and offering new Bitcoin-related services. I've just received this from their mailing list: OKPAY Launches the Complete Bitcoin IntegrationAUTOMATIC DEPOSITS Use bitcoin e-currency to fund OKPAY account and instantly convert your funds into USD, EUR, GBP, CHF or RUB. OKPAY e-Wallet will be funded automatically upon receiving the transfer and required confirmations. Apply for a prepaid OKPAY debit MasterCard® and withdraw your money at any ATM worldwide. ACCEPTING BITCOIN PAYMENTS It is extremely easy to start accepting bitcoin payments as the merchant doesn't even need to keep bitcoin software or monitor any transactions. OKPAY processes bitcoin payments automatically transferring merchant the usual OK USD or OK EUR amount instantly as an ordinary payment, 100% chargebacks free. BITCOIN WITHDRAWALS Purchase bitcoin for yourself or send payments by simply using the bitcoin withdrawal option in your OKPAY account. Specify the amount, enter receiver address and the system will process your payment request. OKPAY offers real time rates for BTC/USD, etc., regardless of the exchange amount. HOW DOES IT WORK? Bitcoin-OKPAY exchange rates are timely provided by major bitcoin exchange services. OKPAY supplies clients with dedicated bitcoin addresses, at the same time new address can be generated for each operation to ensure maximum security and anonymity. SECURITY OKPAY account has the most advanced security measures available: variable PIN-codes sent to the mobile phone number or email address, IP access filtering, etc. Account protection settings can be found and tuned in the Security Center of your OKPAY profile. |
|
|
|
Which would you think would be better? They get trade fees or charge for cashing out/in?
There should be an option for both, so they can choose the amount of each type of fee (which could be 0). Thats not entirely true, although I'm on your side as I think its pointless, Intersango's new fee structure does make business sense: it delivers on the goal of reducing spreads. Their thinking is a tighter spread will lead to more customers. For those who unknowingly sign up, the buys will be more expensive then they expect. I think this is stupid, however it has made the exchange favour sellers. If you dont mind using two exchanges, you can use this to your advantage for your trading activities.
The tighter spread is illusory because what customers gain in the spreads they lose in the fees. For an ordinary customer which just buys or sells and is not a maker, the fee is 0.95%. Intersango may be hoping that the customer will think, "Hm, the fee is sometimes 0.35% and sometimes 0.95%, this is all very confusing, let's say it's 0.65% on average, and the spread is pretty good too, let's join". I am not of the opinion that defrauding your customers should be called "business sense". The new system actually discourages participants from accepting a highest bid/lowest ask. Instead it encourages the order to be off that by 0.00000001 BTC (or whatever the lowest increment the market supports).
If everyone is informed, there shouldn't be a functional difference from the symmetric system, just the displayed numbers will be different. In the symmetric system you have the same dilemma - if instead of accepting an existing order you place your own order, you stand to gain a more favorable execution price, but you risk the market going in the opposite direction and losing the opportunity to execute. Hopefully the market throws a warning like "your commission if you click okay will be 0.095% which is equal to $x.yy <fiat currency>. So the newbies don't get surprised.
If you add needless obfuscation people will be more confused, there's no way around that. |
|
|
|
If you're interested in buying you can anyways put an offer at your desired price on GLBSE and just wait if either someone sells their bonds or Meni issues some at that price or lower.
One problem with that is that if the issue price is lower than his bid, he'll pay more than he could have gotten it otherwise. To my disappointment, it is currently impossible in GLBSE to force the issue to take place at the lower price. @Meni: Very interesting enterprise - I would from experience however strongly recommend to automate payments as much as possible (e.g. Write a script that checks for these key blocks, extracts the necessary info and you just have to press enter to send a few more BTC for the next payment to GLBSE + issue the current dividend).
Without extensive validation (which I am not currently equipped to do), I wouldn't trust a script to do any more automatically than it currently does. I have payment amounts automatically calculated and email notifications of new key blocks. I'm also training my family to handle payments in my absence (in fact I'm holding off payment on the recent block #172367 to save it for a training session in a few hours). Actually I thought of doing something like this too, but it would just be too easy and tempting to do it ponzi style instead. Maybe you could battle this by mining on p2pool or Eligius and sign a message with the private key of the payout address with the generations inside? This would prove in the blockchain that you are capable of mining fresh coins and not just using the ones you got from bonds (which at the moment would be _very_ easy). As you calculated yourself in the starting post - even without selling new bonds you would be able to keep this running for nearly a year.
Inaba is in custody of the actual hardware (which hasn't arrived yet), so he should be able to confirm there is hardware owned by me. I've come to devise this asset after a train of thought starting from wanting to invest in mining, so I have no intention to bet against that (and in fact will likely almost always have spare capacity as my own investment). But my claim to legitimacy rests primarily on - Planning the issue so that even if I had no hardware, I would be able to cover my obligations from personal assets (buying back if needed); - Committing to do so should the need arise due to unforeseeable circumstances; and - Staking my reputation on this commitment. So it basically boils down to how much I am trusted not to run away with the money. This will likely be a more limiting factor as I scale up the venture, and I will be looking for ways to inspire confidence. |
|
|
|
I've completed a Hebrew translation on Transifex. Is any further action required to have it included in the next version? Is there some way I can preview it before it's included in the next version? How can Japanese be added to this list?
Took me a while to figure out, but apparently you need to log in, go to https://www.transifex.net/projects/p/bitcoin/resource/tx/ (note: This is a different link from what paraipan gave, where there is a different option that doesn't work), and click "Add New Translation". |
|
|
|
By the way, any plans to have the issuer of the share get a portion of the trading fee?
Why would the primary issuer get a cut of the secondary market? The issuer get the advantage that a secondary market gives them liquidity. If the issuer gets a cut, then the transaction fees must go up. If the issuer wants to make a margin they can set up their own secondary market, but I'd never invest in them. I want them to stick to the knitting. I guess you're right, what I had in mind is relevant for some specific use cases (for which there are better solutions) but maybe not in a broader sense. |
|
|
|
At the time of the trade, the 1% would be determined and split between both parties. Trade at 1 BTC, fee is 0.01 BTC and 0.005 is charged to each party. Buyer buys 1 share for 1 BTC & 1.005 BTC is removed from their trading account. Seller sells 1 share for 1 BTC and 0.995 BTC is added to their account.
Company(or stock holders) sell shares. You charge the buyer 0.5% more than the stock value and you take 0.5% of the money the seller receives.
I agree. The fee should only be charged to 1 party, but not limited to 1 side of the trade. The person providing the liquidity should be able to make their trade for free. For example, if I put up a buy order at .15 and a sell order at .16, but the stock is actively trading at .155, I should not have to pay fees when my orders are eventually filled. The person who chooses to fill the order (buy at .16 or sell at .15) would pay the fee. This would encourage more open orders and improve liquidity. Just placing the fee on one side or the other seems to encourage holding or discourage trading, while free trades for providing liquidity would encourage more people to list orders, thereby encouraging more trading. It would also allow companies to list their IPO without being victim to double dipping (charging to create the asset and then charging to sell the asset).
I get this, actually yeah this is much better, but more complicated to implement. Very well, I'll implement this, although not for the initial launch, it will be a little bit after. I strongly disagree with this, at least until someone explains how this encourages providing liquidity. Intersango did something like this, I'll quote what I wrote to them: To me it seems very poorly thought out, for the simple reason that it will make absolutely no difference. Makers take fees into account when setting prices, and the change will just mean they will modify their prices so that everybody still pays the same.
Before:
John wants to sell 10 BTC, as long as he gets at least $0.9935 for each. He puts a sell order @ $1/BTC.
Beth executes this order, paying $1 per BTC plus 0.65% fee.
John gets $9.935, Beth pays $10.065, Intersango gets $0.13.
After:
John wants to sell 10 BTC, as long as he gets at least $0.9935 for each. He puts a sell order @ $0.997/BTC.
Beth executes this order, paying $0.997 per BTC plus 0.95% fee.
John gets $9.935, Beth pays $10.065, Intersango gets $0.13.
No change in the actual trades and prices people get, this just makes things unintuitive and complicated.
By the way, any plans to have the issuer of the share get a portion of the trading fee? |
|
|
|
How many and at roughly what price?
It will probably be 500 bonds. I don't know the price yet, and in any case specifying it in advance would significantly affect the market. |
|
|
|
Any plans on issuing new bonds?
There is a possibility I will issue new bonds next week. |
|
|
|
BTW, have you got any further details on the nature of your PoS proposal? As I mentioned earlier, I find these ideas fascinating...even though I might not fully understand them.  I've added a description of my PoS system to the wiki. But I'm beginning to like cunicula's system, it seems more robust against DoS attacks. |
|
|
|
the design clearly leads to a mining monopoly under any likely startup scenario. Why would such a design attract interest from volunteer programmers? After the very first roll of the die, isn't the new altchain reduced to an academic exercise in monopolist behavior?
Seems to me that until a mechanism is designed into the new protocol to prevent the "instant monopoly" problem, you're not going to attract interest from volunteer programmers (or anyone else for that matter) in an altchain. Whether the mechanism is based on a y confirmation limit, an escrow scheme, growing p over time, or some other option, don't you think the issue has to be addressed before it's handed off to a programmer?
This is a relatively easy problem to fix if we want to go forward. But in case there is any doubt, I oppose creating this altchain anytime soon. Unless it is very well thought out (preferably with some additional improvements over the original Bitcoin. There are quite a few issues in need of fixing) and has several supporters willing to dedicate effort to making it succeed, it will do more harm than good. |
|
|
|
Secondly, your idea works and sounds good. Let's consider the starting result where p starts out at 0.01 and increases by some small fixed amount or percentage with every block until it reaches some long-term target.
The initial block finder would have mining power at block 2 equal to:
50^0.01/(50^0.01+9*0.000001^0.01)=11.7% of the network. The other 9 miners would each control 9.8% of the network.
Thus we no longer have a winner take all lottery. I agree that this is probably a better system than a winner take all lottery (though I still find the winner take all situation amusing). Moreover, it should be extremely simple to code this.
A better solution is to add an offset. Instead of giving stakeholders an improvement factor of s^p (s is the stake and p is the influence level of stake on mining), make it a factor of (a+s)^p where a is some constant. So early on, when nobody has a large stake, mining will be proportional to hashrate without much consideration of stake. Also later, even someone with low or no stake can still mine somewhat. An offset introduces decreasing returns to scale (DRS). With DRS, output per unit time increases when you subdivide accounts. Fixing hashing power, mining with 100 accounts with 0.01 bitcoins in each has a higher output rate than mining in 1 account with 1 bitcoin. Nevertheless, an offset works too. It just needs to be phased out completely after the initial distrubition period is over because DRS allows gaming of the system. Right, seems like I still haven't got the hang of your system. Starting p at 0 and letting it gradually grow to the target value seems like it could work, but there's still a nontrivial bootstrapping problem. I guess that a faucet to get a small stake to start could mitigate it. p should remain very small until there's a somewhat decent exchange. |
|
|
|
Heh - that sounds like just giving it a different name for the sake of making it sound better  Maybe. It's an important distinction and using a different name could prevent confusion. If the pool doesn't have the BTC to make DGM payments during bad luck, it's not gonna appear from no where - the payments will be late  The payments are not delayed on any case. Either they are paid on time or the pool declares bankruptcy and shuts down. In practice, the operator may be willing to liquidate personal assets and add it to the pool's reserves to keep it running. With parameters like in EMC the risk is minimal. Ozcoin is more aggressive, cointron even more so. As for bankruptcy payout - the main problem I'd see there from DGM vs PPS (or some of the different PPS) is that no one can probably work out the owed amount on DGM since there is a future component to that, that depends on the future also.
On PPS it's pretty simple.
You can calculate the expected future payment for a given score. (Actually, you can parametrize it so that the expected payout is the score). The operator should pay that out so that miners won't suffer (I'm assuming a deterministic payout is considered better than a variable payout of the same expectation). The total score of all miners is bounded, and the operator should have this as an additional reserve - he should declare bankruptcy before he becomes unable to offer a cashout. |
|
|
|
|
Show Posts
