CoinBr.iDiff-E February expired as planned, paid everyone 0.03651011 per share (current difficulty) and also returned remaining collateral 0.08-0.03651011 = 0.04348989 per share to people who were short selling. In few days it will be reintroduced as CoinBr.iDiff-E April.
what happens to existing shares? can you "decommission" them? Yes, we'll start with clean slate. MPBPT works this way, too. Both iDiff and MPBPT are investments where you can either profit or lose part of your investment, so keeping the shares would require some kind of "negative dividends". It's simpler just to remove all shares and pay everyone out at expiration date. Another possibility would be mutual fund with fixed pricing based on underlying assets, maybe that will happen in future. |
|
|
|
By the way: I will have an option to just use an existing bitcoind/Bitcoin-Qt instance, but most users, especially those who have never used Bitcoin, will benefit dramatically from having this as the default, all-in-one, standalone solution. It will probably show up in the preferences to "Allow using existing already-open Bitcoin-Qt/bitcoind instances".
Recommendations, welcome!
How will users benefit running bitcoind only when armory is started? I call BS, bitcoind can (and is meant to) run all the time in background. With 0.8 disk trashing is no longer an issue. Running it as a service benefits from more open connections, always most recent data readily at hand and also user's transactions propagate quicker. Maybe if user has low-spec computer... but then he shouldn't use bitcoin-qt nor armory at all... |
|
|
|
|
CoinBr.iDiff-E February expired as planned, paid everyone 0.03651011 per share (current difficulty) and also returned remaining collateral 0.08-0.03651011 = 0.04348989 per share to people who were short selling. In few days it will be reintroduced as CoinBr.iDiff-E April.
|
|
|
|
Just thought it would be a funny idea... but if there was an email system that used bitcoin (small fees) for sending messages. You could make it so that if someone sent you a message and it cost them a small fee... you could somehow reply and return the fee to the sender. this would make it even cheaper (since no one will probably respond to spam but they might to a valid user)
I suppose it would work like this: There is some kind of bitcoin clearing house where you set up an account. You can input a bitcoin amount and it will allow you to send a message. When the message is sent the bitcoin fee is put somewhere in reserve. If the person you email replies... then the fee is returned to you. Otherwise it's used to finance the actual service itself. Whatever the fee amount would be something low but not so low that a spammer could afford to spam the network .
Good idea, why not just attach (multisig?) transaction to the email, and if receiver wants to redeem it, he can sign it and broadcast it. So that sender and receiver don't need trusted third party to confirm the payment, but also bitcoins appended to the message can't be stolen by intermediary. Also if the message isn't delivered, the transaction expires and payment returned to sender. Edit: But, why can't everyone just use PGP? Encrypting/signing millions of emails is computationally expensive, mass gathering of pgp fingerprints is nontrivial. That would lower spam volume, too. |
|
|
|
Or send message to MPOE-PR user on this forum. If someone has blocked it on your end, you can also try a mirror: http://mpex.coinbr.com/  |
|
|
|
- snip -
My objection i don't see answered is, what stops other miners to spontaneously build longer chain with smaller blocks that more easily propagate? (In absence of said cartel.) . . .
The proof-of-work system. How, I'm asking again? The proof of work will naturally favor smaller blocks that can be spread faster to majority of the network (and thus support decentralization). Yes, worst connected nodes will be left behind, but as long as there are plenty of "middle class" nodes that will naturally favor blocks less than certain size and slow propagation of oversized blocks making them into orphans more likely, I don't see a problem. Everyone starts with strawman "we will inevitably have single primary megaminer/supernode, heeelp!" and argues from there. Why? How? I'm running myself two instances of bitcoind on one 5 years old desktop PC with dedicated 5400rpm HDD on 10mbit internet and it does fine. I estimate this setup would happily accept 10x, and with some updates 100x current volume.
You aren't paying attention to the debate. This is about miners with slower internet bandwidth. Try again with a 1200 baud dial-up connection and see how long it takes you to receive the next 1MB block when it is added to the blockchain. You seriously insist on making mining or running full node possible through 1200 baud dialup? Please don't be ridiculous. 10mbit-like satellite connection is affordable in most of the world now. |
|
|
|
This requires conspiration of biggest pool owners with majority of hash power. Huh? It's the arguments that the pools (note: miners are not even invoked here, the idea that the authority is handed over to a couple pools is already so easily accepted) will reject "too large" blocks that demands a conspiracy. Peter Todd's point is that a single miner can push off all the smaller ones, all on their own— unless there is a conspiracy to stop them from including these otherwise valid blocks. As you argue such a conspiracy "will result in abuse of current rules", and I agree. Worse, if we as a community can't figure out a criteria to conspire on and put it into the system— where there is no risk of defection— how can we expect a pool-conspiracy to do better when they have less powerful tools to enforce conformance? Also, while the network is choking on blocks which will be rejected users are left around waiting longer times for confirmation because its not obvious when a chain is going to get orphaned because it violated the invisible cartel rules. Finally, even if the cartel is successful at preventing single miners from breaking the system, its in each member's individual best interest to mine the largest possible blocks, so we should expect a slow evaporation which has the same conclusion: a single primary miner/validator. I understood the argument as "big miners/validators will mine too big blocks, leaving smaller users unable to receive/verify them behind". My objection i don't see answered is, what stops other miners to spontaneously build longer chain with smaller blocks that more easily propagate? (In absence of said cartel.) Everyone starts with strawman "we will inevitably have single primary megaminer/supernode, heeelp!" and argues from there. Why? How? I'm running myself two instances of bitcoind on one 5 years old desktop PC with dedicated 5400rpm HDD on 10mbit internet and it does fine. I estimate this setup would happily accept 10x, and with some updates 100x current volume. |
|
|
|
Ok, so a 10GiB block is unacceptably large. What about a 5Gib block? Or a 1GiB block? Or a 500MiB block? At some point the block will be confirmed by a large fraction of the hashing power, but not all the hashing power. The hashing power that couldn't process that gigantic block in time has effectively dropped off of the network, and is no longer contributing to the security of the network.
So repeat the process again. It's now easier to push an even bigger block through, because the remaining hashing power is now less. Maybe the hashing power has just given on on Bitcoin mining, maybe they've redirected their miners to one of the remaining pools that can process such huge blocks, either way, bit by bit the process inevitably leads to centralization.
This requires conspiration of biggest pool owners with majority of hash power. But if such conspiration is going to happen, it will result in abuse of current rules (and any updated rules) anyway. So I consider this argument a strawman. With any competition, issuing 5GiB block out of the blue takes serious risk of it becoming orphaned and Gavin's 5-second proposal supports exactly that. |
|
|
|
|
I think no one here took into consideration major difference between bitcoin and fiat- fiat economy is closed by regulation and number of its "users" isn't growing much. Introducing new significant services into meatspace where fiat can be spent is hard. On the other side, btc economy is very open, there are many new people streaming in and some inevitably invent new ways for bitcoins to be spent, making large part of otherwise hoarded bitcoins circulate. So until bitcoin becomes widespread, I don't fear hoarders/deflation at all. The same incentive that drives hoarding, is also driving people who want to earn bitcoins from hoarders.
|
|
|
|
... We in Bitcoin have, on the other hand, a fantastic chance to build a monetary and financial system from scratch. But we have none of the protections outlined above ....
Okay, so I went to check https://strikesapphire.com only to be greeted by "proxy detected - to ensure we don't accept users from jurisdictions where online gambling isn't allowed" bullshit. So, this is your idea how to build "a monetary and financial system from scratch", right? By preventively succumbing to existing insane regulation? Just because Bitcoin opens up the possibility of acting like a total pirate for the moment doesn't mean you should run your business like a 15 year old tweaker in a basement with no regard for risk. I think that was the OP's point. Your business is a liability. Risk can come from regulatory, technical, security or financial sides of your business. In our case we spent a lot of money on lawyers and determined that the risk of running our casino to the US was greater than the value of what we could make in Bitcoin, and we have good information and good reasons to support that decision. That doesn't change the fact that Bitcoin is an amazing avenue for online casinos to bypass third-party payment processors, or that it allows startup casinos lower their overhead, be more competitive and challenge the entrenched powers in the industry. What it does mean is that each business should determine for itself what level of risk it's willing to take, and make that information available to its customers because anything less would be dishonest; and we've seen enough dishonesty already surrounding crazy Bitcoin schemes. We've been in business since July 2011. It always amuses me when Americans who can't even elect a government that lets them gamble, drink unpasteurized milk or smoke a cigarette get on my case for not holding up their "freedoms". What freedoms? You know, we're open to North Korea but we don't get any players from there either. It's not my problem. Hm, aren't there sanctions against trade with North Korea, too? And while I do see your point, how do you want to compete with people that did not spent a lot of money on lawyers? |
|
|
|
... We in Bitcoin have, on the other hand, a fantastic chance to build a monetary and financial system from scratch. But we have none of the protections outlined above ....
Okay, so I went to check https://strikesapphire.com only to be greeted by "proxy detected - to ensure we don't accept users from jurisdictions where online gambling isn't allowed" bullshit. So, this is your idea how to build "a monetary and financial system from scratch", right? By preventively succumbing to existing insane regulation? Anyway, stuff i have here on port 80 is fine with freenode and all other proxy checkers so far. And I couldn't find any thread here where I can complain that is recent enough and isn't locked. Looks like quite a fail you've got here. |
|
|
|
V Bitcoinwireless nie je momentalne ani jedna krajina EU (nielen CZ/SK), som sa najprv potesil ze si budem dobijat nemecku sim kartu.. a som to zistil  |
|
|
|
I ran bitcoind 0.8rc provided 64bit linux binary (with -dbcache=1000), it synced in just 1 hour using single connection to locally running bitcoind 0.7, while being responsive to RPC queries all the time. I like it  |
|
|
|
|
I hate to be the only one asking, why can't be the money invested into better hardware/software? There are daily outages!
|
|
|
|
Okay I get it now. But it isn't clear at all how would that apply to MPOE options. Only total traded volume is known and published, without analyzing each transaction it is hard to discern how many options MPOE bot bought back that were issued by itself (and thus effectively decreased open interest). Not even taking into account other users that recently started to do the same as MPOE. Number of option exercises in the course of month isn't known, too.
If the volume is known there would be no trouble in calculating the OI at all. Do you have the db with each and every tx or you don't? How do you hedge your risk then? For derivative markets OI is essential, it's the key value to analyze, not the volume.. What risk it needs to be hedged against? The options are fully covered regardless how many of them there are. And if you mean hedging against BTCUSD, how would open interest help in that? |
|
|
|
Naturally we need to be aware of the open interest for every option contract listed.. Please reveal..
I don't understand what do you mean, can you please explain? These numbers should be available to anyone.. Okay I get it now. But it isn't clear at all how would that apply to MPOE options. Only total traded volume is known and published, without analyzing each transaction it is hard to discern how many options MPOE bot bought back that were issued by itself (and thus effectively decreased open interest). Not even taking into account other users that recently started to do the same as MPOE. Number of option exercises in the course of month isn't known, too. Moreover, already happened several times that 80% of all trade was near beginning or end of the month and total amount of options changed wildly in matter of hours. Any proposals how to come up with meaningful numbers in this situation are welcome. |
|
|
|
By the way, CoinBr too saw hourly volume spikes over 1k BTC several times already, and it went smoothly or with only few quickly fixed hitches. That includes users successfully placing big orders in the middle of S.BBET IPO madness. I can't imagine achieving this while moonlighting or "just for fun". It needs sustained focus and attention, doing it slowly with good planning and backups and watching out for featuritis. |
|
|
|
Naturally we need to be aware of the open interest for every option contract listed.. Please reveal..
I don't understand what do you mean, can you please explain? |
|
|
|
How exactly they will be taken care of, did you announce it somewhere, do you have a plan? Or are you again waiting for things to solve themselves somehow and thus further prove your utter ineptitude in this area? What should i tell my brokerage clients when next week their shares go *poof*?
We're supposed to get the list of holders. We'll probably move to BTCT.co All shareholders will be able to sign a message with their MPEx key upon which I'll transfer their S.BVPS to the account they requested. I see. So I'm probably sending coinbr users e-mail that if they won't sell the shares, they'll probably have to create BTCT account where they probably receive the new shares. |
|
|
|
Shareholders will be taken care of. The majority of the shares were still owned by the company or company officials anyway.
-p
How exactly they will be taken care of, did you announce it somewhere, do you have a plan? Or are you again waiting for things to solve themselves somehow and thus further prove your utter ineptitude in this area? What should i tell my brokerage clients when next week their shares go *poof*? |
|
|
|
|
Show Posts
